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

一、應(yīng)用架構(gòu)的演進(jìn)

應(yīng)用服務(wù)架構(gòu)一直處于不斷演進(jìn)的過程中，上圖通過對(duì)比5種比較主流的架構(gòu)模式，展示了應(yīng)用架構(gòu)的演進(jìn)歷程和變化。

1、單體架構(gòu)

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

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

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

2、RPC架構(gòu)

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

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

3、SOA架構(gòu)

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

1）ESB中心化架構(gòu)

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

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

2）以注冊(cè)服務(wù)為中心的服務(wù)注冊(cè)發(fā)現(xiàn)架構(gòu)

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

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

4、微服務(wù)架構(gòu)

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

5、服務(wù)網(wǎng)格架構(gòu)

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

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

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

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

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

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

二、貨拉拉的All In One Web到微服務(wù)治理

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

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

1、貨拉拉微服務(wù)治理的背景

1）微服務(wù)化碰到的問題

從2020年開始微服務(wù)化改造，當(dāng)時(shí)階段屬于類似的RPC架構(gòu)，是基于域名+HTTP的服務(wù)交互方式（圖上）。痛點(diǎn)在于：

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

2）微服務(wù)化需要解決的問題

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

2、貨拉拉微服務(wù)治理的框架選型

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

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

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

1）Dubbo2.X的缺點(diǎn)

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

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

2）Spring Cloud的缺點(diǎn)

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

3）自研微服務(wù)框架

我們對(duì)比后的結(jié)論是自研微服務(wù)框架，具體微服務(wù)體系中組件選型和設(shè)計(jì)思考如下：

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

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

框架設(shè)計(jì)參考Dubbo代碼的分層架構(gòu)和優(yōu)秀設(shè)計(jì)：

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

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

 ① 參考FeignClient定義接口方式

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

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

 ② 參考jsonrpc4j接口的定義方式

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

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

 ④ 標(biāo)準(zhǔn)JSONRPC接口的定義方式

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

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

服務(wù)治理管控平臺(tái)：soa-admin控制臺(tái)

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

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

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

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

1）增加的復(fù)雜性

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

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

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

3）延遲

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

4）平臺(tái)的依賴性

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