雲原生計算重塑企業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應用。大量應用系統由3方供應商提供，一些系統甚至已經無人維護。並且隨着業務迭代，一些新的業務系統被持續構建出來，因爲缺少合理的方法論指導，系統之間缺少有機的連接，造成了若干的孤島，持續加重了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	公共雲/私有云	無邊界的雲（多雲/混合雲， 雲邊端）

---

本文做者：易立

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。