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

為了說明企業架構演化背后的思考，我們先談一些“玄學”：

l 企業IT系統的復雜性（熵）符合熱力學第二定律。隨著時間的推演，業務的變化，企業IT系統的復雜度會越來越高。

l 在計算機交互設計中有一個著名的復雜性守恒定律：應用交互的復雜性不會消失，只會換一種方式存在。這個原理也同樣適用于軟件架構，即引入新的軟件架構，不會降低IT系統的整體復雜性。

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

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

我們就從圖I-1開始，探究企業分布式應用架構演進。

蛻變之痛—SOA

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

當時的大背景是，隨著經濟全球化逐漸深入，企業面對的競爭加劇，商業變革也開始提速。在大型企業內部的IT系統已經經過了數十年的演化。整個技術體系變得異常復雜，并存著諸如主機系統上的CISC和Cobol交易應用、小型機AS/400中的RPG業務系統、X86或Power等分布式系統的C、J2EE、.Net應用。大量應用系統由3方供應商提供，一些系統甚至已經無人維護。而且隨著業務迭代，一些新的業務系統被持續構建出來，由于缺乏合理的方法論指導，系統之間缺乏有機的鏈接，形成了若干個“信息孤島”，持續加劇了IT架構的復雜性，無法支撐業務發展的訴求。這就仿佛各派高手為了幫助受傷的令狐沖，把異種真氣輸入體中，雖然短時間可以緩解傷勢，可是多道真氣無法融合，互相激蕩，長時間下來會傷上加傷。

因此，企業IT所面臨的首要挑戰就是整合企業中大量豎桶型（siloed）IT系統，支撐日益復雜的業務流程進行高效的業務決策和支撐業務快速變化。在這種背景下，IBM等公司提出了SOA（面向服務的架構）理念，將應用系統抽象成一個個粗粒度的服務，構建松耦合服務架構，可以通過業務流程對服務進行靈活組合，提升企業IT資產復用，提高了系統的適應性、靈活性和擴展性，解決“信息孤島”問題。

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

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

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

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

4）?服務應該是可復用的，業務邏輯切分為一系列可復用服務。

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

6）?服務是可發現、可組合的。比如可以通過Service Registry進行服務發現，實現了服務消費者和服務提供者的動態綁定。業務流程中可以對來自不同系統的的業務服務進行編排組裝。

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

為了解決上述挑戰，企業服務總線(Enterprise Service Bus，ESB)開始被引入，如圖I-2所示。企業服務總線提供了服務之間的連接、轉換以及中介處理的能力。可以將企業內部和各種服務連接到服務總線上，實現信息系統之間的松耦合架構，屏蔽了系統集成的復雜性，提高了IT系統架構的靈活性，降低企業內部信息共享的成本。

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

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

在業務上，當時SOA重點解決的是企業IT的存量市場的問題。這使得SOA方法論很大程度被窄化為 Enterprise Application Integration （企業應用集成）。在SOA理念中，打通信息系統間的經絡只是第一步。還需要勤修內功，持續重構迭代企業IT架構，這樣才能保持企業IT架構的敏捷、柔性，持續支撐業務的發展和變化。

在組織結構上，由于當時大部分企業的IT部門仍然屬于成本中心，是業務的支持部門。大多數企業缺乏長遠的IT戰略規劃，IT團隊也缺乏成長認同，SOA淪為項目制運作，而沒有組織化保障和持續投入。即使當時成功的項目也會在復雜性日積月累的侵蝕下，逐漸失去活力。去年在美國生活的朋友發過來照片，15年前我們為客戶構建的業務系統還在支撐其現有全國門店的業務。這是技術項目的成功，卻反映了企業技術戰略的缺失。

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

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

2） ESB是基于一個中心化的消息處理系統，隨著互聯網的高速發展，ESB已經無法應對企業IT規模化成長的挑戰。

