第一代

在第一代微服務架構中，應用除了需要實現業務邏輯之外，還需要自行解決上下游定址、通訊及容錯等問題。隨著微服務規模的逐漸擴大，服務定址邏輯的處理正變得越來越複雜，哪怕是同一種程式語言的另一個應用，上述微服務的基礎能力也需要重新實現一遍。

第二代

在第二代微服務架構中, 旁路服務註冊中心作為協調者完成服務的自動註冊和發現，服務之間的通訊及容錯機制開始模組化， 並形成獨立的服務框架。 但是， 隨著服務框架內功能的日益增多，複用不同程式語言開發的基礎功能就顯得十分困難，這也意味著微服務的開發人員將被迫繫結在某種特定語言之上，從而違背了微服務的敏捷送代原則。

第三代: 服務網格

2016年出現了第三代微服務架構, 即服務網格( Service Mesh)。原來被模組化到框架裡的微服務基礎能力，從一個SDK演進成為一個獨立的程序 Sidecar(邊車)。這個變化使得第二代架構中的多語言支援問題得到了徹底解決, 微服務基礎能力演進和業務邏輯迭代徹底解耦。第三代微服務架構就是雲原生時代的微服務架構,邊車程序開始接管微服務應用之間的流量, 承載第二代微架構中服務框架的功能, 包括服務發現、呼叫容錯以及豐富的服務治理功能，例如權重路由、灰度路由、流量重放、服務偽裝等。

第四代: 多執行時微服務架構

隨著AWS Lambda的出現，部分應用開始嘗試利用serverless技術來構建微服務, 第四代微服務架構出現。在第四代微服務架構中，微服務由一個應用進一步簡化為微邏輯(Micrologic), 這也對邊車模式提出了更高要求，更多可複用的分散式能力從應用中剝離，並下沉到邊車中，例如狀態管理、 資源繫結、鏈路追蹤、事務管理、安全等。同時，開發側開始提倡面向 localhost 程式設計的理念，並提供標準API遮蔽底層資源、服務、基礎設施之間的差異，以進一步降低微服務的開發難度。第四代微服務架構就是目前業界提出的多執行時微服務架構(Multi-Runtime Microservice)。

參考：《阿里云云原生架構實踐》

公眾號: 全球技術精選