摘要：相比於傳統的微服務架構，雲原生和 serverless 技術更加靈活、高效，能夠更好地滿足用戶的需求。 本文分享自華為雲社區《《鳳凰架構》學習和思考——雲原生時代的服務架構演進史》，作者：breakDawn。 隨著雲原生的概念越來越火，服務的架構應該如何發展和演進，成為很多程式員關心的話題。大 ...
摘要：相比於傳統的微服務架構，雲原生和 serverless 技術更加靈活、高效，能夠更好地滿足用戶的需求。
本文分享自華為雲社區《《鳳凰架構》學習和思考——雲原生時代的服務架構演進史》，作者：breakDawn。
隨著雲原生的概念越來越火，服務的架構應該如何發展和演進，成為很多程式員關心的話題。大名鼎鼎的《深入理解java虛擬機》一書作者於21年推出了新作《鳳凰架構》，從這本書中可以看到當前時下很多最新的技術或者理念。
一、服務架構演進史
1.1原始分散式時代
DCE（Distributed Computing Enviroment） 分散式運算環境。
DCE的設計主旨：“開發人員不必關心服務是遠程還是本地，都能夠透明地調用服務或者訪問資源”
是很早由OSF指定的分散式技術體系理論，解答了很多問題，例如：
- 遠程服務在哪？——對應服務發現
- 要部署多少個？——對應負載均衡
- 請求超時怎麼辦？——對應熔斷、隔離、降級
- 方法參數和結果如何表示？——對應序列化方式
- 信息如何傳入？——對應傳輸協議選型
- 服務許可權？——對應認證、授權方案
- 怎麼保證不同機器間的狀態最終一致？——對應分散式數據一致性
但最終發現解決這些問題的代價 遠超 分散式所帶來的收益，在DCE剛提出的年代（80年代），機器資源並沒到那個程度, 於是暫時被擱置了。
1.2 單體系統
單體系統並不一定就代表是壞的，不好的。
單體架構的好處
如果是相同資源的前提下， 單體系統的性能是比分散式要高的。所有數據都是進程內通信，且開發、部署、測試都基於同一個對象進行處理，更加方便。單體系統中的代碼一般也是做好了分層、分模塊的，也是易於敏捷開發和迭代的。
單體架構的壞處
然而如果單體系統中一部分代碼出現缺陷， 可能直接把進程空間耗光，或者直接打崩整個進程，也沒有辦法針對某個代碼模塊做單獨的升級或者更新。因此當系統規模較小的時候，單體系統有獨特的優勢。系統規模越來越大， 則要求各功能模塊能夠自治和隔離，減少爆炸範圍。
從“追求儘量不出錯”到“追求出錯是必然”，是微服務架構挑戰並取代單體架構的底氣所在。
1.3 SOA——面向服務架構
SOA（Service-Oriented-Architecture）叫做面向服務的架構，類似於各服務之間協議和通信方式高度一致性，各服務遵循完全相同的消息協議和管理機制。
終極目標是總結出一套自上而下的軟體研發方法論，最後新廠家要開發系統時，八股文一般照搬SOA架構和實現即可
有一種參考的SOA架構是事件驅動架構，所有服務連接一個統一的消息管道，從管道中接收統一的事件消息和響應機制。
SOA落寞的原因：
- 過於嚴格的規範定義帶來了過度的複雜性；
- 過於精密的流程和理論需要懂得複雜概念的專業人員才能駕馭。
1.4 微服務時代
微服務的九個核心業務與技術特征
- 圍繞業務能力構建：根據業務劃分細粒度的服務和團隊；
- 分散治理： 各服務、各團隊對服務質量各自負責，不受其他服務影響，可以各自演進而不用統一規化；
- 通過服務而不是類庫來實現自治；
- 產品化思維：各服務開發人員關註整個微服務的全方位生命周期，大家不是為了僅僅完成某個功能，而是提供一個持續改進、提升的服務；
- 數據去中心化：允許不同的存儲方式或者存儲位置，但要考慮分散式一致性的成本；
- 強終端弱管道：即弱化類似SOAP的通信機制（通信管道設計很重，所有服務強制依賴，多了很多不必要的管道功能）， 如果有調用需要，提供服務終端的endpoint去調用而不是強制管道使用；
- 容錯性設計：認為各服務是可以出錯的，並不會直接影響所有服務的運行；
- 演進式設計：不僅可以容錯，也可以允許某個服務突然被淘汰；
- 基礎設置自動化：通過CI/CD等自動化構建、發佈、運維，減少人工維護成本。
微服務相比SOA的優勢
微服務不是SOA的變體或者衍生品，微服務中的每一部分可以自由的選擇其中的各種可選方案，例如遠程調用有RMI、Dubbo、Rest；服務發現有ZK、Etcd等。也因為選擇很多，對於架構師而言是一個很沉重的挑戰。
1.5 後微服務時代（雲原生時代）
用硬體方案替代軟體方案
對於註冊、跟蹤治理、均衡等問題，能否脫離應用代碼實現， 直接在硬體層面來實現？很早以前行不通，因為硬體基礎設置跟不上軟體應用的靈活性。直到docker和k8s的出現。微服務時代離不開以docker為代表的早期容器化技術，微服務框架springCloud所支持的軟體級別微服務治理功能，都能夠在k8s中找到硬體層面的替代：
通過k8s和相關的虛擬化技術， 與業務無關的技術性問題可以從軟體層面剝離，直接在硬體設置層面進行解決！
第二次進化
當涉及調用鏈路的切換或者變更， 單純依靠DNS的硬體層面來做切換還是比較困難的，不如軟體方案靈活。於是引入了“服務網格”的邊車代理模式，類似於脫離應用代碼，在容器中部署一個通信代理伺服器，對於請求的熔斷、變更、流量控制都可通過這個代理伺服器來管控。這樣微服務應用代碼中無需再考慮任何和上面這些通信過程相關的邏輯了，全部通過第三方的代理伺服器實現！
1.6無服務（ServerLess）時代
無服務的定義
- 後端即服務： 資料庫、存儲、日誌等業務無關的後端等都存儲在雲上；
- 函數即服務：供使用者調用的函數/介面都是運行在雲端，調用者不需要考慮容量規劃和算力問題。
無服務的願景
- 開發者只需要純粹地關註業務；
- 不需要考慮技術組件，後端組件現成的，直接使用，不用考慮如何採購和選型；
- 不用操心運維，運維能力交給雲計算廠商。
無服務的缺點
對於信息管理系統、網路游戲或者對後端介面響應速度較高的應用而言， 無服務並不是最佳選擇， 因為無服務的函數肯定不會一直處理高活躍度狀態，存在冷啟動的情況，對於其響應性能會有影響。
總結和思考
在很多年前的架構或者介紹微服務的書中，基本都是從單體->SOA->微服務。但是現在，隨著雲原生和serverless等新概念的出現，微服務架構的發展已經越來越多元化。對於需要頻繁接觸雲業務的開發者而言，這些新概念顯得更加重要。在學習這個章節時，需要關註這些架構演進的原因和理由，比如SOA相比單體的優點和缺點，後微服務又是如何從理念上逐步領先了傳統的微服務等。
而《鳳凰架構》一書的後半章節內容，更多是聚焦容器、k8s等雲原生的重要內容。
像基於容器、k8s的設計，雲原生技術將原先軟體能力中複雜的內容轉移到了硬體層面進行替代，開發者能夠用更集中的精力關心業務實現而非服務治理等繁雜的內容。
像華為雲CCE服務對於部署雲業務的服務而言就是雲原生時代的重要一環，CCE服務可以面向雲原生2.0打造CCE Turbo容器集群，計算、網路、調度全面加速，學習 CCE 服務可以幫助開發者更深入地瞭解 Kubernetes 和容器技術，從而提高自己的微服務開發和容器化應用部署能力。而無服務一般也是基於容器實現，對使用者而言基本不感知底層硬體資源，只需要調用即可，大大減少了創建和維護的學習和精力成本，即開即用的理念。 像華為雲數據湖探索DLI、華為雲湖倉構建LakeFormation等都是基於serverless實現的雲服務，雲用戶基於這些serverless服務並結合華為MRS等大數據底座之後，可以快速運行自己的大數據作業或者數據統一管理等能力，構建數智融合的相關能力。
總而言之，相比於傳統的微服務架構，雲原生和 serverless 技術更加靈活、高效，能夠更好地滿足用戶的需求。
