[[278362]]

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

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

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

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

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

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

我們就從下面這張圖開始，探究企業(yè)分布式應用架構演進背后的邏輯。

本圖來自 Bilgin Ibryam 的 twitter[2] 

蛻變之痛：SOA

2004 年，IBM 建立 SOA 全球設計中心，我作為研發(fā) TL 和架構師參與了一系列全球客戶的 pilot 項目，幫助 Pepboys, Office Depot 等國際企業(yè)利用 SOA 優(yōu)化企業(yè)內(nèi)部和企業(yè)間的業(yè)務流程，提升業(yè)務敏捷性。

當時的大背景是：隨著經(jīng)濟全球化逐漸深入，企業(yè)面對的競爭加劇，商業(yè)變革也開始提速。在大型企業(yè)內(nèi)部的 IT 系統(tǒng)已經(jīng)經(jīng)過了數(shù)十年的演化，整個的技術體系變得異常復雜，并存著諸如主機系統(tǒng)上的 CISC/COBOL 交易應用，小型機 AS400 中的 RPG 業(yè)務系統(tǒng)，和 X86/Power 等分布式系統(tǒng)的 C/JEE/.Net 應用。

大量應用系統(tǒng)由三方供應商提供，一些系統(tǒng)甚至已經(jīng)無人維護。而且隨著業(yè)務迭代，一些新的業(yè)務系統(tǒng)被持續(xù)構建出來，由于缺乏合理的方法論指導，系統(tǒng)之間缺乏有機的鏈接，形成了若干的孤島，持續(xù)加劇了 IT 架構的復雜性，無法支撐業(yè)務的發(fā)展訴求。這就仿佛各派高手為了幫助受傷的令狐沖，把異種真氣輸入體中，雖然短時間可以緩解傷勢。可是多道真氣無法融合，互相激蕩，長時間下來會傷上加傷。

因此，企業(yè) IT 所面臨的首要挑戰(zhàn)就是整合企業(yè)中大量豎桶型(silo-ed)的 IT 系統(tǒng)，支撐日益復雜的業(yè)務流程，進行高效的業(yè)務決策和支撐業(yè)務快速變化。

在這種背景下，IBM 等公司提出了 SOA(面向服務的架構)理念，將應用系統(tǒng)抽象成一個個粗粒度的服務，構建松耦合服務架構，可以通過業(yè)務流程對服務進行靈活組合，提升企業(yè) IT 資產(chǎn)復用，提高了系統(tǒng)的適應性、靈活性和擴展性，解決“信息孤島”問題。

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

• 服務具備明確定義的標準化的接口。通過服務定義描述，將服務消費者(Service Consumer)和服務提供者 (Service Provider) 的實現(xiàn)進行解耦，并且服務應該采用 contract-first 而非 code-first 方式進行開發(fā)。服務間通信采用面向文檔的消息而非特定語言 RPC 協(xié)議，一方面可以解決服務與實現(xiàn)語言的解耦，另一方面可以靈活選擇同步或者異步的通信實現(xiàn)，提升系統(tǒng)可用性和可伸縮性;
• 服務應該是松耦合的，服務之間不應存在時間、空間、技術、團隊上的依賴;
• 服務應該是無狀態(tài)的，使得服務調(diào)用與會話上下文狀態(tài)實現(xiàn)解耦;
• 服務應該是自治和自包含的，服務的實現(xiàn)是可以獨立進行部署、版本控制、自我管理和恢復;
• 服務是可發(fā)現(xiàn)、可組合的。比如可以通過 Service Registry 進行服務發(fā)現(xiàn)，實現(xiàn)了服務消費者和服務提供者的動態(tài)綁定。業(yè)務流程中可以對來自不同系統(tǒng)的的業(yè)務服務進行編排組裝。

在初始構建 SOA 系統(tǒng)的時候，大多采用點對點的通信連接，服務調(diào)用和集成邏輯被內(nèi)嵌在應用實現(xiàn)中。這種方式在服務數(shù)量比較少的時候，確實是一種簡單和高效的開發(fā)方式。但其最大的問題是，隨著服務規(guī)模的增長，服務之間通信愈發(fā)復雜，連接路徑和復雜性會劇增，給服務治理帶來巨大的挑戰(zhàn)。

為了解決上述挑戰(zhàn)，企業(yè)服務總線 (Enterprise Service Bus，ESB) 開始被引入。企業(yè)服務總線提供了服務之間的連接(connection)，轉換(transformantion), 以及中介處理(mediation)的能力。可以將企業(yè)內(nèi)部和各種服務連接到服務總線上，實現(xiàn)信息系統(tǒng)之間的松耦合架構，屏蔽了系統(tǒng)集成的復雜性，提高了 IT 系統(tǒng)架構的靈活性，降低企業(yè)內(nèi)部信息共享的成本。

SOA 方法論的目標就像易筋經(jīng)可以幫助梳理、歸聚不同的真氣，融會貫通，為我所用。然而修煉過程卻絕非易事。大量雄心勃勃的 SOA 項目并未取得預期的效果，其背后的原因是什么?

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

