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

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

成都創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計、網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的祥云網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

1、單體架構(gòu)

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

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

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

2、RPC架構(gòu)

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

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

3、SOA架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

綜上所述，應(yīng)用架構(gòu)演進的底層邏輯就是： 一切為了敏捷（低投入，快速滿足業(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ā)布的第一個版本就是PHP的All In One Web，一直延續(xù)到2016年。
• RPC架構(gòu)階段：從2016年開始，業(yè)務(wù)量不斷上升，單體架構(gòu)難以滿足業(yè)務(wù)需求，從單體應(yīng)用里面拆出幾十個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ù)化改造，當時階段屬于類似的RPC架構(gòu)，是基于域名+HTTP的服務(wù)交互方式（圖上）。痛點在于：

• 基于域名的管理方式成本非常高：服務(wù)調(diào)用都還用域名的方式，內(nèi)部新服務(wù)上線都必須申請內(nèi)部域名，當時已接近500個域名，域名維護成本非常高。
• 協(xié)議不統(tǒng)一：PHP和Java服務(wù)調(diào)用、采用HTTP+JSON的協(xié)議方式，但業(yè)務(wù)請求方式不統(tǒng)一，導(dǎo)致研發(fā)效率低，插入管理切面異常困難。當時內(nèi)部業(yè)務(wù)協(xié)議請求方式有GET請求方式、JSON數(shù)據(jù)以HTTP BODY的POST方式、還有HTTP FORM表單方式。
• 沒服務(wù)治理能力：沒有服務(wù)注冊中心，沒有熔斷、降級等保障性能力。服務(wù)之間強關(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ù)不能同時轉(zhuǎn)型或者重構(gòu)，需逐步推進。

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

• 跨語言：支持內(nèi)部PHP和JAVA服務(wù)相互調(diào)用。
• 時間窗口：開發(fā)周期3個月左右。
• 服務(wù)治理能力：具備熔斷、限流、降級等服務(wù)治理能力以及全鏈路灰度發(fā)布能力。
• 協(xié)議兼容要求： 具有泛化調(diào)用能力（需要類似FeignClient的調(diào)用方式，兼容老的PHP和Java服務(wù)）。
• 協(xié)議規(guī)范要求：提供標準化RPC的能力。
• 服務(wù)注冊發(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ā)點：框架上的缺點或者不足點是不是我們能接受或者克服的。

1）Dubbo2.X的缺點

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

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

2）Spring Cloud的缺點

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

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

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

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

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

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

• 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為下游應(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)用的接口定義方式

 ④ 標準JSONRPC接口的定義方式

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

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

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

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

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

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

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

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

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

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

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

3）延遲

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

4）平臺的依賴性

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

本文標題：貨拉拉應(yīng)用架構(gòu)演進，堪稱單體落地微服務(wù)避坑指南
分享URL：http://uogjgqi.cn/article/cdjeihd.html