從 SOA 到微服務，企業分佈式應用架構在雲原生時代如何重塑？

做者 | 易立 阿里雲資深技術專家

導讀：從十餘年前的各類分佈式系統研發到如今的容器雲，從支撐原有業務到孵化各個新業務，企業的發展離不開統一的、與時俱進的技術架構。本篇文章從企業分佈式應用架構層面介紹了雲原生計算架構帶來的變化，但願可以幫助更多企業的 IT 轉型，利用雲計算技術推進其成爲市場競爭中的敏捷力量。

進入 21 世紀以來，咱們見證了企業分佈式應用架構從 SOA(Service-oriented Architecture)，到微服務架構，再到雲原生應用架構的演化。

爲了說明企業架構演化背後的思考，咱們先談一些玄學。

• 第一，企業 IT 系統的複雜性（熵）符合熱力學第二定律。隨着時間的推演，業務的變化，企業 IT 系統的複雜度會愈來愈高。
• 第二，在計算機交互設計中有一個著名的複雜性守恆定律。應用交互的複雜性不會消失，只會換一種方式存在。這個原理也一樣適用於軟件架構。引入新的軟件架構，不會下降IT系統的總體複雜性。

聽到這裏，是否讓生命不息、折騰不止的咱們感到一絲涼涼？:-)

現代軟件架構的核心任務之一就是定義基礎設施與應用的邊界，合理切分複雜性，減小應用開發者須要面對的複雜性。換句話說，就是讓開發者專一在覈心價值創新上，而把一些問題交給更合適的人和系統來解決。

咱們就從下面這張圖開始，探究企業分佈式應用架構演進背後的邏輯。

本圖來自 Bilgin Ibryam 的 twitter

蛻變之痛 - SOA

2004 年，IBM 創建 SOA 全球設計中心，我做爲研發 TL 和架構師參與了一系列全球客戶的 pilot 項目，幫助 Pepboys, Office Depot 等國際企業利用 SOA 優化企業內部和企業間的業務流程，提高業務敏捷性。

當時的大背景是：隨着經濟全球化逐漸深刻，企業面對的競爭加重，商業變革也開始提速。在大型企業內部的 IT 系統已經通過了數十年的演化。整個的技術體系變得異常複雜，並存着諸如主機系統上的 CISC/COBOL 交易應用，小型機 AS400 中的 RPG 業務系統，和 X86/Power 等分佈式系統的 C/JEE/.Net 應用。

大量應用系統由三方供應商提供，一些系統甚至已經無人維護。並且隨着業務迭代，一些新的業務系統被持續構建出來，因爲缺少合理的方法論指導，系統之間缺少有機的連接，造成了若干的孤島，持續加重了 IT 架構的複雜性，沒法支撐業務的發展訴求。這就彷彿各派高手爲了幫助受傷的令狐沖，把異種真氣輸入體中，雖然短期能夠緩解傷勢。但是多道真氣沒法融合，互相激盪，長時間下來會傷上加傷。

所以，企業 IT 所面臨的首要挑戰就是整合企業中大量豎桶型（silo-ed）的 IT 系統，支撐日益複雜的業務流程，進行高效的業務決策和支撐業務快速變化。在這種背景下，IBM 等公司提出了 SOA（面向服務的架構）理念，將應用系統抽象成一個個粗粒度的服務，構建鬆耦合服務架構，能夠經過業務流程對服務進行靈活組合，提高企業 IT 資產複用，提升了系統的適應性、靈活性和擴展性，解決「信息孤島」問題。

SOA 提出了一系列構建分佈式系統的原則，這些思考直到今天也依然適用：

