作者 | Raja Saravanan

編譯 | EthanServerless

已成為企業在數字化、現代化升級過程中越來越流行的范式，不管是國內的阿里云、騰訊云、華為云，還是國外的亞馬遜云科技，微軟等云計算廠商，都正在大力投入無服務器計算領域。由于 Serverless 提供了一個微型的架構，終端客戶無需部署、配置或管理服務器服務，而且代碼運行所需要的服務器服務皆由云端平臺來提供，這就為企業提高了靈活性，同時降低了運營開銷和成本。但與之而來的問題在于，Serverless 體系結構的高度分布式特性，要求開發人員重新思考其應用程序設計和開發方法。本文介紹幾個最佳實踐設計模式，以饗讀者。

?眾所周知，Serverless 是基于微服務體系結構的自然選擇。以基于 AWS 的 Serverless 應用程序為例，它依賴于 AWS Lambda 函數，這些函數在設計上是無狀態和短暫的，Lambda 函數被設計為運行小塊代碼以響應其他服務發出的事件。Lambda 還與一系列可用于實現分布式系統中常見模式的托管服務集成，如消息隊列（Amazon 簡單隊列服務）、API（Amazon API 網關）和事件流（Amazon Kinesis）。這將有助于將構建微服務過程中的痛點最小化。

為工作負載選擇適當的設計模式 

?1、扼殺器（Strangler）模式?Strangler 模式允許開發人員用微服務（可以用一個或多個 Lambda 函數實現）逐步替換其單體組件，而不是完全關閉或一次性替換。

Strangler 模式

此模式使用 strangler（如API網關）來接受對遺留系統的傳入請求。然后，再將它們路由到遺留應用程序或新的 Serverless 應用。因為客戶端只與 strangler 交互，所以他們不知道后端服務受到影響。一旦整個遺留系統被重構，并且所有流量都被路由到新應用程序，則可以安全地棄用前者。

2、聚合器（Aggregator）模式

在基于微服務的架構中，客戶端通常需要調用多個后端服務來執行操作。由于這些調用發生在網絡上，客戶端和微服務之間的聊天通信可能會增加應用程序延遲，特別是在帶寬有限的情況下。

?聚合器模式

聚合器模式通過使用單個 Lambda 函數來接受所有客戶端請求，減少了客戶端需要進行的調用數量。然后，Lambda 函數將請求轉發給適當的微服務和第三方 API，來聚合它們的結果，并向客戶端返回單個響應。

3、狀態機模式（State Machine）?構建應用程序時，業務工作流往往會變得非常復雜。AWS 中的有一個比較好用的“Step”功能，可以用于協調涉及多個微服務的復雜工作流。“Step”功能包括內置的狀態管理、分支、錯誤處理和重試功能，無需編寫樣板代碼。

?狀態機模式

4、Saga 模式

在基于微服務的應用中，每個微服務通常都有自己的數據庫，其中包含與其他微服務數據庫中的數據密切相關的數據。Saga 模式通過協調互連微服務中的一系列本地事務來確保數據一致性。一旦微服務執行其本地事務，它就會觸發鏈中的下一個服務執行其事務。如果一個事務在此過程中失敗，將啟動一系列補償事務，以回滾以前事務中所做的更改。

?Saga 模式

Saga 模式可以通過 choreography 或 orchestration 來實現。在 choreography 模型中，每個服務發布一個事件，觸發下一個服務運行。而在orchestration 中，由中央協調器管理整個事務鏈。

5、斷路器（Circuit breaker）模式

在分布式系統中，在滿足一個請求時涉及多個服務，思考如何處理服務故障是至關重要的。有些問題（如網絡延遲）是間歇性的，可以自行解決，可能只需上游服務的重調用即可。然而，更嚴重的問題或停機，就需要主動干預，解決所需的時間成本都是不確定的。在這些情況下連續重試可能會消耗關鍵資源，并導致依賴同一資源池的其他服務匱乏，這可能導致災難性級聯故障。

?Circuit breaker 模式

斷路器模式允許使用鍵值存儲來跟蹤請求故障和斷路器狀態，而且通過 Lambda 函數來決定是否需要基于故障計數對受影響的服務進行后續調用，從而在系統中構建容錯能力。

總結 

毫無疑問，云計算正在悄無聲息的影響著改變著我們的生活。不論是商業，還是科研，Serverless 計算正在成為當下云計算的主流發展方向之一。于開發者而言，Serverless 的部署比較簡單，但前提是，我們應該借鑒最佳實踐模式來設計，減少不必要的資源浪費。

原文鏈接：

https://medium.com/@raja.sk.saravanan/architect-your-microservices-in-serverless-with-right-design-pattern-60ebe674968