從單體到SOA架構，再從微服務架構到服務網格(Service Mesh)架構，企業應用架構領域每一次技術架構的演進都會給企業帶來更多的價值：職責解耦、能力復用、關注點分離、溝通效率提升、快速演進、快速交付和快速反饋。本次分享主要圍繞應用架構演進以及貨拉拉微服務治理的技術選型等進行思考。

一、應用架構的演進

應用服務架構一直處于不斷演進的過程中，上圖通過對比5種比較主流的架構模式，展示了應用架構的演進歷程和變化。

1、單體架構

在業務發展初期，為了快速落地應用、滿足客戶需求，一般會使用All in One的單體架構。

單體架構的特點是：在每個節點服務器中，包換應用的全部功能模塊代碼等所有模塊都耦合在一個進程里，系統完全封閉且很復雜，牽一發動全局；應用系統很臃腫，維護和版本升級開銷非常大。使用負載均衡分散訪問會話，提高并發處理能力。

單體架構是圍繞web容器打包及部署的架構模式，隨著業務的快速發展，要求實現服務的快速迭代和快速交付，應用架構也演進為以服務為中心的架構模式。

2、RPC架構

RPC架構在現在應用系統的早期還是比較常見的架構模式，就是增加服務層，把冗余的代碼和可以復用的業務應用進行拆分提取，封裝成服務。系統架構更加清晰，代碼質量提高，利于升級和維護，穩定性高。應用層可以更專注于與前端用戶交互。業務處理放在服務層來進行，服務和應用的管理不是自動化，服務層能夠實現HA的功能，適用中小型WEB系統的場景和高并發場景，性能比較好。RPC就是一個典型的RPC架構。

RPC架構也存在一些問題，通過共享分布式對象實現遠程方法調用，如果在其中一個對象中添加一個屬性，就會對共享對象的生產者與消費者產生影響，所以RPC架構也是緊耦合的模式。系統交互采用RPC私有TCP協議，服務生產者和消費者存在強代碼依賴，對異構系統集成不友好。

3、SOA架構

個人認為SOA架構經歷了兩個階段，一是以ESB中心化的架構，二是以注冊服務為中心的服務注冊發現架構（上圖）。

1）ESB中心化架構

ESB中心化架構實現了松耦合，依賴于ESB消息總線技術實現異構系統的信息交互和集成集中式架構管理，因此它雖然是面向服務的，但它本質上依舊是一個中心化的架構。

其優勢在于：基于WebService技術，擁有重量級的消息通訊機制。當團隊規模比較大、要實現異構系統集成時，它可以提供統一的解決方案和技術實現方式，快速集成異構系統對外服務。

2）以注冊服務為中心的服務注冊發現架構

• 注冊中心負責服務地址的注冊與查找，相當于目錄服務；
• ?服務提供者和消費者只在啟動和訂閱后發生變化時與注冊中心交互，注冊中心不轉發請求，壓力較小；
  
• ?應用層和服務層可以根據需求進行動態水平擴展，應用與服務實現負載均衡；
  
• 通過隨機、輪詢、權重等策略與開放式、標準化的框架，滿足接口調用的服務都可以接入服務框架（RPC）監控服務調用情況，可進一步對服務層再分層，根據業務需求和服務運行情況對服務進行編排、梳理以及服務治理。
  

以注冊服務為中心的服務注冊發現架構適用大型及超大型網站應用架構。所以ESB中心化架構的問題也比較明顯：中心化架構難以滿足靈活性的服務迭代和需求交付。

4、微服務架構

微服務架構實現了系統解耦和持續集成，有清晰的服務邊界，相對ESB架構和傳統SOA架構來說粒度更小，使用輕量級的通訊機制（HTTP+REST）交互，具備更強的擴展性和彈性，能夠更靈活、更快響應業務變化。

5、服務網格架構