1. 首先是，服務具有明肯定義的標準化的接口。經過服務定義描述，將服務消費者（Service Consumer）和服務提供者 (Service Provider) 的實現進行解耦，而且服務應該採用 contract-first 而非 code-first 方式進行開發。服務間通訊採用面向文檔的消息而非特定語言 RPC 協議，一方面能夠解決服務與實現語言的解耦，另外一方面能夠靈活選擇同步或者異步的通訊實現，提高系統可用性和可伸縮性；
2. 服務應該是鬆耦合的，服務之間不該存在時間、空間、技術、團隊上的依賴；
3. 服務應該是無狀態的，使得服務調用與會話上下文狀態實現解耦；
4. 服務應該是自治和自包含的，服務的實現是能夠獨立進行部署、版本控制、自我管理和恢復；
5. 服務是可發現、可組合的。好比能夠經過 Service Registry 進行服務發現，實現了服務消費者和服務提供者的動態綁定。業務流程中能夠對來自不一樣系統的的業務服務進行編排組裝。

在初始構建 SOA 系統的時候，大多采用點對點的通訊鏈接，服務調用和集成邏輯被內嵌在應用實現中。這種方式在服務數量比較少的時候，確實是一種簡單和高效的開發方式。但其最大的問題是，隨着服務規模的增加，服務之間通訊愈發複雜，鏈接路徑和複雜性會劇增，給服務治理帶來巨大的挑戰。

爲了解決上述挑戰，企業服務總線 (Enterprise Service Bus，ESB) 開始被引入。企業服務總線提供了服務之間的鏈接（connection），轉換（transformantion）, 以及中介處理（mediation）的能力。能夠將企業內部和各類服務鏈接到服務總線上，實現信息系統之間的鬆耦合架構，屏蔽了系統集成的複雜性，提升了 IT 系統架構的靈活性，下降企業內部信息共享的成本。

SOA 方法論的目標就像易筋經能夠幫助梳理、歸聚不一樣的真氣，融會貫通，爲我所用。然而修煉過程卻絕非易事。大量雄心勃勃的 SOA 項目並未取得預期的效果，其背後的緣由是什麼？

任何 IT 架構的成功，都離不開與業務目標、技術基礎和組織能力的相互配合。

在業務上，當時 SOA 重點解決的是企業 IT 的存量市場的問題。這使得 SOA 方法論很大程度被窄化爲 Enterprise Application Integration （EAI 企業應用集成)。在 SOA 理念中，打通訊息系統間的經絡只是第一步。還須要勤修內功，持續重構迭代企業 IT 架構，這樣才能保持企業 IT 架構的敏捷、柔性，持續支撐業務的發展和變化。

在組織結構上，因爲當時在大部分企業的 IT 部門仍然是成本中心，是業務的附屬支撐部門。大多數企業缺少長遠的 IT 戰略規劃，IT 團隊也缺少成長認同，SOA 淪爲項目制運做而沒有組織化保障和持續投入。即便當時成功的項目也會在複雜性日積月累的侵蝕下，逐漸失去活力。去年在美國生活的朋友發過來照片，15 年前咱們爲客戶構建的業務系統還在支撐其現有全國門店的業務。這是技術項目的成功，卻反映了企業技術戰略的缺失。

在技術上，ESB 架構雖然實現了業務邏輯與服務集成的解耦，能夠更好地進行中央化的服務治理，也暴露出一些嚴肅問題：

1. 因爲過分強調業務系統的可複用性，而不是對企業 IT 架構的治理和重構。大量服務集成的實現邏輯被下沉到 ESB 內部（如上圖最右側所示），這些邏輯很是難以維護，難以移植和擴展，成爲 ESB 不可承受之重。咱們必須在合適的地點合理地處理複雜性，而非將其簡單轉移；
2. ESB 基於一箇中心化的消息處理系統，但隨着互聯網的高速發展，ESB 已經沒法應對企業IT規模化成長的挑戰；
3. ESB 這樣的 Smart Pipes, Dumb endpoints 的系統架構是一個沒法適應快速變化和大衆創新的一個架構。類比一下，電信運營商曾經但願將視頻通訊，電話會議等複雜功能歸入電信基礎設施，只需一個 Dummy 電話終端就能夠享受豐富的通訊服務。然而隨着智能電話的普及，微信和釘釘這樣的分佈式協同工具創新完全顛覆了人們溝通交流的方式，而電信網絡重回管道的宿命。

