淺析云原生時代的服務架構演進

摘要：相比于傳統的微服務架構，云原生和 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 微服務時代

微服務的九個核心業務與技術特征

1. 圍繞業務能力構建：根據業務劃分細粒度的服務和團隊；
2. 分散治理： 各服務、各團隊對服務質量各自負責，不受其他服務影響，可以各自演進而不用統一規化；
3. 通過服務而不是類別庫來實作自治；
4. 產品化思維：各服務開發人員關注整個微服務的全方位生命周期，大家不是為了僅僅完成某個功能，而是提供一個持續改進、提升的服務；
5. 資料去中心化：允許不同的存盤方式或者存盤位置，但要考慮分布式一致性的成本；
6. 強終端弱管道：即榷訓類似SOAP的通信機制（通信管道設計很重，所有服務強制依賴，多了很多不必要的管道功能）， 如果有呼叫需要，提供服務終端的endpoint去呼叫而不是強制管道使用；
7. 容錯性設計：認為各服務是可以出錯的，并不會直接影響所有服務的運行；
8. 演進式設計：不僅可以容錯，也可以允許某個服務突然被淘汰；
9. 基礎設定自動化：通過CI/CD等自動化構建、發布、運維，減少人工維護成本，

微服務相比SOA的優勢

微服務不是SOA的變體或者衍生品，微服務中的每一部分可以自由的選擇其中的各種可選方案，例如遠程呼叫有RMI、Dubbo、Rest；服務發現有ZK、Etcd等，也因為選擇很多，對于架構師而言是一個很沉重的挑戰，

1.5 后微服務時代（云原生時代）

用硬體方案替代軟體方案

對于注冊、跟蹤治理、均衡等問題，能否脫離應用代碼實作， 直接在硬體層面來實作？很早以前行不通，因為硬體基礎設定跟不上軟體應用的靈活性，直到docker和k8s的出現，微服務時代離不開以docker為代表的早期容器化技術，微服務框架springCloud所支持的軟體級別微服務治理功能，都能夠在k8s中找到硬體層面的替代：

通過k8s和相關的虛擬化技術， 與業務無關的技術性問題可以從軟體層面剝離，直接在硬體設定層面進行解決！

第二次進化

當涉及呼叫鏈路的切換或者變更， 單純依靠DNS的硬體層面來做切換還是比較困難的，不如軟體方案靈活，于是引入了“服務網格”的邊車代理模式，類似于脫離應用代碼，在容器中部署一個通信代理服務器，對于請求的熔斷、變更、流量控制都可通過這個代理服務器來管控，這樣微服務應用代碼中無需再考慮任何和上面這些通信程序相關的邏輯了，全部通過第三方的代理服務器實作！

1.6無服務（ServerLess）時代

無服務的定義

• 后端即服務： 資料庫、存盤、日志等業務無關的后端等都存盤在云上；
• 函式即服務：供使用者呼叫的函式/介面都是運行在云端，呼叫者不需要考慮容量規劃和算力問題，

無服務的愿景

1. 開發者只需要純粹地關注業務；
2. 不需要考慮技術組件，后端組件現成的，直接使用，不用考慮如何采購和選型；
3. 不用操心運維，運維能力交給云計算廠商，

無服務的缺點

對于資訊管理系統、網路游戲或者對后端介面回應速度較高的應用而言， 無服務并不是最佳選擇， 因為無服務的函式肯定不會一直處理高活躍度狀態，存在冷啟動的情況，對于其回應性能會有影響，

總結和思考

在很多年前的架構或者介紹微服務的書中，基本都是從單體->SOA->微服務，但是現在，隨著云原生和serverless等新概念的出現，微服務架構的發展已經越來越多元化，對于需要頻繁接觸云業務的開發者而言，這些新概念顯得更加重要，在學習這個章節時，需要關注這些架構演進的原因和理由，比如SOA相比單體的優點和缺點，后微服務又是如何從理念上逐步領先了傳統的微服務等，

而《鳳凰架構》一書的后半章節內容，更多是聚焦容器、k8s等云原生的重要內容，

像基于容器、k8s的設計，云原生技術將原先軟體能力中復雜的內容轉移到了硬體層面進行替代，開發者能夠用更集中的精力關心業務實作而非服務治理等繁雜的內容，

像華為云CCE服務對于部署云業務的服務而言就是云原生時代的重要一環，CCE服務可以面向云原生2.0打造CCE Turbo容器集群，計算、網路、調度全面加速，學習 CCE 服務可以幫助開發者更深入地了解 Kubernetes 和容器技術，從而提高自己的微服務開發和容器化應用部署能力，而無服務一般也是基于容器實作，對使用者而言基本不感知底層硬體資源，只需要呼叫即可，大大減少了創建和維護的學習和精力成本，即開即用的理念，  像華為云資料湖探索DLI、華為云湖倉構建LakeFormation等都是基于serverless實作的云服務，云用戶基于這些serverless服務并結合華為MRS等大資料底座之后，可以快速運行自己的大資料作業或者資料統一管理等能力，構建數智融合的相關能力，

總而言之，相比于傳統的微服務架構，云原生和 serverless 技術更加靈活、高效，能夠更好地滿足用戶的需求，

點擊關注，第一時間了解華為云新鮮技術~

標籤：大數據

上一篇：HBase在進行模型設計時重點在什么地方？一張表中定義多少個Column Family最合適？為什么？

下一篇：解釋一下布隆過濾器原理