對于云原生解決方案中涉及到的微服務，DevOps，容器云和ServiceMesh等內容，在前面很多文章都已經談到過，今天準備談下對Serverless架構的一些理解。
實際上要完全理解Serverless無服務器架構是一件相對困難的事情，包括到現在我的認知里面仍然認為這種架構是無法滿足傳統IT應用系統的架構轉型和遷移的，只能夠應用到一些特定的場景。
對Serverless架構基礎概念的理解
首先我們還是先看下對Serverless的一個基礎定義和說明，即：
Serverless是一種構建和管理基于微服務架構的完整流程，允許你在服務部署級別而不是服務器部署級別來管理你的應用部署。它與傳統架構的不同之處在于，完全由第三方管理，由事件觸發，存在于無狀態（Stateless）、暫存（可能只存在于一次調用的過程中）計算容器內。
構建無服務器應用程序意味著開發者可以專注在產品代碼上，而無須管理和操作云端或本地的服務器或運行時。Serverless真正做到了部署應用無需涉及基礎設施的建設，自動構建、部署和啟動服務。
注：這里必須搞清和容器化paas的區別點，要知道容器PaaS本身也是不用關心服務器的，但是可以看到在Serverless是一種更小更靈活的動態容器這是其一，其次是真正到了服務級別，而不是部署包級別。因為在原來的部署包級別就一定還是會存在編譯打包部署，要將部署包部署到類似tomact，jboss中間件的過程。而到了Serverless階段功能都是FaaS粒度更新，沒有打包構建動作，你也不用關系應用中間件。
Serverless由開發者實現的服務端邏輯運行在無狀態的計算容器中，它由事件觸發， 完全被第三方管理，其業務層面的狀態則被開發者使用的數據庫和存儲資源所記錄。
關鍵兩類服務-FaaS和BaaS
1.FaaS（Function as a Service，函數即服務）
要理解這個概念，首先還是要說明下傳統的一個軟件應用功能是如何開發和交付的。
即我們首先是在本地開發環境和IDE里面建設一個項目，然后建立相應的代碼文件，編寫代碼，完成后進行編譯構建，形成一個部署包。然后將部署包部署到中間件或容器里面，部署完成后應用就暴露一個訪問地址，我們通過該地址訪問該應用功能。
那么到FaaS里面是什么概念呢？
首先就是沒有了中間件容器的概念，或者說這個容器對你不可見，最終的程序運行在哪個容器里面，或者說中間件容器長什么樣子你根本不需要知道。
其次就是沒有編譯構建動作，對于寫好的程序不需要進行編譯和構建，打包成一個部署包進行部署，寫好的程序即交付到Serverless環境后即可以運行。如果你不需要運行了，支撐程序運行的環境或容器也可以快速的銷毀。
再次，我們在本地開發環境寫一個應用功能，不可避免都會涉及到類似SSH三層框架，類似SpringCloud微服務開發框架等。但是到了Serverless階段你可以看到沒有很重的開發框架這個說法，也就是說開發框架在FaaS里面不再存在。那么原來你是通過開發框架開發一個應用，這個應用比如有20個功能點，那么到了FaaS這個階段，對應的就是20個獨立的代碼片段實現20個功能點。
以上就是FaaS和傳統應用的關鍵區別點。
FaaS意在無須自行管理服務器系統或自己的服務器應用程序，即可直接運行后端代碼。其中所指的服務器應用程序，是該技術與容器和PaaS（平臺即服務）等其他現代化架構最大的差異。FaaS可以取代一些服務處理服務器（可能是物理計算機，但絕對需要運行某種應用程序），這樣不僅不需要自行供應服務器，也不需要全時運行應用程序。
FaaS產品不要求必須使用特定框架或庫進行開發。在語言和環境方面，FaaS函數就是常規的應用程序。例如AWS Lambda的函數可以通過JAVAscript、Python以及任何JVM語言（Java、Clojure、Scala）等實現。然而Lambda函數也可以執行任何捆綁有所需部署構件的進程，因此可以使用任何語言，只要能編譯為Unix進程即可。
FaaS中的函數可以通過供應商定義的事件類型觸發。對于亞馬遜AWS，此類觸發事件可以包括S3（文件）更新、時間（計劃任務），以及加入消息總線的消息（例如Kinesis）。通常你的函數需要通過參數指定自己需要綁定到的事件源。大部分供應商還允許函數作為對傳入Http請求的響應來觸發，通常這類請求來自某種該類型的API網關（例如AWS API網關、Webtask）。
2.BaaS（Backend as a Service，后端即服務）
BaaS（Backend as a Service，后端即服務）是指我們不再編寫或管理所有服務端組件，可以使用領域通用的遠程組件（而不是進程內的庫）來提供服務。
BaaS看起來和我們常說的PaaS平臺感覺很類似，那么來看下兩者的區別。
對應PaaS平臺我們看到實際上提供的是應用托管，應用自動部署，后續資源彈性擴展調度能力。即前提是有部署包，再調用PaaS平臺的能力將應用部署到托管的中間件和容器里面。這里面有兩個重點，即：其一是有部署包，其二是有中間件和容器的概念。
但是到了BaaS可以看到，已經沒有編譯構建和部署包的概念，對于容器和應用中間件概念也不再有或對開發者不可見。而實際上BaaS需要提供的是什么呢？即代碼片段編寫完成上傳后運行代碼片段的能力。
但是實際上單獨的一個代碼片段本身很難實現一個業務場景功能。
比如我們需要做一個網頁抓取功能，那么在實現這個功能的時候可能涉及到圖片存儲，全文檢索，對象存儲幾個關鍵技術服務能力。而這些技術能力就是BaaS平臺提供，即類似于我們傳統PaaS平臺里面說的技術服務能力平臺。
那么代碼片段做什么事呢？即通過代碼片段對BaaS層提供的API能力進行組合或編排，這樣就可以完成一個簡單的業務場景和功能實現。
例如我們看當前亞馬遜提供的Serverless服務應用場景圖，如下：
可以看到BaaS提供類似網關，消息通知，對象存儲等各種技術服務能力，而前端的FaaS通過對這些技術服務能力進行組合完成一個業務功能實現。
在AWS用Serverless創建一個應用一般會涉及到如下內容
- API Gateway 網關服務，實現我們需要的網絡RESTful接口
- Lambda 函數計算，實現我們需要的平行擴展業務運算
- Dynamodb數據庫，實現我們需要的“單機”無限性能數據庫
- S3服務，實現前端靜態頁面的存儲
通過 Amazon API Gateway，您可以根據在 AWS Lambda 中運行的代碼快速、輕松地創建自定義 API，然后通過 API 調用 Lambda 代碼。Amazon API Gateway 可以用您的賬戶執行 AWS Lambda 代碼，也可以在 AWS 外部通過可公共訪問的 HTTP 端點來調用 AWS Elastic Beanstalk、Amazon EC2 或 Web 服務。利用 Amazon API Gateway 控制臺，您可以定義 REST API 及其關聯的資源和方法、管理 API 生命周期、生成客戶端 SDK，并能查看 API 指標。
Serverless架構適合的場景
在現階段，Serverless主要應用在以下幾個場景。首先在Web及移動端服務中，可以整合API網關和Serverles服務構建Web及移動后端，幫助開發者構建可彈性擴展、高可用的移動或 Web后端應用服務。
在IoT場景下可高效的處理實時流數據，由設備產生海量的實時信息流數據，通過Serverles服務分類處理并寫入后端處理。另外在實時媒體資訊內容處理場景里，用戶上傳的音視頻到對象存儲OBS，通過上傳事件觸發多個函數，分別完成高清轉碼、音頻轉碼等功能，滿足用戶對實時性和并發能力的高要求。
無服務器計算還適合于任何事件驅動的各種不同的用例，這包括物聯網，移動應用，基于網絡的應用程序和聊天機器人等。這里簡單說兩個場景，方便大家思考。
場景一：應用負載有顯著的波峰波谷
Serverless 應用成功與否的評判標準并不是公司規模的大小，而是其業務背后的具體技術問題，比如業務波峰波谷明顯，如何實現削峰填谷。一個公司的業務負載具有波峰波谷時，機器資源要按照峰值需求預估；而在波谷時期機器利用率則明顯下降，因為不能進行資源復用而導致浪費。
業界普遍共識是，當自有機器的利用率小于 30%，使用 Serverless 后會有顯著的效率提升。對于云服務廠商，在具備了足夠多的用戶之后，各種波峰波谷疊加后平穩化，聚合之后資源復用性更高。比如，外賣企業負載高峰是在用餐時期，安防行業的負載高峰則是夜間，這是受各個企業業務定位所限的；而對于一個成熟的云服務廠商，如果其平臺足夠大，用戶足夠多，是不應該有明顯的波峰波谷現象的。
場景二：典型用例 - 基于事件的數據處理
視頻處理的后端系統，常見功能需求如下：視頻轉碼、抽取數據、人臉識別等，這些均為通用計算任務，可由函數計算執行。開發者需要自己寫出實現邏輯，再將任務按照控制流連接起來，每個任務的具體執行由云廠商來負責。如此，開發變得更便捷，并且構建的系統天然高可用、實時彈性伸縮，用戶不需要關心機器層面問題。
具體參考：
https://blog.csdn.net/cc18868876837/article/details/90672971
微服務和Serverless關系和融合
當我們比較微服務和Serverless時，實際上比較的是微服務和FaaS。直觀上來看，微服務和FaaS的差別在于粒度，而要實現FaaS，首先必須將單體應用演進到微服務，然后才能進一步地分解到函數級別，實現FaaS。
微服務和Serverless不完全是同一層面的事物，實際上不應該放在一個層面進行比較。
原因就是微服務仍然是傳統IT架構演進的一個容易理解過程，即原來傳統的單體應用拆分為微服務模塊，從數據庫，邏輯層都進行拆分，都能夠獨立自治。拆分后的微服務可以基于容器進行部署和管理。
但是微服務并沒有強調傳統SOA我們經常說的識別可重用的服務接口，基于服務接口進行應用功能的組裝。
在這個意義上可以看到Serverless說成是SOA分層架構思想的進一步演進更加合適。
這個演進過程出現了兩個關鍵點。
- 其一就是共性技術服務能力全部轉變為BaaS層的API服務接口
- 其二是前端應用功能開發轉化為代碼片段和對API能力的組合
以上這兩點才是Serverless架構到重點，因此可以說傳統架構朝微服務架構演進是順理成章的一個漸進過程，但是不能說微服務到Serverless演進是平滑的。
Serverless比微服務粒度打的更細，完全到了功能點級，實際上可以看到后續管控運維的復雜度是增加了的，對于類似單一功能App，微信小程序，定向數據采集等適合，但是對于復雜應用系統暫時不適合。包括我們看到企業內部復雜業務系統，當前轉微服務架構本身就已經很吃力。一拆分一定會帶來集成的問題，監控運維的問題，事務一致性的問題。
注意對于Serverless不僅僅是無服務器，是整體架構設計的概念都弱化了，同時應用開發框架的概念也隨著弱化，沒有重的開發框架和底層平臺，也沒有編譯和部署概念。
在已有的API服務能力都用傳統方式提供出來后，可以看到對于Serverless更加適合用來做前端應用的組合和輕量級編排，通過FaaS來實現對各類第三方API服務能力的整合完成要給特定功能。
比如你要做一個簡單的圖像處理程序，那么圖像采集，圖像識別和匹配，圖像存儲都可以調用獨立的第三方API接口服務來完成。
在Serverless后，可以看到對開發人員技能要求進一步降低，更不需要大家都去做全棧工程師，開發人員也可以花更多的精力來關注業務場景和業務需求的理解和實現。同時在Serverless后也可以看到，小功能的開發和交付周期會更快更加敏捷。
微服務和Serverless相互融合
在前面我們談到了BaaS層，對于各大公有云服務商來說，提供的BaaS層更多的是類似消息，緩存，對象存儲，網關等技術服務API能力接口，而對于傳統業務系統需要提供的可復用業務能力接口是服務提供的。
你也可以理解為BaaS可以提供技術中臺API，但是服務提供業務中臺API。
因此如果你采用Serverless方式來構建傳統業務應用功能，你會發現一些業務后端API能力并不具備，在這種情況下你完全可以采用微服務的方式開發業務API服務接口能力，然后暴露給前端FaaS層使用。即我們說的構建方式為：
完整業務應用功能 = 前端FaaS代碼組合+（后端BaaSAPI+后端業務微服務API）
通過這種方式，一些簡單的業務功能場景我們就可以遷移到采用Serverless來進行開發。但是要做到一個傳統IT系統應用全部功能遷移到Serverless仍然相當困難。因為傳統IT系統，業務微服務能力往往才是主體能力。
進一步對Serverless架構關鍵思想理解
首先再回顧下對Serverless無服務器架構的一個基礎說明。
Serverless是一種構建和管理基于微服務架構的完整流程，允許你在服務部署級別而不是服務器部署級別來管理你的應用部署。它與傳統架構的不同之處在于，完全由第三方管理，由事件觸發，存在于無狀態（Stateless）、暫存（可能只存在于一次調用的過程中）計算容器內。構建無服務器應用程序意味著開發者可以專注在產品代碼上，而無須管理和操作云端或本地的服務器或運行時。Serverless真正做到了部署應用無需涉及基礎設施的建設，自動構建、部署和啟動服務。
過去是“構建一個框架運行在一臺服務器上，對多個事件進行響應”，Serverless則變為“構建或使用一個微服務或微功能來響應一個事件”，做到當訪問時，調入相關資源開始運行，運行完成后，卸載所有開銷，真正做到按需按次計費。這是云計算向縱深發展的一種自然而然的過程。
Serverless無服務器架構的一些關鍵理解
通過拆分實現對應用基礎設施的進一步弱化(中間件，容器，開發框架）
首先可以看到Serverless架構下本身就體現了微服務，而且這種微服務API的粒度更加細，更加小，一個API往往僅僅能夠完成一個微功能。因此不再像傳統應用必須是一個大的組件模塊，實現多個功能并打包在一起。
大的功能拆分為微功能-》微功能本身拆分為無狀態的微服務API
在完成了這種拆分后，要實現一個大功能那么就是對諸多的微服務API的的組裝過程。
我們還是從傳統的云平臺說起，在傳統的應用開發和云平臺模式下，我們開發一個應用還是能夠明確的感受到虛擬機，感受到中間件容器資源，同時應用開發必須依托一個很重的開發框架，類似springcloiud，類似傳統的ssh框架等等。
但是新架構下可以看到沒有復雜的開發框架，也沒有重的中間件容器，只有一個個新粒度的微服務API，微功能的實現，這些實現也不存在傳統的打包和部署動作。也就是說整個軟件的開發過程實現完全的面向服務化，你可以使用第三方已有的服務，你開發完成的微功能也是服務，你呈現給用戶的是多個服務的串聯和組裝。
在這種場景下沒有任何的中間件資源需要你去關心和維護，類似傳統模式下我們可能需要關心和運維我們的數據庫，關心和運維我們的Tomcat容器服務器，我們有復雜的編譯構建，打包部署動作，而這些在無服務器架構模式下都沒有了。體現出現的是函數或事件，而函數本身也是服務。
傳統云平臺計費模式的一大轉變-真正實現使用次數來計費
這個可以講是Serverless無服務器架構帶來的第二大轉變，真正實現按使用次數計費。在傳統云平臺模式下可以看到，虛擬機或計算資源是固定分配給你了的，即使某天你的業務系統沒有任何的訪問請求，你也需要給云服務商繳費。
你為何需要固定分配的資源，簡單來說還是你拿到一個虛擬機后，你還有很多的應用基礎設施需要在虛擬機上安裝部署和搭建，比如我們前面講的中間件容器，網關，基礎框架包，應用部署包等。而這些應用基礎設施越重就越難以靈活的響應。
而到了Serverless無服務器架構下可以看到應用已經拆分為足夠細的微功能或API，而這些微功能的運行本身需要極少的輕量化資源即可，因此我們能夠實現對類似動態容器能力，快速申請獲取容器資源，使用完成后快速的銷毀釋放資源。
所以你可以看到實現微服務化，實現FaaS或聲明式API編程是走向按次動態收費的基礎。
- Serverless 是真正的按需使用，請求到來時才開始運行
- Serverless 是按運行時間和內存來算錢的
- Serverless 應用嚴重依賴于特定的云平臺、第三方服務
對于AWS 官方對于 Serverless 的介紹是這樣的：無服務器架構是基于互聯網的系統，其中應用開發不使用常規的服務進程。相反，它們僅依賴于第三方服務（例如AWS Lambda服務），客戶端邏輯和服務托管遠程過程調用的組合。
在Serverless架構下開發人員不再關心底層邏輯
簡單來說最早的開發往往會涉及到操作系統，進一步的會涉及到數據庫，應用中間件容器，然后是各類的開發框架，而這些在Serverless架構下開發人員不再關心，更多的是關心業務場景和業務功能的實現。
這里的不關心包括兩個方面，一個是不會直接去安裝部署和配置這些中間件，其次是不用去關心這些中間件或容器運行在哪里？更加不用自己運維這些中間件容器。簡單來說，你真正要運維的就是你實現的服務API接口，你實現的事件或函數。
目前業界的各類 Serverless 實現按功能而言，主要為應用服務提供了兩個方面的支持：函數即服務（Function as a Service，FaaS）以及后臺即服務（Backend as a Service，BaaS）。
而實際上我們看到最難的仍然是在類似數據庫等原來的中間件資源能力的服務化，即我們對數據庫的需求也變成了一個個可以拆分的微服務API請求。比如我們僅僅是一個爬蟲采集后的數據存儲這種單一場景往往比較容易實現，但是類似企業信息化系統這種底層復雜數據模型，強關系和強事務場景下往往就很難實現徹底意義上的數據庫能夠服務化。
正是這個原因我們看到類似Serverless架構前期更加適用于移動互聯網，物聯網IOT，面向互聯網的聚合類應用實現上面，而對于傳統企業信息化應用軟件至少短期難看很難適用。
傳統企業信息化應用轉到Serverless
對于這點，實際上我在前面已經談到，對于傳統企業信息化應用來說，由于本身業務規則和邏輯實現復雜，同時存在大類的流程，數據，應用功能間的協同和集成。在這種場景下，轉到完全的Serverless架構基本沒有任何的可能性。
我們可以看到，對于SOA架構思想出來很多年，我們早就希望將傳統企業內部新和應用的開發基于ESB總線暴露的共享服務能力進行BPEL服務編排來完成，即使這點對于絕大部分企業都很難真正做到和實施。
可以看到Serverless是SOA架構思想應用的極致狀態。
由于企業應用本身的業務復雜性，數據關聯和耦合性，集成復雜性，事務強一致性要求等。很難真正實現將傳統IT應用完全的Serverless化。
那么唯一可行的應用場景，即是我前面談到的，對于一些簡單的功能開發，我們可以基于技術中臺和業務中臺暴露的API服務能力，進行前端的代碼片段組裝來完成。但是前提仍然是需要首先開發業務微服務模塊，并暴露API服務能力接口。
對于企業內的信息化，在企業傳統IT架構轉型過程中，重點還是云原生里面的微服務，服務網格和DevOps幾個關鍵能力。即首先是微服務化拆分，其次通過服務網格去中心化，再次通過Devops實現和云端的快速對接和持續交付能力。
頭條號：@人月聊IT，分享SOA，微服務，DevOps和云原生相關技術文章。