3） ESB這樣的“智能管道，啞端點”的系統架構是一個無法適應快速變化和大眾創新的架構。類比一下，電信運營商曾經希望將視頻通信、電話會議等復雜功能納入電信基礎設施，只需一個“啞”電話終端就可以享受豐富的通信服務。然而隨著智能電話的普及，微信和釘釘這樣的分布式協同工具創新徹底顛覆了人們溝通交流的方式，而電信網絡重回管道的宿命。

羽化之美—微服務

隨著互聯網的發展，尤其是移動互聯時代的到來，整個世界的經濟形態發生了巨大的變化。企業IT的重點從傳統的交易系統（如ERP、SCM等）演化到互動系統（如全渠道營銷）。這些系統需要能夠應對互聯網規模的快速增長，并且能夠快速迭代，低成本試錯。企業IT已經成為創新驅動的引擎之一，技術拓展商業邊界的理想也幫助IT團隊更有使命感，進一步加速推動了企業IT的進化。

以Netflix、阿里巴巴為首的一系列互聯網公司主導了企業架構新的變革—微服務架構，如圖I-3所示。Apache Dubbo、Spring Cloud等微服務框架得到了廣泛應用。

微服務的核心思想便是應用功能拆分與解耦，降低業務系統實現復雜性。微服務強調將應用功能拆解為一組松耦合服務，每個服務遵守單一責任原則。微服務架構解決了傳統單體式架構存在的幾個固有問題：每個服務可以獨立部署和交付，大大提升了業務敏捷性；每個服務可以獨立橫向擴展、收縮，應對互聯網規模的挑戰。?

微服務架構繼承了SOA的架構原則，但是在實現層面，它傾向于通過構造“智能端點，啞管道”的去中心化分布式架構來替代ESB，把所有的服務治理邏輯包括服務發現、路由、消息解析等放在服務內部，去掉大一統的ESB，服務間通信采用簡單的協議，是比SOA更徹底的分布式的、去中心化的架構。

同時，微服務架構符合現代創新組織架構的需求。著名的康威定律指出，組織架構決定了技術架構。面對互聯網業務的快速演進，“兩個披薩原則”最早是由亞馬遜CEO貝索斯提出的，他認為如果兩個披薩不夠一個項目團隊吃的，那么這個團隊可能就顯得太大了。因為小團隊更有利于高效地溝通和協作，更易于達成共識，并能夠有效促進企業內部的創新。這樣的組織架構也要求每個團隊的模塊有更加明確的業務邊界，每個小團隊都對自己的模塊的整個生命周期負責，而模塊之間盡可能解耦，模塊可以獨立演化。

當然，將大型的單體應用拆解為多個微服務，也一定會增加IT系統研發協同、交付、運維的復雜性。隨著容器技術的廣泛應用，容器已經成為應用分發和交付的標準，可以將應用與底層運行環境解耦；Kubernetes 成為資源調度和編排的標準，屏蔽了底層架構的差異性，幫助應用平滑運行在不同的基礎設施上，可以幫助應用從數據中心平滑遷移到云端等不同環境。這時候微服務架構與DevOps和容器自然走到了一起，構成了云原生應用架構的雛形。

微服務架構還要面對分布式架構的內生復雜性，請參考文章“分布式計算的誤區”。微服務框架需要能夠解決服務通信和服務治理的復雜性，比如服務發現、熔斷、限流、全鏈路追蹤等挑戰。微服務框架，如HSF、Dubbo或Spring Cloud以代碼庫的方式來封裝這些能力。這些代碼庫被構建在應用程序本身中，隨著應用一起發布和維護，如圖I-4所示。?

服務通信和治理本質是橫向的系統級關注，是與業務邏輯正交的。但在微服務架構中，其實現方式和生命周期與業務邏輯耦合在一起。微服務框架的升級會導致整個服務應用的重新構建和部署。此外由于代碼庫通常與特定語言所綁定，難以支持企業應用的多語言（polyglot）實現。

