本文背景還要從網(wǎng)易考拉海購(gòu)(下文簡(jiǎn)稱“考拉”)微服務(wù)化說(shuō)起，現(xiàn)在任何大型的互聯(lián)網(wǎng)應(yīng)用，尤其是電商應(yīng)用從Monolithic單體應(yīng)用走向微服務(wù)化已經(jīng)是必然趨勢(shì)。微服務(wù)化是一個(gè)比較寬泛的概念，涉及到一個(gè)產(chǎn)品生命周期的多個(gè)方面，首先它作為一個(gè)指導(dǎo)原則指引業(yè)務(wù)劃分、架構(gòu)解耦等；技術(shù)層面實(shí)施微服務(wù)需要開(kāi)發(fā)測(cè)試階段、運(yùn)行階段、發(fā)布階段、部署階段等一系列基礎(chǔ)框架的支撐。我們?cè)谙硎芊⻊?wù)化易擴(kuò)展易部署等便利性的同時(shí)，也面臨新的問(wèn)題，如數(shù)據(jù)一致性、分布式調(diào)用鏈路追蹤、異常定位、日志采集等。
本文將集中在支撐微服務(wù)交互、運(yùn)行的基礎(chǔ)框架講解上，即考拉當(dāng)前使用的Dubbok框架，Dubbok由阿里開(kāi)源Dubbo框架的優(yōu)化和功能改進(jìn)而來(lái)。當(dāng)前開(kāi)源上可選用的微服務(wù)框架主要有Dubbo、Spring Cloud等，鑒于Dubbo完備的功能和文檔且在國(guó)內(nèi)被眾多大型互聯(lián)網(wǎng)公司選用，考拉自然也選擇了Dubbo作為服務(wù)化的基礎(chǔ)框架。其實(shí)相比于Dubbo，Spring Cloud可以說(shuō)是一個(gè)更完備的微服務(wù)解決方案，它從功能性上是Dubbo的一個(gè)超集，個(gè)人認(rèn)為從選型上對(duì)于一些中小型企業(yè)Spring Cloud可能是一個(gè)更好的選擇。提起Spring Cloud，一些開(kāi)發(fā)的第一印象是http+JSON的rest通信，性能上難堪重用，其實(shí)這也是一種誤讀。微服務(wù)選型要評(píng)估以下幾點(diǎn)：內(nèi)部是否存在異構(gòu)系統(tǒng)集成的問(wèn)題；備選框架功能特性是否滿足需求；http協(xié)議的通信對(duì)于應(yīng)用的負(fù)載量會(huì)否真正成為瓶頸點(diǎn)(Spring Cloud也并不是和http+JSON強(qiáng)制綁定的，如有必要Thrift、protobuf等高效的RPC、序列化協(xié)議同樣可以作為替代方案)；社區(qū)活躍度、團(tuán)隊(duì)技術(shù)儲(chǔ)備等。作為已經(jīng)沒(méi)有團(tuán)隊(duì)持續(xù)維護(hù)的開(kāi)源項(xiàng)目，選擇Dubbo框架內(nèi)部就必須要組建一個(gè)維護(hù)團(tuán)隊(duì)，先不論你要準(zhǔn)備要集成多少功能做多少改造，作為一個(gè)支撐所有工程正常運(yùn)轉(zhuǎn)的基礎(chǔ)組件，問(wèn)題的及時(shí)響應(yīng)與解答、重大缺陷的及時(shí)修復(fù)能力就已足夠重要。
下文將選取Dubbo高性能RPC通信原理、服務(wù)注冊(cè)發(fā)現(xiàn)特性、依賴隔離、啟動(dòng)與停機(jī)等幾個(gè)方面闡述Dubbok的工作原理和相關(guān)改進(jìn)工作。
一、高性能RPC
Dubbo作為一個(gè)分布式通信框架，最基本的職責(zé)就是完成跨進(jìn)程的遠(yuǎn)程調(diào)用(RPC)。以下是RPC基本流程圖：
RPC基本原理非常簡(jiǎn)單，那么Dubbo是如何實(shí)現(xiàn)高效的RPC通信的呢，和其他分布式通信組件關(guān)注點(diǎn)一樣，主要集中在以下幾點(diǎn)的優(yōu)化：
1.協(xié)議棧：
Dubbo支持自定義RPC協(xié)議，冗余字段少、通信性能高；
序列化協(xié)議支持hessian2、Dubbo自定義序列化等高性能協(xié)議；
Dubbo支持序列化協(xié)議解碼在業(yè)務(wù)線程(Netty3編碼自動(dòng)在業(yè)務(wù)線程執(zhí)行)；
Dubbo RPC通信協(xié)議棧
2.線程模型：
依賴Netty3的非阻塞線程模型，支持I/O、業(yè)務(wù)邏輯線程分離，通過(guò)Handler鏈處理請(qǐng)求。
Netty基本線程模型
Dubbo業(yè)務(wù)線程與netty3 IO線程交互
這里特別強(qiáng)調(diào)Netty3，是因?yàn)镹etty4在線程模型、buffer緩沖區(qū)等方面做了重大的設(shè)計(jì)和性能改進(jìn)，包括Inbound、Outbound事件強(qiáng)制在I/O線程發(fā)起、buffer通過(guò)緩沖池減少分配釋放、DirectBuffer實(shí)現(xiàn)緩沖區(qū)零復(fù)制等。Netty這塊升級(jí)相對(duì)是一個(gè)高風(fēng)險(xiǎn)的點(diǎn)，明面上的API兼容性改造是小，如對(duì)Netty4工作原理認(rèn)識(shí)不足，新的線程模型、buffer緩沖池等帶來(lái)的非預(yù)期性能下降、內(nèi)存泄露等問(wèn)題相對(duì)更難定位與跟蹤。
講到線程模型，實(shí)現(xiàn)上密切相關(guān)的Dubbo網(wǎng)絡(luò)連接模型必須要提一下。Dubbo默認(rèn)是所有服務(wù)共享單一的TCP長(zhǎng)連接的(這也是為什么服務(wù)接口不適合傳輸大負(fù)載值，即容易阻塞其他服務(wù)的調(diào)用)。為響應(yīng)慢或重要的服務(wù)接口考慮，Dubbo支持設(shè)置多TCP連接，此時(shí)連接數(shù)和線程池?cái)?shù)默認(rèn)是綁定的，即每連接對(duì)應(yīng)一個(gè)線池，consumer、provider都執(zhí)行這個(gè)策略，從線程隔離的角度講是合理的，但不注意也容易造成線程占用資源過(guò)多，尤其是對(duì)于消費(fèi)端基本無(wú)線程阻塞的情況下可能是一個(gè)設(shè)計(jì)缺陷。
3.緩沖區(qū)：
Dubbo默認(rèn)使用的全部是heap緩沖區(qū)，因此Socket通信不可避免會(huì)存在內(nèi)核緩沖區(qū)和堆緩沖區(qū)復(fù)制消耗；除此之外在RPC協(xié)議解析(包括粘包/半包處理)、序列化協(xié)議解析等處理上也存在heap區(qū)內(nèi)的復(fù)制，因此性能上是存在優(yōu)化點(diǎn)的(當(dāng)然要確有必要)。
二、自動(dòng)注冊(cè)/發(fā)現(xiàn)、負(fù)載均衡等服務(wù)化特性
高性能通信是Dubbo作為RPC框架的基本功能，但使其區(qū)別于Thrift、hessian、gRPC等框架的關(guān)鍵在于其新增的服務(wù)間自動(dòng)協(xié)調(diào)、服務(wù)治理等特性。
1. 服務(wù)自動(dòng)注冊(cè)自動(dòng)發(fā)現(xiàn)、負(fù)載均衡
服務(wù)自動(dòng)注冊(cè)發(fā)現(xiàn)依賴于注冊(cè)中心的支持，consumer與provider通過(guò)注冊(cè)中心獲取各自地址后直接通信。目前考拉使用Zookeeper作為注冊(cè)中心，Dubbo原生支持Redis作為注冊(cè)中心，使用pub/sub機(jī)制協(xié)調(diào)服務(wù)的上下線事件通知，但Redis方案要求服務(wù)器時(shí)間同步且存在性能消耗過(guò)大的缺點(diǎn)。
消費(fèi)者/提供者注冊(cè)中心交互圖
使用Zookeeper作為注冊(cè)中心，建議選用curator作為客戶端框架；
Zookeeper服務(wù)器異常宕機(jī)并重新啟動(dòng)的場(chǎng)景下，Dubbo服務(wù)的recover恢復(fù)機(jī)制存在不能重新注冊(cè)的問(wèn)題，導(dǎo)致老zk session失效后服務(wù)被錯(cuò)誤清除。
服務(wù)框架常見(jiàn)負(fù)載均衡實(shí)現(xiàn)方案包括：集中式、分布式，分布式又可分進(jìn)程內(nèi)、分進(jìn)程兩種。Dubbo采用的是服務(wù)發(fā)現(xiàn)和負(fù)載均衡共同集成在consumer端的分布式進(jìn)程內(nèi)解決方案
Dubbo負(fù)載均衡策略
負(fù)載均衡策略上Dubbo原生提供的有基于權(quán)重隨機(jī)負(fù)載、最少活躍數(shù)優(yōu)先、Roundrobin、一致性Hash等幾個(gè)方案。
在實(shí)際應(yīng)用中，為了能對(duì)個(gè)別錯(cuò)誤率較高的異常provider做到及時(shí)發(fā)現(xiàn)、及時(shí)引流，Dubbok增加了新的負(fù)載均衡策略，在支持權(quán)重的基礎(chǔ)上自動(dòng)發(fā)現(xiàn)異常provider，異常期自動(dòng)減流、正常后自動(dòng)恢復(fù)流量。
2.路由、集群容錯(cuò)、限流
和負(fù)載均衡策略一樣，Dubbo的路由方案是集成在消費(fèi)端的，加上集群容錯(cuò)功能客戶端相對(duì)是一個(gè)重量的功能封裝。可選方案是將路由工作移到注冊(cè)中心完成(這要求注冊(cè)中心具有較強(qiáng)的可定制性，不僅路由像權(quán)限控制、服務(wù)過(guò)濾、環(huán)境隔離等都可由注冊(cè)中心集成)
限流目前支持consumer、provider端并發(fā)限流，實(shí)際上是基于信號(hào)量限制的，以接口粒度分配信號(hào)量，當(dāng)信號(hào)量用完新的調(diào)用將被拒絕，當(dāng)業(yè)務(wù)返回后信號(hào)量被釋放。
消費(fèi)端限流應(yīng)該是為整個(gè)提供端集群分配信號(hào)量，而Dubbo錯(cuò)誤的將信號(hào)量分配給單個(gè)機(jī)器。這個(gè)問(wèn)題目前可以通過(guò)下文提到的隔離框架的流控功能來(lái)實(shí)現(xiàn)。
限流并非精確限制，不應(yīng)當(dāng)依賴其實(shí)現(xiàn)嚴(yán)格的并發(fā)數(shù)控制。
后端backend服務(wù)限流需要業(yè)務(wù)方合理評(píng)估每個(gè)接口的流控值，要求對(duì)業(yè)務(wù)量有足夠經(jīng)驗(yàn)值(可能要在多次線上調(diào)優(yōu)后才能最終得出合理的流控值)。考拉內(nèi)部流控實(shí)踐證明，對(duì)于保證服務(wù)穩(wěn)定性、優(yōu)先保證重要消費(fèi)方、實(shí)現(xiàn)服務(wù)隔離等有著重要的作用。
3.服務(wù)動(dòng)態(tài)治理
動(dòng)態(tài)治理本質(zhì)上是依賴Dubbo運(yùn)行期參數(shù)的動(dòng)態(tài)調(diào)整，再通用一點(diǎn)其實(shí)就是應(yīng)用的參數(shù)動(dòng)態(tài)調(diào)整，開(kāi)源常用的disconf、diamond、archaius等集中配置管理工具都是設(shè)計(jì)來(lái)解決這個(gè)問(wèn)題。Dubbo內(nèi)部在url參數(shù)傳遞模型基礎(chǔ)上實(shí)現(xiàn)了一套參數(shù)動(dòng)態(tài)配置邏輯，個(gè)人認(rèn)為相比于Dubbo的實(shí)現(xiàn)，集成disconf等更專業(yè)的框架應(yīng)該是更好的解決方案，或許Dubbo為了一些其他設(shè)計(jì)目標(biāo)解除了對(duì)一些外部框架的強(qiáng)制依賴。動(dòng)態(tài)治理可以實(shí)現(xiàn)從基本參數(shù)如timeout、mock到一些高級(jí)特性如路由、限流等幾乎所有的運(yùn)行期參數(shù)調(diào)整。
Dubbo原生在動(dòng)態(tài)配置上存在很多bug，配置不生效或配置規(guī)則誤讀等問(wèn)題都遇到過(guò)，如果你再使用原生Dubbo過(guò)程中也遇到任何配置問(wèn)題，Dubbok應(yīng)該都已經(jīng)解決掉了。
三、依賴隔離(服務(wù)降級(jí))
當(dāng)應(yīng)用被設(shè)計(jì)依賴外部服務(wù)時(shí)，要始終保持警惕狀態(tài)：外部依賴是不穩(wěn)定的，為此對(duì)接外部依賴做好解耦是關(guān)鍵，避免外部接口發(fā)生異常拖垮自身系統(tǒng)。Dubbo提供了超時(shí)timeout機(jī)制作為最基本的解耦措施，同時(shí)在接口報(bào)錯(cuò)時(shí)支持提供降級(jí)的容錯(cuò)邏輯；除了容錯(cuò)降級(jí)，Dubbo進(jìn)一步支持強(qiáng)制的短路降級(jí)。
容錯(cuò) 短路
然而在容錯(cuò)降級(jí)與短路降級(jí)之間，Dubbo缺乏一種在容錯(cuò)與短路間切換的機(jī)制，即自動(dòng)熔斷。自動(dòng)熔斷要達(dá)到的效果是：當(dāng)接口偶然報(bào)錯(cuò)時(shí)執(zhí)行容錯(cuò)返回備用數(shù)據(jù)，而當(dāng)接口持續(xù)大量報(bào)錯(cuò)時(shí)能自動(dòng)在消費(fèi)端對(duì)接口調(diào)用短路直接返回備用數(shù)據(jù)，之后持續(xù)監(jiān)測(cè)接口可用性，接口恢復(fù)后自動(dòng)恢復(fù)調(diào)用。這樣能最大限度減少接口異常對(duì)消費(fèi)方的影響，同時(shí)也減輕本就處于異常狀態(tài)的提供端負(fù)載。
自動(dòng)熔斷工作原理圖
Dubbok通過(guò)標(biāo)準(zhǔn)SPI的的形式，實(shí)現(xiàn)了熔斷功能。目前支持兩套方案：一套是自己實(shí)現(xiàn)的熔斷邏輯；一套是通過(guò)集成hystrix框架實(shí)現(xiàn)。目前支持錯(cuò)誤率、最低請(qǐng)求量、熔斷時(shí)間窗等基本配置，支持將業(yè)務(wù)異常納入統(tǒng)計(jì)范疇；以上參數(shù)均可通過(guò)SOA治理平臺(tái)運(yùn)行期動(dòng)態(tài)調(diào)整；支持外部Dubbo依賴調(diào)用的準(zhǔn)實(shí)時(shí)監(jiān)控。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.guhuozai8.cn/
本文標(biāo)題：網(wǎng)易考拉海購(gòu)Dubbok框架優(yōu)化詳解
本文網(wǎng)址：http://www.guhuozai8.cn/html/support/11121520450.html
相關(guān)文章
