云原生技術-從微服務到serverless無服務器架構演進思考

作者：何明璐 2022-03-02 09:31:42
云計算
云原生 Serverless是一種構建和管理基于微服務架構的完整流程，允許你在服務部署級別而不是服務器部署級別來管理你的應用部署。

成都創(chuàng)新互聯(lián)服務項目包括和林格爾網(wǎng)站建設、和林格爾網(wǎng)站制作、和林格爾網(wǎng)頁制作以及和林格爾網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，和林格爾網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到和林格爾省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

今天再下從微服務到ServerLess無服務器架構的演進過程方面的話題。對于ServerLess我在前面專門寫過一篇文章進行說明，自己也專門申請了騰訊云ServerLess環(huán)境做了簡單驗證和測試。具體可以參考下面這篇文章。

你應該了解的Serverless無服務器架構和應用場景

最近1到2年，類似阿里，騰訊，華為各大公有云服務商對ServerLess架構和解決方案推廣力度很大，也看了一些垂直細分場景下ServerLess架構下的成熟應用和實踐。但是實際上可以看到這些應用場景主要還是集中在互聯(lián)網(wǎng)應用中，即使在互聯(lián)網(wǎng)應用中也是一些相當垂直的場景，比如一些基礎服務能力整合，數(shù)據(jù)采集發(fā)送，事件響應場景，物聯(lián)網(wǎng)垂直應用等。

而對于傳統(tǒng)企業(yè)信息化領域，ServerLess應用很少。

其次，對于一個傳統(tǒng)的IT應用系統(tǒng)，可以說對其進行微服務化和架構改造，但是卻很難在短期做到完全的ServerLess化。

今天重新談這篇文章，還是想對ServerLess無服務器架構里面的一些關鍵內(nèi)容進一步說明，也方便大家理清思路和要點。

ServerLess無服務器架構

首先我們還是先看下對Serverless的一個基礎定義和說明，即：

Serverless是一種構建和管理基于微服務架構的完整流程，允許你在服務部署級別而不是服務器部署級別來管理你的應用部署。它與傳統(tǒng)架構的不同之處在于，完全由第三方管理，由事件觸發(fā)，存在于無狀態(tài)(Stateless)、暫存(可能只存在于一次調(diào)用的過程中)計算容器內(nèi)。

構建無服務器應用程序意味著開發(fā)者可以專注在產(chǎn)品代碼上，而無須管理和操作云端或本地的服務器或運行時。Serverless真正做到了部署應用無需涉及基礎設施的建設，自動構建、部署和啟動服務。

在這里我想再強調(diào)下里面的一些關鍵點。

徹底意義上的從資源到服務

實際在談微服務的時候，我們希望的就是整個云平臺不斷地向上抽象和上移，從IaaS層資源能力提供到PaaS層服務能力提供。

但是實際在應用開發(fā)過程中，并沒有完全做到對資源層的隔離，比如一些自研的基礎組件開發(fā)和部署，一些數(shù)據(jù)庫資源部署，我們?nèi)匀贿€在申請類似虛擬機資源，然后自己進行部署和管理。也就是說沒有做到完整意義上的對資源層透明。

而到了Serverless階段，那就是必須做到完整意義上的服務化，你能夠看到和使用的只能夠是通過API網(wǎng)關暴露給你的API接口服務能力，對于資源層可以做到徹底意義上的不關心。

所以對于Serverless無服務器化這個詞，無服務器化可以理解為無資源化，即你不直接面對資源層，你面對的都是服務能力，去訂購和消費使用API服務能力。

去重的開發(fā)框架和組件依賴

對于Serverless可以理解為微服務的進一步拆分，即將微服務實現(xiàn)的各個能力全部拆分和解耦，每一個服務能力變成無狀態(tài)的API接口能力，這些API接口能力就是一個個的可以通過腳本來實現(xiàn)的云函數(shù)，構成了Serverless架構中的FaaS層。

傳統(tǒng)架構，即使微服務架構仍然可以看到有比較重的微服務開發(fā)框架，有共性底層技術組件依賴等，而這些在Serverless下全部都應該去掉或者轉(zhuǎn)為由云平臺統(tǒng)一提供。

簡單來說如果共性基礎框架這層不去掉，上層就不可能徹底的函數(shù)化。

徹底的無狀態(tài)化

為何徹底函數(shù)化困難?

除了前面談到的有一個共性的技術框架依賴外，另外一個關鍵點就是各個方法和函數(shù)之間的調(diào)用往往存在狀態(tài)，需要做類似會話保持等相關動作。

一旦方法間存在狀態(tài)，那么實際每一個方法或函數(shù)功能的實現(xiàn)就無法做到完全的自我管理，這個不論在前期部署，后續(xù)的彈性伸縮，高可用等各種場景中你都需要去考慮狀態(tài)保持的問題，那么整體架構又變得復雜。