羽化之美 - 微服務

隨着互聯網的發展，尤爲是移動互聯時代的到來，整個世界的經濟形態發生了巨大的變化改變。企業 IT 的重點從傳統的 System of Record（交易系統，如 ERP、SCM 等）演化到 System of Engagement（互動系統，如全渠道營銷）。這些系統須要可以應對互聯網規模的快速增加，而且可以快速迭代，低成本試錯。企業 IT 已經成爲創新驅動的引擎之一，技術拓展商業邊界的理想也幫助 IT 團隊更有使命感，進一步加速推進了企業 IT 的進化。

以 Netflix、阿里爲首的一系列互聯網公司主導了企業架構新的變革 - 微服務架構。Apache Dubbo, Spring Cloud 等微服務框架獲得了普遍應用。

微服務的核心思想即是應用功能拆分與解耦，下降業務系統實現複雜性。微服務強調將應用功能拆解爲一組鬆耦合服務，每一個服務遵照單一責任原則（Single Responsibility Principle）。微服務架構解決了傳統單體式架構存在的幾個固有問題：每一個服務能夠獨立部署和交付，大大提高了業務敏捷性；每一個服務能夠獨立橫向擴展/收縮，應對互聯網規模的挑戰。

原圖來自於 Martin Fowler 對微服務架構的定義

固然，將大型的單體應用拆解爲多個微服務，也必定會增長 IT 系統研發協同、交付、運維的複雜性。這時候微服務架構與 DevOps 和容器天然走到了一塊兒，構成了雲原生應用架構的雛形。

微服務架構繼承了 SOA 的架構原則，可是在實現層面，它傾向於經過構造智能端點和啞管道的去中心化分佈式架構風格來替代 ESB。在《微服務（Microservice）那點事》文中詳細分析了這些問題，我也再也不贅述。

微服務架構首先要面對分佈式架構的內生複雜性，請參考分佈式計算的誤區。微服務框架須要可以解決服務通訊和服務治理的複雜性，好比服務發現、熔斷、限流、全鏈路追蹤等挑戰。微服務框架，如 HSF/Dubbo 或 Spring Cloud 以代碼庫的方式來封裝這些能力。這些代碼庫被構建在應用程序自己中，隨着應用一塊兒發佈和維護。

原圖來源

服務通訊和治理本質是橫向的系統級關注，是與業務邏輯正交的。但在微服務架構中，其實現方式和生命週期與業務邏輯耦合在一塊兒的。微服務框架的升級會致使整個服務應用的從新構建和部署。此外因爲代碼庫一般與特定語言所綁定，難以支持企業應用的多語言（polyglot）實現。

進化之光 - 雲原生

SOA 採用中心化的服務總線架構，解耦了業務邏輯和服務治理邏輯；微服務架構迴歸了去中心化的點對點調用方式，在提高敏捷性和可伸縮性的同時，也犧牲了業務邏輯和服務治理邏輯解耦所帶來的靈活性。

爲了解決上述挑戰，社區提出了 Service Mesh（服務網格）架構。它從新將服務治理能力下沉到基礎設施，在服務的消費者和提供者兩側以獨立進程的方式部署。這樣既達到了去中心化的目的，保障了系統的可伸縮性；也實現了服務治理和業務邏輯的解耦，兩者能夠獨立演進不相互干擾，提高了總體架構演進的靈活性；同時服務網格架構減小了對業務邏輯的侵入性，下降了多語言支持的複雜性。

原圖來源

Google, IBM，Lyft 主導發起的 Istio 項目就是服務網格架構的一個典型的實現，也成爲了新的現象級「網紅」項目。

上圖是 Istio 的架構，邏輯上分爲數據平面和控制平面。數據平面由一組以 sidecar 方式部署的智能代理組成，負責截獲應用網絡流量，收集遙測數據而且執行服務治理策略；控制平面中，Galley 負責配置管理，Pilot 負責下發配置，Mixer 負責策略檢查和遙測數據聚合，Citadel 負責通訊中安全證書管理。