在業(yè)務上，當時 SOA 重點解決的是企業(yè) IT 的存量市場的問題。這使得 SOA 方法論很大程度被窄化為 Enterprise Application Integration (EAI 企業(yè)應用集成)。

在 SOA 理念中，打通信息系統(tǒng)間的經(jīng)絡只是第一步，還需要勤修內(nèi)功，持續(xù)重構迭代企業(yè) IT 架構，這樣才能保持企業(yè) IT 架構的敏捷、柔性，持續(xù)支撐業(yè)務的發(fā)展和變化。

在組織結構上，由于當時在大部分企業(yè)的 IT 部門仍然是成本中心，是業(yè)務的附屬支撐部門，大多數(shù)企業(yè)缺乏長遠的 IT 戰(zhàn)略規(guī)劃，IT 團隊也缺乏成長認同，SOA 淪為項目制運作而沒有組織化保障和持續(xù)投入。

即使當時成功的項目也會在復雜性日積月累的侵蝕下，逐漸失去活力。去年在美國生活的朋友發(fā)過來照片，15 年前我們?yōu)榭蛻魳嫿ǖ臉I(yè)務系統(tǒng)還在支撐其現(xiàn)有全國門店的業(yè)務。這是技術項目的成功，卻反映了企業(yè)技術戰(zhàn)略的缺失。

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

由于過度強調(diào)業(yè)務系統(tǒng)的可復用性，而不是對企業(yè) IT 架構的治理和重構。大量服務集成的實現(xiàn)邏輯被下沉到 ESB 內(nèi)部(如上圖最右側所示)，這些邏輯非常難以維護，難以移植和擴展，成為 ESB 不可承受之重。我們必須在合適的地點合理地處理復雜性，而非將其簡單轉移;

ESB 基于一個中心化的消息處理系統(tǒng)，但隨著互聯(lián)網(wǎng)的高速發(fā)展，ESB 已經(jīng)無法應對企業(yè)IT規(guī)模化成長的挑戰(zhàn);

ESB 這樣的 Smart Pipes, Dumb endpoints 的系統(tǒng)架構是一個無法適應快速變化和大眾創(chuàng)新的一個架構。

類比一下，電信運營商曾經(jīng)希望將視頻通信，電話會議等復雜功能納入電信基礎設施，只需一個 Dummy 電話終端就可以享受豐富的通信服務。然而隨著智能電話的普及，微信和釘釘這樣的分布式協(xié)同工具創(chuàng)新徹底顛覆了人們溝通交流的方式，而電信網(wǎng)絡重回管道的宿命。

羽化之美：微服務

隨著互聯(lián)網(wǎng)的發(fā)展，尤其是移動互聯(lián)時代的到來，整個世界的經(jīng)濟形態(tài)發(fā)生了巨大的變化改變。企業(yè) IT 的重點從傳統(tǒng)的 System of Record(交易系統(tǒng)，如 ERP、SCM 等)演化到 System of Engagement(互動系統(tǒng)，如全渠道營銷)。

這些系統(tǒng)需要能夠應對互聯(lián)網(wǎng)規(guī)模的快速增長，并且能夠快速迭代，低成本試錯。企業(yè) IT 已經(jīng)成為創(chuàng)新驅動的引擎之一，技術拓展商業(yè)邊界的理想也幫助 IT 團隊更有使命感，進一步加速推動了企業(yè) IT 的進化。

以 Netflix、阿里為首的一系列互聯(lián)網(wǎng)公司主導了企業(yè)架構新的變革 - 微服務架構。Apache Dubbo, Spring Cloud 等微服務框架得到了廣泛應用。

微服務的核心思想便是應用功能拆分與解耦，降低業(yè)務系統(tǒng)實現(xiàn)復雜性。微服務強調(diào)將應用功能拆解為一組松耦合服務，每個服務遵守單一責任原則(Single Responsibility Principle)。微服務架構解決了傳統(tǒng)單體式架構存在的幾個固有問題：每個服務可以獨立部署和交付，大大提升了業(yè)務敏捷性;每個服務可以獨立橫向擴展/收縮，應對互聯(lián)網(wǎng)規(guī)模的挑戰(zhàn)。 

原圖來自于 Martin Fowler 對微服務架構的定義[3]

當然，將大型的單體應用拆解為多個微服務，也一定會增加 IT 系統(tǒng)研發(fā)協(xié)同、交付、運維的復雜性。這時候微服務架構與 DevOps 和容器自然走到了一起，構成了云原生應用架構的雛形。

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

微服務架構首先要面對分布式架構的內(nèi)生復雜性，請參考分布式計算的誤區(qū)[4]。微服務框架需要能夠解決服務通信和服務治理的復雜性，比如服務發(fā)現(xiàn)、熔斷、限流、全鏈路追蹤等挑戰(zhàn)。

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

原圖來源：[5] 