因此在Serverless不斷在強調(diào)事件驅(qū)動，強調(diào)無狀態(tài)，強調(diào)任何一個接口調(diào)完就結束，這個結束不僅僅是不保留狀態(tài)，包括承載FaaS函數(shù)實現(xiàn)的輕量無狀態(tài)容器也可以做到快速的銷毀。

所以你也可以看到無狀態(tài)化是實現(xiàn)Serverless能夠按調(diào)用次數(shù)進行計費的一個關鍵。要實現(xiàn)這個按次計費就必須做到資源層的快速啟動，創(chuàng)建，快速的擴展，銷毀等各種能力。

從微服務到ServerLess無服務器架構

實際上將微服務和ServerLess無服務器架構進行對比，或者將ServerLess作為微服務后續(xù)的發(fā)展趨勢并不合理。

基于上圖可以看到。

ServerLess無服務架構實際是整個云平臺的重心不斷上移，從資源到服務層能力不斷抽象的一個過程。

那么微服務在哪里?

微微服務實際可以理解為PaaS層發(fā)展的第二個階段。對于PaaS層的第一個階段仍然是單體應用和傳統(tǒng)的基于虛擬機進行應用調(diào)度和托管的PaaS平臺，同時類似數(shù)據(jù)庫，消息等技術服務能力也不足夠成熟。

而隨著云原生技術的發(fā)展，特別是云原生中的微服務，容器技術也在不斷發(fā)展。公有云PaaS平臺發(fā)展到了圍繞容器+技術服務為核心的云原生PaaS平臺。在這個過程中傳統(tǒng)的單體應用為了獲得更好的性能和可擴展性，也轉(zhuǎn)變從單體拆分為更小的微服務。

這個發(fā)展階段可以參考下圖：

我們可以將整個演進過程分為三個階段。

在傳統(tǒng)單體架構階段，往往只會使用到云平臺提供的虛擬化資源池，提供彈性計算和彈性存儲能力。應用自己申請?zhí)摂M機，然后安裝環(huán)境，管理環(huán)境。同時應用在開發(fā)完成后也是人工來完成將測試通過的版本部署到虛擬機環(huán)境中去。

而到了云原生PaaS平臺階段，底層的資源池變成了更加輕量化的容器，同時上層的單體已經(jīng)拆分為了多個獨立松耦合的微服務，中間件PaaS層實現(xiàn)兩個能力。

其一是類似K8s實現(xiàn)的容器資源編排和調(diào)度;其二是實現(xiàn)共性的技術服務能力提供，其中包括了數(shù)據(jù)庫，消息，緩存等各種技術服務能力。

為了更好地銜接上層微服務和底層容器云資源，可以通過DevOps持續(xù)集成和交付最佳實踐和工具集的整合，來完成整個從需求，開發(fā)，測試，集成，交付過程的全面自動化。也就是說整個編譯，構建，打包，部署的動作全部由DevOps過程自動完成。

到了ServerLess階段，實際看到又帶來如下變化。

其一是底層的容器變成無狀態(tài)化容器，更加輕量，也更加容易快速創(chuàng)建和銷毀;其二是上層的微服務能力進一步拆分為各個獨立，無狀態(tài)的云函數(shù)或服務;其三是PaaS層的技術服務能力進一步增強，構建完整的BaaS層。

BaaS(Backend as a Service，后端即服務)是指我們不再編寫或管理所有服務端組件，可以使用領域通用的遠程組件(而不是進程內(nèi)的庫)來提供服務。

傳統(tǒng)企業(yè)應用遷移到ServerLess思考

在現(xiàn)階段，Serverless主要應用在以下幾個場景。首先在Web及移動端服務中，可以整合API網(wǎng)關和Serverles服務構建Web及移動后端，幫助開發(fā)者構建可彈性擴展、高可用的移動或 Web后端應用服務。

在IoT場景下可高效地處理實時流數(shù)據(jù)，由設備產(chǎn)生海量的實時信息流數(shù)據(jù)，通過Serverles服務分類處理并寫入后端處理。另外在實時媒體資訊內(nèi)容處理場景里，用戶上傳的音視頻到對象存儲OBS，通過上傳事件觸發(fā)多個函數(shù)，分別完成高清轉(zhuǎn)碼、音頻轉(zhuǎn)碼等功能，滿足用戶對實時性和并發(fā)能力的高要求。

無服務器計算還適合于任何事件驅(qū)動的各種不同的用例，這包括物聯(lián)網(wǎng)，移動應用，基于網(wǎng)絡的應用程序和聊天機器人等。

我曾經(jīng)提到如下觀點：

對于傳統(tǒng)企業(yè)信息化應用來說，由于本身業(yè)務規(guī)則和邏輯實現(xiàn)復雜，同時存在大類的流程，數(shù)據(jù)，應用功能間的協(xié)同和集成。在這種場景下，轉(zhuǎn)到完全的Serverless架構基本沒有任何的可能性。

