[[278362]]

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

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

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

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

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

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

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

本圖來自 Bilgin Ibryam 的 twitter[2] 

蛻變之痛：SOA

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

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

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

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

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

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

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

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

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

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

任何 IT 架構(gòu)的成功，都離不開與業(yè)務(wù)目標(biāo)、技術(shù)基礎(chǔ)和組織能力的相互配合。

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

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

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

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

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

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

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

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

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

羽化之美：微服務(wù)

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

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

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

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

原圖來自于 Martin Fowler 對微服務(wù)架構(gòu)的定義[3]

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

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

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

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

原圖來源：[5] 

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

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

進(jìn)化之光：云原生

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

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

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

原圖來源：[5] 

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

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

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

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

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

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

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

關(guān)于性能問題：

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

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

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

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

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

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

回望歷史

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

相關(guān)鏈接：

[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/