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

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

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

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

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

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

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

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

本圖來自 Bilgin Ibryam 的 twitter[2]

蛻變之痛： 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 提出了一系列構建分佈式系統的原則，這些思考直到今天也依然適用：

服務具備明確定義的標準化的接口。通過服務定義描述，將服務消費者（Service Consumer）和服務提供者 (Service Provider) 的實現進行解耦，並且服務應該採用 contract-first 而非 code-first 方式進行開發。服務間通信採用面向文檔的消息而非特定語言 RPC 協議，一方面可以解決服務與實現語言的解耦，另一方面可以靈活選擇同步或者異步的通信實現，提升系統可用性和可伸縮性；

服務應該是松耦合的，服務之間不應存在時間、空間、技術、團隊上的依賴；

服務應該是無狀態的，使得服務調用與會話上下文狀態實現解耦；

服務應該是自治和自包含的，服務的實現是可以獨立進行部署、版本控制、自我管理和恢復；

服務是可發現、可組合的。比如可以通過 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 架構雖然實現了業務邏輯與服務集成的解耦，可以更好地進行中央化的服務治理，也暴露出一些嚴肅問題：

由於過度強調業務系統的可複用性，而不是對企業 IT 架構的治理和重構。大量服務集成的實現邏輯被下沉到 ESB 內部（如上圖最右側所示），這些邏輯非常難以維護，難以移植和擴展，成爲 ESB 不可承受之重。我們必須在合適的地點合理地處理複雜性，而非將其簡單轉移；

ESB 基於一箇中心化的消息處理系統，但隨着互聯網的高速發展，ESB 已經無法應對企業IT規模化成長的挑戰；
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 對微服務架構的定義[3]

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

微服務架構繼承了 SOA 的架構原則，但是在實現層面，它傾向於通過構造智能端點和啞管道的去中心化分佈式架構風格來替代 ESB。

微服務架構首先要面對分佈式架構的內生複雜性，請參考分佈式計算的誤區[4]。微服務框架需要能夠解決服務通信和服務治理的複雜性，比如服務發現、熔斷、限流、全鏈路追蹤等挑戰。

微服務框架，如 HSF/Dubbo 或 Spring Cloud 以代碼庫的方式來封裝這些能力。這些代碼庫被構建在應用程序本身中，隨着應用一起發佈和維護。

原圖來源：[5]

服務通信和治理本質是橫向的系統級關注，是與業務邏輯正交的。但在微服務架構中，其實現方式和生命週期與業務邏輯耦合在一起的。

微服務框架的升級會導致整個服務應用的重新構建和部署。此外由於代碼庫通常與特定語言所綁定，難以支持企業應用的多語言（polyglot）實現。

進化之光：雲原生

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

爲了解決上述挑戰，社區提出了 Service Mesh（服務網格）架構。它重新將服務治理能力下沉到基礎設施，在服務的消費者和提供者兩側以獨立進程的方式部署。

這樣既達到了去中心化的目的，保障了系統的可伸縮性；也實現了服務治理和業務邏輯的解耦，二者可以獨立演進不相互干擾，提升了整體架構演進的靈活性。同時服務網格架構減少了對業務邏輯的侵入性，降低了多語言支持的複雜性。

原圖來源：[5]

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[6] 實現靈活的 L2/L3 組網能力。我們相信其會成爲未來企業分佈式應用通信基礎設施。

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

回望歷史

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