1.3.1　Serverless的技術創新

Serverless基于事件驅動的架構，它的編程模型和運行模式簡化了開發模式，融入了不可變基礎設施的最佳實踐。

1. Serverless是事件驅動架構的延伸

Serverless更容易實現事件驅動的應用。在分布式系統中，請求/響應的方式和事件驅動的方式都存在。請求/響應是指客戶端會發出一個請求并等待一個響應，該過程允許同步或異步方式。雖然請求者可以允許該響應異步到達，但對響應到達的預期本身就在一個響應和另一個響應之間建立了直接的依賴關系[1]。事件驅動的架構是指在松耦合系統中通過生產和消費事件來互相交換信息。相比請求/響應的方式，事件的方式更解耦，并且更加自治。例如，在圖片上傳后進行轉換處理的場景，以往需要一個長時運行的服務去輪詢是否有新圖片產生，而在Serverless下，用戶不需要進行編碼輪詢，只需要通過配置將對象存儲服務中的上傳事件對接到函數即可，文件上傳后會自動觸發函數進行圖片轉換。

Serverless架構的基本單元從微服務變為函數。微服務的每個API的非功能屬性有差異，比如對性能、擴展性、部署頻率的要求并不相同，進一步拆分的確有助于系統的持續演進，但相應會帶來指數級的服務數量增長，導致微服務的基礎設施和運維體系難以支撐。Serverless架構可以將微服務的粒度進一步降低到函數級，同時不會對基礎設施和運維產生新的負擔，只是增加了少量的函數管理成本，相比其帶來的收益這是完全可以接受的。

基于Serverless更容易構建3-Tier架構應用。3-Tier是指將應用分為3層，即展示層、業務層及數據層，并且會部署在不同的物理位置。如Web應用，其展示層和業務層在物理層面往往會在一起部署。以圖1-9中的寵物商店應用為例，在基于微服務的部署視圖中，其業務層和展示層在一起部署；而在基于Serverless的部署視圖中，展示層可以托管在對象存儲服務中，業務層由FaaS托管，數據層由云數據庫托管，實現了3-Tier在物理上的獨立部署。同時，各層獨立擴展，技術獨自演進。

2. Serverless簡化了開發模式

微服務提供了豐富的框架，方便開發者進行開發，但同時也增加了開發者的認知負擔，同樣是使用Java，基于Serverless開發服務，開發者只需掌握Java的基礎特性、函數編程框架及BaaS的SDK即可，如圖1-10所示。

函數的編程框架相比Spring/SpringBoot要簡單很多，開發者只需了解輸入輸出處理（通常為JSON）及如何處理業務邏輯。如圖1-11所示，Serverless系統可以是1∶1的觸發模型，每個請求被一個單獨的函數實例處理，每個實例可以被視為一個單獨的線程，系統自動根據請求數量擴展函數實例，開發者不用理解Java的并發編程也可以輕松實現對高并發應用的支持。

基于函數的編程模型，可以繼續對數據進行抽象操作。例如，Azure Function提供的Data Binding功能，允許開發者用一套配置和一種編程模型操作不同存儲服務的數據，讓開發服務變得更加簡單，降低開發人員的認知負擔，進而提升開發效率。

3. Serverless是不可變基礎設施的最佳實踐

Serverless直接以代碼方式部署，開發者不用再考慮容器鏡像打包、鏡像維護等問題。系統通常在部署時重新創建函數實例，在不使用時回收實例，每次處理用戶請求的可能都是全新的實例，降低了因為環境變化出錯的風險。而這些部署及變更的過程，對用戶來說只是更新代碼，其復雜度相比使用容器及Kubernetes大大降低。Serverless在擴展性方面也具有優勢。FaaS和BaaS對開發人員來說沒有“預先計劃容量”的概念，也不需要配置“自動擴展”觸發器或規則。縮放由Serverless平臺自動發生，無須開發人員干預。請求處理完成后，Serverless平臺會自動壓縮計算資源，當面對突發流量時，Serverless可以做到毫秒級擴容，保證及時響應。

基于Serverless的服務治理也更簡單。例如，通過API網關服務可以對函數進行SLA（服務水平協議）設置限流，函數請求出錯后會自動重試，直至進入死信隊列，開發者可以針對死信隊列進行重放，最終保證請求得到處理。

Serverless平臺默認對接了監控、日志、調用鏈系統，開發者無須再費力單獨維護運維的基礎設施。雖然當前Serverless的監控指標并不如傳統的監控指標豐富，但是其更關注的是應用的黃金指標，如延遲、流量、錯誤和飽和度。這樣可以減少復雜的干擾信息，使開發者專注在用戶體驗相關的指標上。