Istio 提供了一系列高階的服務治理能力，好比：服務發現和負載均衡，漸進式交付(灰度發佈)，混沌注入與分析，全鏈路追蹤，零信任網絡安全等。能夠供上層業務系統將其編排到本身的IT架構和發佈系統之中。

可是 Service Mesh 不是銀彈，其架構選擇是經過增長部署複雜性（sidecar）和損失性能（增長兩跳），來換取架構的靈活性和系統的可演化性。

爲了解決部署複雜性的挑戰，社區和雲服務商都在共同進行努力：一方面簡化服務網格自動化運維水平（好比阿里雲經過 operator 大大簡化了 Istio的升級運維和跨 K8s 集羣部署的複雜度）；另外一方面提供託管的服務網格服務，幫助用戶關注在業務層面的服務治理而非基礎架構實現。

關於性能問題，一方面 Service Mesh 須要下降自身控制平面和服務平面的性能開銷，好比儘量 offload mixer 負載，將治理策略執行下沉到數據平面完成；另外一方面還須要從新思考整個通訊棧中應用與網絡基礎設施的邊界。

爲了實現容器應用之間的互聯互通，Kubernetes 社區提出 CNI 網絡模型，將容器網絡連通性與底層網絡實現的進行解耦，同時 K8s 提供了 Service, Ingress, Network policy 等基本元語來支持應用層的服務通訊和訪問控制。可是這些能力遠不能知足應用對服務治理的需求。

服務網格在 L4/L7 增長了流量管理、全鏈路可觀測性、安全互聯等新功能，這些是經過引入運行在用戶空間的 Envoy 代理實現的，在提高靈活性的同時也不可避免地增長了性能開銷。爲了系統化解決這個問題，社區在進行有趣的探索。好比在 Cillium 容器網絡中，能夠利用 eBPF/XDP 等操做系統和底層網絡能力，將應用層的服務控制能力（如 Kube-Proxy 提供的 service, network policy）下沉到操做系統內核和網絡層解決，並優化了 Service Mesh 數據鏈路，減小上下文切換和數據拷貝，有效地減小了性能開銷。

目前 Service Mesh 技術還處在技術成熟度曲線的初期，除了在 L4/L7 層提供靈活的服務通訊功能，社區也在探索經過網絡 Service Mesh實現靈活的 L2/L3 組網能力。咱們相信其會成爲將來企業分佈式應用通訊基礎設施。

在這個過程當中會有一些新的理念和項目被持續創造出來，咱們須要可以理性地分析其業務價值和技術侷限性。咱們要避免將 Service Mesh 做爲萬靈藥，不要將應用集成、應用側安全等業務邏輯下沉到服務網格中，避免咱們重蹈複雜性覆轍。能夠參考 Application Safety and Correctness Cannot Be Offloaded to Istio or Any Service Mesh

回望歷史

天下大勢，分久必合，合久必分。企業分佈式應用架構也走過一條分分合合的進化道路。在新技術迭起的今天，咱們既要擁抱新技術帶來的架構變化，更加要關注其背後的演進邏輯和核心價值，系統化地控制複雜性。

本文從企業分佈式應用架構層面介紹了雲原生計算架構帶來的變化，後面咱們陸續會分享在研發過程，集成架構等方面的思考。

	SOA	微服務	雲原生
研發過程	CMM/RUP	Agile	Agile
交付流程	手工/自動化	DevSecOps	GitOps/AIOps/NoOps
服務通訊	Web Service	REST/專有 RPC 協議	REST/gRPC 等開放協議
服務治理	ESB	微服務/API 網關	服務網格
應用運行環境	物理機/虛擬機	虛擬機/容器	Kubernetes/Serverless
基礎設施	IDC	公共雲/私有云	無邊界的雲（多雲/混合雲， 雲邊端）