在這里想轉(zhuǎn)換下思考方式，即對于傳統(tǒng)企業(yè)信息化應用，如果要遷移到ServerLess無服務器化架構需要做哪些準備。

對于這個問題，我準備分幾個點來思考。

第一：BaaS后端即服務能力仍然是傳統(tǒng)方式構建

在這里再次強調(diào)下對于BaaS后端共性服務能力提供這塊，仍然是采用傳統(tǒng)架構或當期的微服務架構方式來提供。

當我們一說到Serverless架構的時候，很容易將思考重心放在FaaS云函數(shù)這層，其原因是在當前的公有云服務下，類似存儲，數(shù)據(jù)，消息等各種BaaS后端服務能力都是云平臺在提供。但是當前去開發(fā)企業(yè)級應用的時候，這個BaaS后端服務含義變化。

即BaaS后端服務不僅僅是技術服務，也包括了共性業(yè)務服務能力。

如果還是用中臺這個詞，你可以理解為企業(yè)共性的業(yè)務中臺和數(shù)據(jù)中臺提供的共性服務能力也是BaaS后端服務的重要組成。

也就說你要開發(fā)企業(yè)級應用，那么先得把BaaS這層做好，否則寸步難行。

第二：徹底的無狀態(tài)化開發(fā)模式

在前面已經(jīng)談到，Serverless架構是一種徹底的無狀態(tài)化架構模式。比如你原來本身就是采用的類似事件驅(qū)動架構在開發(fā)，那么轉(zhuǎn)移到Serverless相當容易。但是如果你原來更多的都是大量長周期事務，大量的狀態(tài)保持場景，那么整個遷移就相當復雜。

無狀態(tài)開發(fā)類似SOA架構思想里面的服務組裝和服務編排，也類似于基于消息事件機制的事件鏈編排模式。但是核心都是無狀態(tài)，你需要通過其它方式，比如類似token傳遞來保持狀態(tài)，通過消息機制來暫存狀態(tài)等。

第三：面向服務開發(fā)而非面向資源開發(fā)

這個也是我在前面就強調(diào)的點，如果后續(xù)要轉(zhuǎn)移到Serverless架構模式，那么你現(xiàn)在所有的開發(fā)指導思想都應該是面向服務而非面向資源。

你不要再去考慮申請訂購虛擬機或容器資源，你需要考慮的是將你的技術需求轉(zhuǎn)換為對技術服務的需求;將你的業(yè)務需求轉(zhuǎn)變?yōu)橐粋€個獨立的無狀態(tài)功能函數(shù)。

在前面我就談到如果你現(xiàn)在上云過程中，都還是在自己申請?zhí)摂M機安裝數(shù)據(jù)，安裝消息中間件，那么在后期就更難以遷移到ServerLess模式。包括在前面對騰訊云ServerLess簡單驗證中也可以看到，當你需要數(shù)據(jù)持久化存儲的時候，你不是去申請了一個虛擬機自己安裝Mysql數(shù)據(jù)庫，而是在基礎服務里面有一個數(shù)據(jù)庫服務，你直接使用這個服務能力來創(chuàng)建數(shù)據(jù)庫集合即可。

對于所有開發(fā)人員來說，面向服務開發(fā)是一個相對重要的內(nèi)容。

第四：開發(fā)團隊和人員分工

進入到ServerLess無服務器階段的時候，可以看到開發(fā)團隊人員往往重新進行分工，這個分工可以看做是當前微服務前后端分工的一個分支。

即一個團隊專門來做BaaS后端服務這層，這個團隊仍然是采用傳統(tǒng)方法或者當前的微服務架構來進行開發(fā)和持續(xù)集成交付。而對于另外一個開發(fā)團隊則面向應用和用戶，面向后端提供的API接口服務，這個開發(fā)團隊完全可以由當前的前端開發(fā)人員來組成。

也就是說在后端BaaS服務穩(wěn)定后，對于新應用的創(chuàng)建更多就是前端應用，F(xiàn)aaS云函數(shù)的編寫，前端開發(fā)人員可以更加關注業(yè)務場景和規(guī)則的實現(xiàn)，更多的是去組裝和組合BaaS層已有的業(yè)務服務和技術服務能力來滿足各種需求。

可以舉個簡單的例子。

對于傳統(tǒng)的OA辦公自動化場景里面，當組織，權限，人員，流程這些共性的后端服務能力具備后，對于前端各種類似請假單，出差申請單這種功能的開發(fā)是完全可以實現(xiàn)云函數(shù)化的。這個時候前端應用的開發(fā)更類似于當前的低代碼開發(fā)平臺完成的事情。

當前標題：云原生技術-從微服務到ServerLess無服務器架構演進思考
網(wǎng)站路徑：http://www.dlmjj.cn/article/djidjjc.html