服務網格架構是容器化的產物，引入了類似代理的Sidecar，在微服務SDK里面保留協議編解碼能力，把服務注冊與發現、負載均衡、熔斷、限流、降級等服務治理能力下沉到Sidecar。當該 sidecar 在微服務中大量部署時，這些 sidecar 節點自然就形成了一個網格。

服務網格架構的優勢：支持用多語言開發業務、省去或輕量化SDK，為異構服務框架/平臺創造了融合和發展的機會，讓服務框架/平臺的演進更自主、更敏捷，讓業務開發聚焦業務本身，無需關心安全、灰度、熔斷、限流、降級等普遍服務，治理能力更敏捷、更好管控，加速業務探索。

Service Mesh的終局：Mesh所有協議或框架。目前貨拉拉已經實現了Redis Mesh。

通過上述對比，我們不難發現，應用服務架構是在不斷演進的，而且其演進背后存在一定的邏輯，服務架構的演進主要取決于以下2個維度： 

• 業務維度，技術架構是由業務發展所處的時期和階段決定的，要能夠解決業務發展過程中的痛點。在進行架構選型時，需要考慮這個架構是否能滿足當前業務的需求，業務需求能否隨著架構的演進實現增量式的迭代。
  
• 技術維度，要滿足非功能需求，使業務快速跟上技術生態的發展。

綜上所述，應用架構演進的底層邏輯就是： 一切為了敏捷（低投入，快速滿足業務需求）。

二、貨拉拉的All In One Web到微服務治理

貨拉拉應用架構到現在為止經歷了All In One Web的單體架構，RPC架構，與現在的微服務架構。

• 單體架構階段：2014年發布的第一個版本就是PHP的All In One Web，一直延續到2016年。
• RPC架構階段：從2016年開始，業務量不斷上升，單體架構難以滿足業務需求，從單體應用里面拆出幾十個dcore，ucore等核心服務。雖然服務之間采用HTTP+REST的調用方式，不是RPC的調用方式，但這階段和RPC架構一樣，都不具備服務治理能力。
  
• 微服務階段：從2020年開始微服務化改造，一直到目前都還處于微服務階段。

1、貨拉拉微服務治理的背景

1）微服務化碰到的問題

從2020年開始微服務化改造，當時階段屬于類似的RPC架構，是基于域名+HTTP的服務交互方式（圖上）。痛點在于：

• 基于域名的管理方式成本非常高：服務調用都還用域名的方式，內部新服務上線都必須申請內部域名，當時已接近500個域名，域名維護成本非常高。
• 協議不統一：PHP和Java服務調用、采用HTTP+JSON的協議方式，但業務請求方式不統一，導致研發效率低，插入管理切面異常困難。當時內部業務協議請求方式有GET請求方式、JSON數據以HTTP BODY的POST方式、還有HTTP FORM表單方式。
• 沒服務治理能力：沒有服務注冊中心，沒有熔斷、降級等保障性能力。服務之間強關聯，調用鏈脆弱。若某旁支服務不可用，可能導致整條關鍵鏈路不可用，穩定性無法保證。
• 技術轉型：公司業務快速發展，大部分業務還是PHP開發，需要向Java轉型或者使用Java來重構。內部500+的應用/服務不能同時轉型或者重構，需逐步推進。

2）微服務化需要解決的問題

• 跨語言：支持內部PHP和JAVA服務相互調用。
• 時間窗口：開發周期3個月左右。
• 服務治理能力：具備熔斷、限流、降級等服務治理能力以及全鏈路灰度發布能力。
• 協議兼容要求： 具有泛化調用能力（需要類似FeignClient的調用方式，兼容老的PHP和Java服務）。
• 協議規范要求：提供標準化RPC的能力。
• 服務注冊發現：基于APPID的方式，考慮到后續容器化Service Mesh方式的服務治理要求。

2、貨拉拉微服務治理的框架選型

綜合上述需要解決的問題，技術選型和參考的框架：

