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

一、應用架構的演進

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

1、單體架構

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

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

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

2、RPC架構

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

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

3、SOA架構

個人認為SOA架構經(jīng)歷了兩個階段，一是以ESB中心化的架構，二是以注冊服務為中心的服務注冊發(fā)現(xiàn)架構（上圖）。

1）ESB中心化架構

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

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

2）以注冊服務為中心的服務注冊發(fā)現(xiàn)架構

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

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

4、微服務架構

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

5、服務網(wǎng)格架構

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

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

Service Mesh的終局：Mesh所有協(xié)議或框架。目前貨拉拉已經(jīng)實現(xiàn)了Redis Mesh。

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

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

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

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

貨拉拉應用架構到現(xiàn)在為止經(jīng)歷了All In One Web的單體架構，RPC架構，與現(xiàn)在的微服務架構。

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

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

1）微服務化碰到的問題

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

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

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

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

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

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

• SOA架構：Dubbo
• 微服務架構：Spring Cloud
• 服務網(wǎng)格架構：Istio

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

1）Dubbo2.X的缺點

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

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

2）Spring Cloud的缺點

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

3）自研微服務框架

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

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

3、貨拉拉微服務治理的實現(xiàn)思路

框架設計參考Dubbo代碼的分層架構和優(yōu)秀設計：

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

1）泛化調(diào)用的實現(xiàn)方式

 ① 參考FeignClient定義接口方式

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

其中XC-SERVICE-MANAGE-CMS為下游應用的APPID，F(xiàn)eignClient在Spring Cloud體系中以APPID的方式發(fā)現(xiàn)服務。

 ② 參考jsonrpc4j接口的定義方式

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

 ③ 泛化調(diào)用的接口定義方式

 ④ 標準JSONRPC接口的定義方式

2）服務治理能力整體實現(xiàn)方式

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

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

3）Java Agent版本服務治理能力實現(xiàn)方式

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

4、貨拉拉微服務治理的未來規(guī)劃

未來往Service Mesh演進，但生產(chǎn)落地仍有挑戰(zhàn)。

1）增加的復雜性

在一個已經(jīng)很復雜的環(huán)境中引入代理、sidecar等組件會極大地增加運維的復雜性。

2）需要的專業(yè)知識

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

3）延遲

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

4）平臺的依賴性

服務網(wǎng)格的侵入性迫使開發(fā)人員和運維人員適應一個高度自治的平臺，并遵守其規(guī)則。