進化之光—云原生

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

為了解決上述挑戰，社區提出了服務網格（service mesh）架構。它重新將服務治理能力下沉到基礎設施，在服務的消費者和提供者兩側以獨立進程的方式部署。這樣既達到了去中心化的目的，保障了系統的可伸縮性；也實現了服務治理和業務邏輯的解耦，二者可以獨立演進不相互干擾，提升了整體架構演進的靈活性；同時服務網格架構減少了對業務邏輯的侵入性，降低了多語言支持的復雜性，如圖I-5所示。?

2017年，Google、IBM、Lyft主導發起的Istio項目就是服務網格架構的一個典型實現，也成為了新的現象級“網紅”項目。

Istio提供了一系列高階的服務治理能力，比如：服務發現和負載均衡、漸進式交付（灰度發布）、混沌注入與分析、全鏈路追蹤、零信任網絡安全等。可以供上層業務系統將其編排到自己的IT架構和發布系統之中。在此之上，面向領域的云原生框架也在迅速出現，比如面向機器學習的云原生平臺Kubeflow，和面向無服務器的Knative等。通過這樣的架構分層，開發者只需關注自身的業務邏輯，而無需關注底層實現的復雜性。

2019年是服務網格技術落地的關鍵之年，我們見證了以Istio為代表的服務網格技術的快速成熟和廣泛使用。在阿里經濟體內部，螞蟻金服和電商業務已經開始大規模應用服務網格技術，來提供多語言支持，降低業務對接門檻；提供統一架構模式，提升技術迭代速度。

我們在支持用戶使用Istio的過程中，也深刻體會到了它具備較高的學習門檻。客觀來說，Istio的復雜性，一方面來源于其豐富的功能，譬如說它支持多種協議的流量控制，支持多語言，無需修改應用程序的情況下可以支持啟用雙向TLS認證等等；另一方面則來源于分布式架構的部署、運維本身就很復雜。

作為開發者來說，一方面希望把重點放到自身的業務上，另一方面又會期望底層服務網格技術基礎簡單、易用、安全、穩定。為了實現這些目標，托管的服務網格模式可能是一個較為合理的方案。在托管模式下，控制平面的組件被托管，降低用戶使用的復雜度，用戶只需要專注于數據平面中業務應用的開發部署。同時，仍然保持與Istio的兼容，支持聲明式的方式來定義靈活的路由規則，支持多個Kubernetes集群的統一流量管理。

展望

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

隨著容器、服務網格等技術的快速發展，我們可以看到一個云原生操作系統的雛形開始出現。這是開發者最好的時代，云基礎設施和云原生計算技術極大地提升了業務創新的速度。同時，云原生技術的發展離不開社區的成長和壯大，阿里巴巴全面擁抱云原生技術，并將我們在大規模生產中的最佳實踐回饋到社區，與社區共同建設更加美好的云原生計算。

我和《Istio服務網格技術解析與實踐》這本書作者王夕寧共事10多年，他以前就是SOA領域的技術專家，親歷了企業分布式架構演化的過程，在相關領域擁有眾多的全球技術專利。他在服務網格領域有非常深厚的理論功底和豐富的實踐經驗，負責了阿里云服務網格技術的產品化過程。非常期待本書能幫助各位讀者更好地把握服務網格的技術精髓，并且靈活應用于自己的業務系統中。?

本書由阿里云高級技術專家王夕寧撰寫，詳細介紹Istio的基本原理與開發實戰，包含大量精選案例和參考代碼可以下載，可快速入門Istio開發。Gartner認為，2020年服務網格將成為所有領先的容器管理系統的標配技術。本書適合所有對微服務和云原生感興趣的讀者，推薦大家對本書進行深入的閱讀。?

本文作者簡介：易立，阿里云容器服務負責人，資深技術專家。

總結

以上是生活随笔為你收集整理的阿里云专家手把手教你重塑 IT 架构！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。