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

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

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

而對于傳統企業信息化領域，ServerLess應用很少。

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

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

ServerLess無服務器架構

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

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

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

在這里我想再強調下里面的一些關鍵點。

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

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

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

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

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

去重的開發框架和組件依賴

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

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

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

徹底的無狀態化

為何徹底函數化困難?

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

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

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

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

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

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

基于上圖可以看到。

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

那么微服務在哪里?

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

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

這個發展階段可以參考下圖：

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

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

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

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

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

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

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

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

傳統企業應用遷移到ServerLess思考

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

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

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

我曾經提到如下觀點：

對于傳統企業信息化應用來說，由于本身業務規則和邏輯實現復雜，同時存在大類的流程，數據，應用功能間的協同和集成。在這種場景下，轉到完全的Serverless架構基本沒有任何的可能性。

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

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

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

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

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

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

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

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

第二：徹底的無狀態化開發模式

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

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

第三：面向服務開發而非面向資源開發

這個也是我在前面就強調的點，如果后續要轉移到Serverless架構模式，那么你現在所有的開發指導思想都應該是面向服務而非面向資源。

你不要再去考慮申請訂購虛擬機或容器資源，你需要考慮的是將你的技術需求轉換為對技術服務的需求;將你的業務需求轉變為一個個獨立的無狀態功能函數。

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

對于所有開發人員來說，面向服務開發是一個相對重要的內容。

第四：開發團隊和人員分工

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

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

也就是說在后端BaaS服務穩定后，對于新應用的創建更多就是前端應用，FaaS云函數的編寫，前端開發人員可以更加關注業務場景和規則的實現，更多的是去組裝和組合BaaS層已有的業務服務和技術服務能力來滿足各種需求。

可以舉個簡單的例子。

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