• SOA架構：Dubbo
• 微服務架構：Spring Cloud
• 服務網格架構：Istio

公司內部基礎設施還未全面容器化，所以服務網格架構方式Istio先淘汰，剩下就是Dubbo和Spring Cloud。我們選型思考的出發點：框架上的缺點或者不足點是不是我們能接受或者克服的。

1）Dubbo2.X的缺點

2020年Dubbo 3.0還未Release，所以我們研究了Dubbo 2.X。

• Dubbo 2.X協議對云原生支持不友好；
• Dubbo 2.X不支持熔斷、限流、降級等服務治理能力，需要另外的Sentinel等框架支撐；
• Dubbo 3.X Release時間和版本穩定時間未知；
• 很強的RPC契約，沒有泛化調用能力，達不到兼容老的Java和PHP服務要求；
• Dubbo 2.X基于接口/服務(Inteface/Service)的服務注冊發現方式，對未來Service Mesh方向即基于APPID的服務注冊發現方式支持不友好。

2）Spring Cloud的缺點

• 臃腫、體系過于復雜、不夠輕量，雖然使用門檻低，但深入和改造成本較高；
• 打包的包過大，一般都大于100M，啟動后占用的內存也比較大；
  
• 服務調用協議采用HTTP+REST方式，協議管控能力較弱。

3）自研微服務框架

我們對比后的結論是自研微服務框架，具體微服務體系中組件選型和設計思考如下：

• 標準服務調用協議：JSON-RPC（支持Java和PHP服務相互調用）；
• 注冊中心：Consul；
• 服務治理：熔斷Hystrix（Hystrix有PHP版本支持）；
  
• 泛化調用：參考FeignClient的客戶端和jsonrpc4j服務定義機制；
  
• 框架設計：參考Dubbo的分層機制和優秀設計。

3、貨拉拉微服務治理的實現思路

框架設計參考Dubbo代碼的分層架構和優秀設計：

• dubbo-common
• dubbo-config
• dubbo-filter
• dubbo-metadata
• dubbo-monitor
• dubbo-registry
• dubbo-remoting
• dubbo-rpc
• dubbo-serialization
• dubbo-springboot

1）泛化調用的實現方式

 ① 參考FeignClient定義接口方式

@FeignClient(value= “XC-SERVICE-MANAGE-CMS”)

其中XC-SERVICE-MANAGE-CMS為下游應用的APPID，FeignClient在Spring Cloud體系中以APPID的方式發現服務。

 ② 參考jsonrpc4j接口的定義方式

@JsonRpcService("/path/to/MyService")
interface MyService {
... service methods ...
}

 ③ 泛化調用的接口定義方式

 ④ 標準JSONRPC接口的定義方式

2）服務治理能力整體實現方式

• 熔斷能力：集成Hystix框架。
• 治理配置：集成公司內部的配置中心。
• 監控能力：集成公司內部的監控中心。
• 治理控制臺：開發治理管控平臺soa-admin。

服務治理管控平臺：soa-admin控制臺

3）Java Agent版本服務治理能力實現方式

• 服務治理能力下沉到Java Agent；
• Java Agent模塊化、插件化，目前插件有Metric、Trace、SOA；
• Java Agent插件支持動態升級和灰度升級。

4、貨拉拉微服務治理的未來規劃

未來往Service Mesh演進，但生產落地仍有挑戰。

1）增加的復雜性

在一個已經很復雜的環境中引入代理、sidecar等組件會極大地增加運維的復雜性。

2）需要的專業知識

在容器編排器(如Kubernetes)之上添加Istio之類的服務網格，通常需要運維人員成為這兩種技術的專家。

3）延遲

服務網格是一種入侵的、復雜的技術，它能向服務架構中添加顯著的延遲。

4）平臺的依賴性

服務網格的侵入性迫使開發人員和運維人員適應一個高度自治的平臺，并遵守其規則。