演講嘉賓簡介：李小平（花名：愚奇），阿裡雲智能中間件首席架構師。
以下内容根據演講視訊及PPT整理而成。
本次分享主要圍繞以下四個方面：
一、數字化轉型和中台對企業技術架構所帶來的挑戰
二、微服務架構的應對之道
三、雲原生微服務架構的應對之道
四、阿裡雲走過的路徑
數字化轉型和中台對企業技術架構帶來了挑戰
如今，各大企業都在進行數字化轉型。在中國，阿裡巴巴首先提出“中台”的概念，而中台正是幫助企業進行數字化轉型的良好實踐。企業數字化轉型會為企業技術架構帶來兩點改變，即一切業務資料化和一切資料業務化。這将會導緻企業的軟體生産流程發生巨大變化，促使傳統企業向着網際網路類型的軟體企業進行轉變。此外，由于生産線中存在更多的需求和軟體設計等，這都會為企業的技術架構帶來更多的挑戰。
核心問題：軟體複雜性
以上的挑戰從更高的次元來看，可以歸結為軟體複雜性問題。《人月神話》一書的作者Fred Brooks有一番經典言論，即“軟體複雜度問題很多時候都是由于軟體規模的不斷增加所造成的，而且軟體複雜度的增加與軟體規模的增加并不是線性關系”。
我們的讨論範圍
本次分享的讨論範圍僅關注于技術領域，而且因為市面上很多書籍都對于微服務架構都有詳細介紹，是以本次分享将更多地關注企業高層技術架構的非功能性分析、組織溝通結構、流水線效能以及商業影響等方面，不會讨論具體的架構設計方案。
典型場景
如下圖所示的是大部分企業中的組織架構和軟體生産流水線概況。在組織結構中，按照功能結構方式劃分職責，通常會有需求分析師、架構師、業務分析師、前端開發、後端開發、品質保證以及運維人員，這樣的組織結構就構成了企業軟體生産流水線中的各種角色。對于企業軟體生産流水線而言，大部分企業的流水線包括需求分析、架構設計、總設/詳設、代碼開發、測試驗證、釋出上線、監控運維以及錯誤處理等，這就是本次分享主要讨論的典型場景。在這樣的典型場景裡面，我們最主要需要關注的是模型下的技術複雜度、實作成本以及組織結構和生産流水線對應的技術架構會為業務價值帶來什麼影響。
簡單的情況（小于5人）
很多時候，團隊規模小或者簡單将會帶來更高的快捷性，是以對于團隊小于5個人的場景就不再做過多的讨論了。因為在這樣的場景中，上述提到的多個角色将會合并，進而形成“快捷、友善”的企業流水線，而且也未必會遵循前面提到的流程和步驟，因為在這樣的場景下，溝通非常迅速。很多時候不會涉及到軟體的開發複雜度問題，而涉及到的隻是技術複雜度問題。
中大規模下的環境互相影響問題
本次分享将會主要聚焦于中大規模的軟體生産環境，在這樣的環境中往往存在比較多的問題，本次分享中将會選取幾個較為典型的問題進行分析。第一個問題就是由于多個開發或測試人員共用一個環境所帶來的互相影響，這樣的互相影響在很多企業中都在發生。因為這些人員共用了一個開發或者測試環境，而這些環境的使用者衆多，其中的一個使用者在該環境中所做的一次釋出或者變更，都會導緻其他依賴了這一環境的人員或者業務子產品出現問題，進而可能導緻整體問題。每次出現問題，都需要軟體生産線管理者對于環境進行修複，避免進一步影響更多的工作。當這種場景所造成的問題越來越大的時候，軟體生産線的管理者不得不通過流程來限制和規範大家對于環境的使用行為。
中大規模下的釋出幹擾問題
第二個典型場景就是同一個軟體需求往往會由多個部門同時進行開發。此外，軟體生産線也不會一次隻處理一個需求，而是多個需求同時疊代。團隊在進行需求開發的時候，往往會中間插入一些高優先級的需求，而客戶要求高優先級需求盡快上線，這就會使得原來位于生産線中的其他還沒有完成的需求處于尴尬位置，如果跟随高優先級需求同時上線，就會導緻整體或者部分功能不可用；而如果不上線，那麼已經完成的這部分代碼很難從現有的代碼分支中剔除出去，這就是釋出所帶來的互相幹擾問題。這些幹擾問題從本質上就是由于不同的需求有不同的優先級和排期，而需求的實作代碼又有不同的子產品依賴關系，而這就使得整體的釋出周期變長，協調成本變高。相應的協調工作不斷增多，使得組織不得不考慮使用流程化的方法進行整體釋出。很多企業則會采用按周期進行釋出，這就使得開發人員更累，因為往往需要在進行多分支之間的處理。
中大規模下的資料幹擾問題
此外，還經常會遇到資料幹擾問題。這是因為不同的資料子產品共同通路相同的資料庫表或者KV存儲導緻的，這種共同的依賴導緻一個子產品需要改變資料庫表或者KV存儲的Schema的時候，另外一個使用相同資料庫表或KV存儲的子產品不得不進行回歸測試和釋出，即使該子產品并沒有進行任何業務代碼的修改。當資料上形成的依賴增多的時候，相應的協調、溝通工作也會大大增加，需要讓所有的釋出子產品進行代碼級、資料級的依賴分析，進而在每次釋出時進行準确的依賴測試，并基于回歸測試判斷釋出品質，而且需要做Schema的相容性設計。
中大規模下的生産流水線分析
對于以上問題而言，當回到組織流水線來看，都是由康威定律中所描述的溝通問題導緻的。在如下圖所示的組織結構中，由于不同角色在生産流水線的不同階段都有相應的工作，他們之間需要進行不斷的溝通和協調。在這樣複雜的溝通結構中，勢必造成相應角色對于相應流水線的強依賴關系。如果這種強依賴關系不斷擴散，那麼相應的溝通複雜度就會不斷放大。在這種傳統生産流水線模式下面，技術複雜度顯然會随着軟體規模的擴大而不斷擴大，當組織的規模增大之後，組織之間的内耗就會增多，溝通成本增加了。同樣的，管理成本也會增加，不僅是對人的管理，也包括對于工具、環境的管理等。在這樣的場景下面，需求響應速度會不斷變慢，并且容易觸發穩定性、關聯性Bug，進而影響使用者體驗。當軟體規模不斷增大的時候，傳統的軟體生産流水線就無法滿足企業要求了。
微服務架構随着軟體規模的擴大而被大家采納
随着軟體規模的不斷擴大，新的技術架構不斷湧現出來。從2000年的SOA架構，到2008年的網際網路架構，以及2015年的微服務架構。與此同時，軟體企業和軟體從業者的規模則也是不斷增加的。微服務架構本質上所解決的問題是随着軟體規模不斷擴大而出現的組織複雜度、生産流水線複雜度和技術複雜度問題。
現在的主流微服務架構
現在的主流微服務架構比較多，如果做一個抽象可以如下圖所示。可以看出，所有請求很多時候會從API Gateway過來，并且以服務調用的方式送到不同的微服務裡面，微服務之間通過遠端服務調用的方式來發生關系，微服務自己通過服務發現的模式進行注冊和銷毀。同樣，會有相應的服務管理子產品對微服務進行治理。在這樣比較典型的架構裡面可以看到，其不僅在技術架構上面發生了變化，在流水線群組織結構中也要發生變化。在傳統架構中，組織是按照部門職能進行劃分的，而在微服務架構中，則要求按照業務域進行劃分，比如客戶域、訂單域。在一個業務域下面，自身會形成閉包，不僅包括了架構的閉包，也包括了人員角色的閉包，閉包中包括了從需求分析，到相應的設計、開發、品質保證、運維以及營運等相應的人員，讓他們一起負責整體業務。實際上，就是對于大顆粒度業務進行服務級别的拆分，
微服務下的生産流水線分析
微服務下組織結構的拆分會對于生産流水線造成巨大改變。如下圖所示，原來所有的業務人員都在同一條生産流水線下面，現在則變成了每個業務域都有至少一條屬于自己的生産流水線，對于企業而言，就形成了多流水線并行的情況，這樣就顯然提升了企業生産的并發度，減少了業務單元之間的互相依賴，進而提升了整體效率。在微服務生産流水線下面，企業強調微服務做合理拆分，這樣的拆分往往是通過領域方式實作的，比如按照聚合根方式。拆分完成的服務具備高内聚、低耦合的特征。在這樣的服務中，很顯然服務子產品内部技術複雜度降低了，這是因為對于子產品之間的互動進行了技術架構和業務架構上的規範，進而使得一個服務所需要關注的資料下降了，是以其複雜度也會随之下降。但從技術的角度，原來是一個大的服務包，現在拆分成若幹個不同的服務包，服務之間就會存在比較多的調用關系，這個時候再分布式場景下會使得複雜度增加。從實作的成本上來看，由于多流水線并行，是以企業的溝通成本将會下降，因為隻有一個大的業務需求需要橫跨多個業務單元的時候才需要進行溝通，而且都是在業務層面進行溝通，而不會在軟體的實作、軟體環境的共用上發生關系，是以就減少了組織之間的溝通複雜度。當然這裡的前提是企業自動化能力需要跟上，如果沒有強大的自動化能力，那麼做微服務将會成為企業的巨大噩夢。這是因為原來架構下，運維人員隻需要維護一組服務，現在則需要維護多組服務；對于測試人員也是一樣的。是以，在微服務架構下，需要相應的測試、運維以及開發提升整個生産流水線的自動化能力，進而提升整體研發和運維效率。這也正是DevOps理念所強調的提升持續內建和持續傳遞的能力。從業務價值來看，微服務流水線使得需求響應的速度得到了極大提升，同時按照業務領域而非人員職能劃分組織結構的方式非常符合中台理念，也非常符合中台、前台互相分離的原則，進而快速疊代的業務需求。
微服務架構下的環境問題解決
回到前面所提到的傳統架構所面臨的問題，考慮一下微服務架構如何解決。對于環境問題而言，在微服務架構下面，由于提倡DevOps，不斷增強CI/CD能力，使得共用環境變成了每個小組擁有單獨的環境。而因為持續內建的能力提升，小組内可以有生産測試環境和試飛環境，也就是說當開發人員完成代碼實作之後可以先送出到試飛環境，在試飛環境中完成CI以及CD相關的工作。如果所有的工作驗證完成之後，再自動化地将釋出的子產品同步到小組内的預發環境中去做SIT。這就使得每個業務領域的小組都能夠實作快速疊代，而不是通過流程規範來限制大家的行為。
微服務架構下的釋出幹擾問題解決
對于釋出幹擾問題而言，在微服務架構下，按照服務的顆粒度進行釋出，這樣就比較容易實作按需求進行釋出。如果某個符合需求橫跨多個領域，也能夠得到快速排期。這是因為可以在頂層實作業務分解，進而進入到每個不同的業務領域時就變成了單獨的需求，隻需要在頂層去協調需求的任務排期情況即可，互相之間的幹擾得到極大降低。這使得每個服務都可以随時釋出，并且快速釋出、按需釋出，并降低了每個服務釋出品質對于整體系統品質的影響。
微服務架構下的資料幹擾問題解決
對于資料幹擾問題而言，微服務要求不同的服務使用不同的資料源，是以從本質上就打斷了服務之間的資料依賴問題。當這種設計模式應用到微服務的設計中之後，當業務子產品中需要通路資料通常有兩種形式。第一種方式是通過API或者消息方式；第二種是通過Change Data Capture（CDC）方式實作，因為如果對于資料子產品存在依賴，往往是依賴其局部視圖，是以跟蹤另外一個子產品資料發生變化的消息，當接收到所訂閱的資料變化消息之後，服務可以在自己的資料視圖中進行改變，這樣就徹底消除了服務之間的資料依賴。
微服務架構的“雙刃劍”問題
正如Fred Brooks所說的“沒有銀彈”。其實任何的技術往往都是“雙刃劍”。那麼，在微服務架構下面，什麼是“雙刃劍”問題呢？
微服務架構面臨的主要挑戰
微服務很好地解決了大規模軟體的複雜度問題，但是也帶來了其他問題。這些問題包括以下幾點：
分布式規模的增加帶來的技術複雜度問題：特别是像今天雲計算在不斷地普及，企業在雲計算環境下如何解決分布式問題變成一個巨大的挑戰。
節點執行個體增加帶來的穩定性降低：以往架構使用一台計算能力強的機器做釋出，而今天在微服務架構下面，系統不斷拆分使得出現更多的服務執行個體，是以需要增加更多的節點，導緻穩定性降低。
快速擴縮容響應網際網路規模的大促：網際網路的不斷普及使得其與更多的業務發生關系，這意味着對業務架構突然産生大的擴縮容要求。
分布式環境的調試、故障診斷和監控關聯性分析：微服務使得運維人員進行這些工作時會出現困難，需要去不同的機器上采集資訊并進行關聯性分析。
提升開發運維的自動化能力：微服務部署的複雜度增加導緻對此産生更高的需求。
多語言開發、容災、安全：微服務允許使用多語言實作業務，并且在容災和安全方面都面臨較大挑戰。
雲原生技術随着雲計算的推廣而被廣泛使用
隻要有需求就會不斷湧現出新的技術方案來解決問題。随着雲計算技術的不斷普及，雲原生相關技術也逐漸被廣泛使用，從2001年的虛拟化，到2013年容器技術的出現，對于雲原生技術都帶來了非常大的變革。在2015年，業界正式提出雲原生技術來去解決軟體生産流程中的各種問題。
雲原生中間件
雲原生技術的普及就帶來建構所需要的中間件發生的巨大變化，導緻雲原生中間件這個新領域的出現。與以往的中間件不同，雲原生中間件除了能夠接受二進制包并進行相應的部署以外，還可以直接解決高可用問題，不需要關注彈性等問題，而隻需要關注業務實作本身以及排錯等。除此以外，巨大的變化在于Service Mesh技術上面，原本像安全、限流、降級、熔斷等分布式場景下的設計模式是被沉澱到了Spring Cloud、Dubbo這樣的架構中，而在雲原生中間件中，這些模式則被沉澱到了Service Mesh中，實作了與應用的徹底剝離。分布式模式與應用的徹底剝離帶來了幾個優勢：開發人員不需要再去關注分布式架構下面的設計複雜度問題；不同的開發架構、不同語言所開發的微服務都可以同樣地共享這些能力，為業務開發帶來了極大便利；原本這些分布式設計模式都存在與開源架構中，沒有商業服務，而在雲基礎服務中，這些設計模式都能夠被類似于Service Mesh的基礎設施提供，也就是所謂的雲廠商提供，是以能夠大大提升服務品質。除了Service Mesh，在雲領域大家非常關注的SLA、如何做穩定性的安全生産、如何做持續的IT治理等能力都能夠由雲原生中間件層提供。而雲原生中間件會架構在很多BaaS服務上面，同時也會架構在容器上面，這樣的設計使得對于應用架構帶來巨大改變，那就是将一個應用所依賴的第三方元件交給專業的産品提供，不僅提供SDK，還會提供專業服務，擴縮容以及運維都由雲廠商提供。
如何解決穩定性問題
在雲原生環境下面如何解決穩定性問題呢？由于在雲原生中間件裡面所提倡的是事件驅動架構，這種架構從設計本身來看是具有巨大優勢的，可以進一步減少服務之間的耦合。原本服務之間可能是通過RPC調用方式形成的耦合，但在事件驅動的架構下，服務之間通過事件進行傳遞，而事件本身具有松耦合的特征，是以事件驅動架構将為整體架構帶來更強的韌性。同樣的，由于Service Mesh接管了穩定性相關的所有雲設計模式，比如熔斷、限流、降級等，就會使得應用變得更加穩定。新的技術架構，比如Serverless、BaaS等使得應用無需關注分布式環境中的運作位置，減少了對于第三方元件的依賴，進而提升了整體的穩定性。
如何解決彈性問題
無伺服器架構模式按照業務峰值進行動态伸縮，避免了手工擴縮容。Service Mesh可以根據流量觀測以及資源消耗情況實作動态擴縮容。由于BaaS元件的出現，使得應用非常易于實作計算存儲分離，進而簡化自動擴縮容的處理。
如何解決可觀測性問題
在雲原生架構中存在Open Tracing标準友善不同的軟體架構實作Tracing，進而通過tag機制拉通業務流量與軟硬體基礎設施的可觀測性，這是原來架構所不具備的。此外，在Service Mesh和Serverless層實作了請求級的SLA測量，能夠很清晰地看到使用者查詢的某個接口是否達到了100 QPS的SLA。同樣的，對于使用者的查詢還可能涉及主資料等查詢，這樣可以對依賴關系進行分析來形成SLA鍊條并進一步提升。進一步看，今天雲原生的基礎設施由于具備了業務流量，是以能夠友善将網絡流量、服務流量以及業務流量和基礎設施運作情況形成大資料，進而比較好地幫助企業進行持續的IT服務治理。
生産流水線分析
基于DevOps的生産流水線、基于按領域劃分的組織結構，其技術複雜度得到了很大降低，特别是分布式環境下的技術複雜度得到了極大降低，這是因為分布式環境下的設計模式下沉到了雲原生中間件這樣的雲基礎設施當中，将分布式環境中的很多非功能性需求從業務架構或者業務包中剝離出來，直接放到了雲廠商所提供的軟體基礎設施當中。在實作成本上面，由于新增加了Serverless、Service Mesh架構，使得如今基于雲原生微服務的這些軟體對于所依賴的硬體可以實作按用量購買，進而進一步降低整體CAPEX。同樣的，這些技術的更新對于業務帶來更多的價值，可以進一步提升使用者體驗。這是因為在雲原生基礎設施和雲原生微服務架構裡面，軟硬體的穩定性都得到了極大的提升。此外，在這樣的基礎設施裡面，開發可以使用不同的技術棧、開發語言來快速實作業務，能夠幫助業務快速上線，并通過觀察業務試運作的情況判斷是否進一步推廣，是以多技術棧能夠幫助企業進一步加快業務疊代速度。
架構風險控制
正如前面所說的“沒有銀彈”，在雲原生微服務的架構之下，也無法解決所有問題，是以需要在架構層面進行風險控制。推薦大家在組織結構中增加架構控制委員會，這一角色最主要是從組織架構、技術架構以及業務架構的不斷更新和疊代的過程中不斷保持比對。除了控制變更，架構控制委員會還需要負責架構度量分析、架構風險治理以及規範架構設計原則等。對于一個組織而言，架構控制委員會可以是架構組，也可以将這以角色外包給其他咨詢廠商，進而保證企業架構技術演進和企業生産流水線比較好地比對，進而使得技術演進與業務需求具有更好的比對。
架構遷移路徑
微服務架構具有很多優點，今天無論是現有應用還是新建構的應用都會向着雲原生微服務的架構上進行演進。
對于現有的應用，特别是曆史債務比較沉重的應用而言，建議首先在架構分析層面充分地梳理技術和業務架構的風險點，特别是遺留系統部分；其次考慮如何進行內建，對于內建方面進行充分設計；最後，即使面對沉重的曆史負擔，也需要進行必要的改造，這是因為架構的遷移并非是一天能完成的，但不能遲遲不動，而可以通過必要的改造逐漸疊代完成。
而對于新建構的應用，由于其沒有太多的曆史負擔，一般而言遷移到微服務比較容易，是以也會提供最佳實踐為企業提供參考。通過對于最佳實踐的分析，可以了解做架構遷移的風險，分析完成之後可以依據最佳實踐進行小範圍POC驗證，之後通過阿裡雲等雲計算廠商所提供的解決方案和遷移工具實作快速、低成本上雲。
阿裡走過的路徑
前面分享了很多的技術，而阿裡巴巴作為一家巨大的網際網路公司，走過了一條完整的技術路線，從2008年的網際網路架構，到微服務架構再到雲原生架構。今天，除了應用上雲，不斷疊代IT基礎設施、應用基礎設施之外，阿裡巴巴還将相應服務輸出到外面，将最佳實踐也不斷分享給外界，是以也希望更多的公司能夠盡情擁抱雲原生微服務架構。