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

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

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

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

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

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

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

蛻變之痛 - 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）。微服務架構解決了傳統單體式架構存在的幾個固有問題：每個服務可以獨立部署和交付，大大提升了業務敏捷性；每個服務可以獨立橫向擴充套件/收縮，應對網際網路規模的挑戰。

當然，將大型的單體應用拆解為多個微服務，也一定會增加 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

回望歷史

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

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

原文連結
本文為雲棲社群原創內容，未經