服務通信和治理本質是橫向的系統(tǒng)級關注，是與業(yè)務邏輯正交的。但在微服務架構中，其實現(xiàn)方式和生命周期與業(yè)務邏輯耦合在一起的。

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

進化之光：云原生

SOA 采用中心化的服務總線架構，解耦了業(yè)務邏輯和服務治理邏輯;微服務架構回歸了去中心化的點對點調(diào)用方式，在提升敏捷性和可伸縮性的同時，也犧牲了業(yè)務邏輯和服務治理邏輯解耦所帶來的靈活性。

為了解決上述挑戰(zhàn)，社區(qū)提出了 Service Mesh(服務網(wǎng)格)架構。它重新將服務治理能力下沉到基礎設施，在服務的消費者和提供者兩側以獨立進程的方式部署。

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

原圖來源：[5] 

Google, IBM，Lyft 主導發(fā)起的 Istio 項目就是服務網(wǎng)格架構的一個典型的實現(xiàn)，也成為了新的現(xiàn)象級“網(wǎng)紅”項目。

上圖是 Istio 的架構，邏輯上分為數(shù)據(jù)平面和控制平面：

• 數(shù)據(jù)平面由一組以 sidecar 方式部署的智能代理組成，負責截獲應用網(wǎng)絡流量，收集遙測數(shù)據(jù)并且執(zhí)行服務治理策略;
• 控制平面中，Galley 負責配置管理，Pilot 負責下發(fā)配置，Mixer 負責策略檢查和遙測數(shù)據(jù)聚合，Citadel 負責通信中安全證書管理。

Istio 提供了一系列高階的服務治理能力，比如：服務發(fā)現(xiàn)和負載均衡，漸進式交付(灰度發(fā)布)，混沌注入與分析，全鏈路追蹤，零信任網(wǎng)絡安全等，可以供上層業(yè)務系統(tǒng)將其編排到自己的 IT 架構和發(fā)布系統(tǒng)之中。

但是 Service Mesh 不是銀彈，其架構選擇是通過增加部署復雜性(sidecar)和損失性能(增加兩跳)，來換取架構的靈活性和系統(tǒng)的可演化性。

為了解決部署復雜性的挑戰(zhàn)，社區(qū)和云服務商都在共同進行努力：

• 一方面簡化服務網(wǎng)格自動化運維水平(比如阿里云通過 operator 大大簡化了 Istio的升級運維和跨 K8s 集群部署的復雜度);
• 另一方面提供托管的服務網(wǎng)格服務，幫助用戶關注在業(yè)務層面的服務治理而非基礎架構實現(xiàn)。

關于性能問題：

• 一方面 Service Mesh 需要降低自身控制平面和服務平面的性能開銷，比如盡可能 offload mixer 負載，將治理策略執(zhí)行下沉到數(shù)據(jù)平面完成;
• 另一方面還需要重新思考整個通信棧中應用與網(wǎng)絡基礎設施的邊界。

為了實現(xiàn)容器應用之間的互聯(lián)互通，Kubernetes 社區(qū)提出 CNI 網(wǎng)絡模型，將容器網(wǎng)絡連通性與底層網(wǎng)絡實現(xiàn)的進行解耦，同時 K8s 提供了 Service, Ingress, Network policy 等基本元語來支持應用層的服務通信和訪問控制。但是這些能力遠不能滿足應用對服務治理的需求。

服務網(wǎng)格在 L4/L7 增加了流量管理、全鏈路可觀測性、安全互聯(lián)等新功能，這些是通過引入運行在用戶空間的 Envoy 代理實現(xiàn)的，在提升靈活性的同時也不可避免地增加了性能開銷。

為了系統(tǒng)化解決這個問題，社區(qū)在進行有趣的探索。比如在 Cillium 容器網(wǎng)絡中，可以利用 eBPF/XDP 等操作系統(tǒng)和底層網(wǎng)絡能力，將應用層的服務控制能力(如 Kube-Proxy 提供的 service, network policy)下沉到操作系統(tǒng)內(nèi)核和網(wǎng)絡層解決，并優(yōu)化了 Service Mesh 數(shù)據(jù)鏈路，減少上下文切換和數(shù)據(jù)拷貝，有效地減少了性能開銷。

目前 Service Mesh 技術還處在技術成熟度曲線的初期，除了在 L4/L7 層提供靈活的服務通信功能，社區(qū)也在探索通過網(wǎng)絡 Service Mesh[6] 實現(xiàn)靈活的 L2/L3 組網(wǎng)能力。我們相信其會成為未來企業(yè)分布式應用通信基礎設施。

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

回望歷史

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

相關鏈接：

[1] https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity

[2] https://twitter.com/bibryam/status/1026429379587567616

[3] https://martinfowler.com/articles/microservices.html

[4] https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

[5] https://philcalcado.com/2017/08/03/pattern_service_mesh.html

[6] https://networkservicemesh.io/

[7] https://blog.christianposta.com/microservices/application-safety-and-correctness-cannot-be-offloaded-to-istio-or-any-service-mesh/