摘要：微服務(wù)化是當(dāng)前電商產(chǎn)品演化的必然趨勢，網(wǎng)易考拉海購?fù)ㄟ^微服務(wù)化打破了業(yè)務(wù)爆發(fā)增長的架構(gòu)瓶頸。本文結(jié)合網(wǎng)易考拉海購引用的開源Dubbo框架，分享支持考拉微服務(wù)工作的基本原理。文章分析了使用Dubbo過程中遇到的問題，講解了團(tuán)隊(duì)所做的一些問題修復(fù)和功能集成工作，在此基礎(chǔ)上最終形成了考拉內(nèi)部持續(xù)維護(hù)升級的Dubbok框架。
本文背景還要從網(wǎng)易考拉海購（下文簡稱“考拉”）微服務(wù)化說起，現(xiàn)在任何大型的互聯(lián)網(wǎng)應(yīng)用，尤其是電商應(yīng)用從Monolithic單體應(yīng)用走向微服務(wù)化已經(jīng)是必然趨勢。微服務(wù)化是一個比較寬泛的概念，涉及到一個產(chǎn)品生命周期的多個方面，首先它作為一個指導(dǎo)原則指引業(yè)務(wù)劃分、架構(gòu)解耦等；技術(shù)層面實(shí)施微服務(wù)需要開發(fā)測試階段、運(yùn)行階段、發(fā)布階段、部署階段等一系列基礎(chǔ)框架的支撐。我們在享受服務(wù)化易擴(kuò)展易部署等便利性的同時，也面臨新的問題，如數(shù)據(jù)一致性、分布式調(diào)用鏈路追蹤、異常定位、日志采集等。 
本文將集中在支撐微服務(wù)交互、運(yùn)行的基礎(chǔ)框架講解上，即考拉當(dāng)前使用的Dubbok框架，Dubbok由阿里開源Dubbo框架的優(yōu)化和功能改進(jìn)而來。當(dāng)前開源上可選用的微服務(wù)框架主要有Dubbo、Spring Cloud等，鑒于Dubbo完備的功能和文檔且在國內(nèi)被眾多大型互聯(lián)網(wǎng)公司選用，考拉自然也選擇了Dubbo作為服務(wù)化的基礎(chǔ)框架。其實(shí)相比于Dubbo，Spring Cloud可以說是一個更完備的微服務(wù)解決方案，它從功能性上是Dubbo的一個超集，個人認(rèn)為從選型上對于一些中小型企業(yè)Spring Cloud可能是一個更好的選擇。提起Spring Cloud，一些開發(fā)的{dy}印象是http+JSON的rest通信，性能上難堪重用，其實(shí)這也是一種誤讀。


微服務(wù)選型要評估以下幾點(diǎn)：內(nèi)部是否存在異構(gòu)系統(tǒng)集成的問題；備選框架功能特性是否滿足需求；http協(xié)議的通信對于應(yīng)用的負(fù)載量會否真正成為瓶頸點(diǎn)（Spring Cloud也并不是和http+JSON強(qiáng)制綁定的，如有必要Thrift、protobuf等{gx}的RPC、序列化協(xié)議同樣可以作為替代方案）；社區(qū)活躍度、團(tuán)隊(duì)技術(shù)儲備等。作為已經(jīng)沒有團(tuán)隊(duì)持續(xù)維護(hù)的開源項(xiàng)目，選擇Dubbo框架內(nèi)部就必須要組建一個維護(hù)團(tuán)隊(duì)，先不論你要準(zhǔn)備要集成多少功能做多少改造，作為一個支撐所有工程正常運(yùn)轉(zhuǎn)的基礎(chǔ)組件，問題的及時響應(yīng)與解答、重大缺陷的及時修復(fù)能力就已足夠重要。


 


下文將選取Dubbo高性能RPC通信原理、服務(wù)注冊發(fā)現(xiàn)特性、依賴隔離、啟動與停機(jī)等幾個方面闡述Dubbok的工作原理和相關(guān)改進(jìn)工作。


 
高性能RPC
Dubbo作為一個分布式通信框架，最基本的職責(zé)就是完成跨進(jìn)程的遠(yuǎn)程調(diào)用（RPC）。以下是RPC基本流程圖：
RPC工作原理（圖片來自網(wǎng)絡(luò)）
RPC基本原理非常簡單，那么Dubbo是如何實(shí)現(xiàn){gx}的RPC通信的那，和其他分布式通信組件關(guān)注點(diǎn)一樣，主要集中在以下幾點(diǎn)的優(yōu)化： 
1.協(xié)議棧：


Dubbo支持自定義RPC協(xié)議，冗余字段少、通信性能高；
序列化協(xié)議支持hessian2、Dubbo自定義序列化等高性能協(xié)議；
Dubbo支持序列化協(xié)議解碼在業(yè)務(wù)線程（Netty3編碼自動在業(yè)務(wù)線程執(zhí)行）；


Dubbo RPC通信協(xié)議棧
2.線程模型：依賴Netty3的非阻塞線程模型，支持I/O、業(yè)務(wù)邏輯線程分離，通過Handler鏈處理請求。


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通過緩沖池減少分配釋放、DirectBuffer實(shí)現(xiàn)緩沖區(qū)零復(fù)制等。Netty這塊升級相對是一個高風(fēng)險(xiǎn)的點(diǎn)，明面上的API兼容性改造是小，如對Netty4工作原理認(rèn)識不足，新的線程模型、buffer緩沖池等帶來的非預(yù)期性能下降、內(nèi)存泄露等問題相對更難定位與跟蹤。 
講到線程模型，實(shí)現(xiàn)上密切相關(guān)的Dubbo網(wǎng)絡(luò)連接模型必須要提一下。Dubbo默認(rèn)是所有服務(wù)共享單一的TCP長連接的（這也是為什么服務(wù)接口不適合傳輸大負(fù)載值，即容易阻塞其他服務(wù)的調(diào)用）。為響應(yīng)慢或重要的服務(wù)接口考慮，Dubbo支持設(shè)置多TCP連接，此時連接數(shù)和線程池?cái)?shù)默認(rèn)是綁定的，即每連接對應(yīng)一個線池，consumer、provider都執(zhí)行這個策略，從線程隔離的角度講是合理的，但不注意也容易造成線程占用資源過多，尤其是對于消費(fèi)端基本無線程阻塞的情況下可能是一個設(shè)計(jì)缺陷。


 


3.緩沖區(qū)：Dubbo默認(rèn)使用的全部是heap緩沖區(qū)，因此Socket通信不可避免會存在內(nèi)核緩沖區(qū)和堆緩沖區(qū)復(fù)制消耗；除此之外在RPC協(xié)議解析（包括粘包/半包處理）、序列化協(xié)議解析等處理上也存在heap區(qū)內(nèi)的復(fù)制，因此性能上是存在優(yōu)化點(diǎn)的（當(dāng)然要確有必要）。


 
自動注冊/發(fā)現(xiàn)、負(fù)載均衡等服務(wù)化特性
高性能通信是Dubbo作為RPC框架的基本功能，但使其區(qū)別于Thrift、hessian、gRPC等框架的關(guān)鍵在于其新增的服務(wù)間自動協(xié)調(diào)、服務(wù)治理等特性。 
1. 服務(wù)自動注冊自動發(fā)現(xiàn)、負(fù)載均衡


服務(wù)自動注冊發(fā)現(xiàn)依賴于注冊中心的支持，consumer與provider通過注冊中心獲取各自地址后直接通信。目前考拉使用Zookeeper作為注冊中心，Dubbo原生支持Redis作為注冊中心，使用pub/sub機(jī)制協(xié)調(diào)服務(wù)的上下線事件通知，但Redis方案要求服務(wù)器時間同步且存在性能消耗過大的缺點(diǎn)。




消費(fèi)者/提供者注冊中心交互圖
使用Zookeeper作為注冊中心，建議選用curator作為客戶端框架；
 


Zookeeper服務(wù)器異常宕機(jī)并重新啟動的場景下，Dubbo服務(wù)的recover恢復(fù)機(jī)制存在不能重新注冊的問題，導(dǎo)致老zk session失效后服務(wù)被錯誤qc。
服務(wù)框架常見負(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等幾個方案。 
在實(shí)際應(yīng)用中，為了能對個別錯誤率較高的異常provider做到及時發(fā)現(xiàn)、及時引流，Dubbok增加了新的負(fù)載均衡策略，在支持權(quán)重的基礎(chǔ)上自動發(fā)現(xiàn)異常provider，異常期自動減流、正常后自動恢復(fù)流量。
 


2.路由、集群容錯、限流


和負(fù)載均衡策略一樣，Dubbo的路由方案是集成在消費(fèi)端的，加上集群容錯功能客戶端相對是一個重量的功能封裝。可選方案是將路由工作移到注冊中心完成（這要求注冊中心具有較強(qiáng)的可定制性，不僅路由像權(quán)限控制、服務(wù)過濾、環(huán)境隔離等都可由注冊中心集成）。


 


限流目前支持consumer、provider端并發(fā)限流，實(shí)際上是基于信號量限制的，以接口粒度分配信號量，當(dāng)信號量用完新的調(diào)用將被拒絕，當(dāng)業(yè)務(wù)返回后信號量被釋放。


 


消費(fèi)端限流應(yīng)該是為整個提供端集群分配信號量，而Dubbo錯誤的將信號量分配給單個機(jī)器。這個問題目前可以通過下文提到的隔離框架的流控功能來實(shí)現(xiàn)。 
限流并非jq限制，不應(yīng)當(dāng)依賴其實(shí)現(xiàn)嚴(yán)格的并發(fā)數(shù)控制。 
后端backend服務(wù)限流需要業(yè)務(wù)方合理評估每個接口的流控值，要求對業(yè)務(wù)量有足夠經(jīng)驗(yàn)值（可能要在多次線上調(diào)優(yōu)后才能最終得出合理的流控值）。考拉內(nèi)部流控實(shí)踐證明，對于保證服務(wù)穩(wěn)定性、優(yōu)先保證重要消費(fèi)方、實(shí)現(xiàn)服務(wù)隔離等有著重要的作用。
 


3.服務(wù)動態(tài)治理


動態(tài)治理本質(zhì)上是依賴Dubbo運(yùn)行期參數(shù)的動態(tài)調(diào)整，再通用一點(diǎn)其實(shí)就是應(yīng)用的參數(shù)動態(tài)調(diào)整，開源常用的disconf、diamond、archaius等集中配置管理工具都是設(shè)計(jì)來解決這個問題。Dubbo內(nèi)部在url參數(shù)傳遞模型基礎(chǔ)上實(shí)現(xiàn)了一套參數(shù)動態(tài)配置邏輯，個人認(rèn)為相比于Dubbo的實(shí)現(xiàn)，集成disconf等更專業(yè)的框架應(yīng)該是更好的解決方案，或許Dubbo為了一些其他設(shè)計(jì)目標(biāo)解除了對一些外部框架的強(qiáng)制依賴。動態(tài)治理可以實(shí)現(xiàn)從基本參數(shù)如timeout、mock到一些高級特性如路由、限流等幾乎所有的運(yùn)行期參數(shù)調(diào)整。


 


Dubbo原生在動態(tài)配置上存在很多bug，配置不生效或配置規(guī)則誤讀等問題都遇到過，如果你再使用原生Dubbo過程中也遇到任何配置問題，Dubbok應(yīng)該都已經(jīng)解決掉了。


 
依賴隔離（服務(wù)降級）
當(dāng)應(yīng)用被設(shè)計(jì)依賴外部服務(wù)時，要始終保持警惕狀態(tài)：外部依賴是不穩(wěn)定的，為此對接外部依賴做好解耦是關(guān)鍵，避免外部接口發(fā)生異常拖垮自身系統(tǒng)。Dubbo提供了超時timeout機(jī)制作為最基本的解耦措施，同時在接口報(bào)錯時支持提供降級的容錯邏輯；除了容錯降級，Dubbo進(jìn)一步支持強(qiáng)制的短路降級。


容錯  短路
然而在容錯降級與短路降級之間，Dubbo缺乏一種在容錯與短路間切換的機(jī)制，即自動熔斷。自動熔斷要達(dá)到的效果是：當(dāng)接口偶然報(bào)錯時執(zhí)行容錯返回備用數(shù)據(jù)，而當(dāng)接口持續(xù)大量報(bào)錯時能自動在消費(fèi)端對接口調(diào)用短路直接返回備用數(shù)據(jù)，之后持續(xù)監(jiān)測接口可用性，接口恢復(fù)后自動恢復(fù)調(diào)用。這樣能{zd0}限度減少接口異常對消費(fèi)方的影響，同時也減輕本就處于異常狀態(tài)的提供端負(fù)載。


自動熔斷工作原理圖
Dubbok通過標(biāo)準(zhǔn)SPI的的形式，實(shí)現(xiàn)了熔斷功能。目前支持兩套方案：一套是自己實(shí)現(xiàn)的熔斷邏輯；一套是通過集成hystrix框架實(shí)現(xiàn)。目前支持錯誤率、{zd1}請求量、熔斷時間窗等基本配置，支持將業(yè)務(wù)異常納入統(tǒng)計(jì)范疇；以上參數(shù)均可通過SOA治理平臺運(yùn)行期動態(tài)調(diào)整；支持外部Dubbo依賴調(diào)用的準(zhǔn)實(shí)時監(jiān)控。


SOA動態(tài)調(diào)整熔斷參數(shù)


依賴實(shí)時監(jiān)控
Hystrix是Netflix在微服務(wù)實(shí)踐中為實(shí)現(xiàn)外部依賴解耦而設(shè)計(jì)的框架，它假設(shè)所有的外部依賴（http、MySQL、Redis等等）可能在任何時間出現(xiàn)問題（你甚至可以想像不經(jīng)意間就使用了一個沒有提供超時設(shè)置的http客戶端）。于任何可能的外部延時造成的阻塞或其他異常，hystix提供了基于線程池隔離的超時機(jī)制，新版本在RxJava基礎(chǔ)上信號量隔離也同樣支持超時。此外框架還支持定制容錯邏輯、請求結(jié)果緩存、請求合并、消費(fèi)端線程池隔離等，由于某些功能當(dāng)前無明確需求或與Dubbo功能設(shè)計(jì)重合而沒有進(jìn)行集成。 
Hystrix更多特性及實(shí)現(xiàn)原理請參見Netflix官方文檔。


 
啟動與停機(jī)
這里主要關(guān)注Dubbo工程啟動初始化階段和停機(jī)銷毀階段的一些特性和改進(jìn)點(diǎn)： 
1.延遲暴露。


默認(rèn)Dubbo服務(wù)會隨著Spring框架的加載逐一完成服務(wù)到注冊中心的注冊（暴露），如果某些服務(wù)需要等待資源就位才能暴露，那就需要延時注冊。






 


增加Spring context初始化完成后繼續(xù)延時等待的配置項(xiàng)；
 


在無特殊配置的情況下，所有的Dubbo服務(wù)默認(rèn)是注冊在同一個tcp端口的。而延遲暴露是通過開啟新的延時線程實(shí)現(xiàn)的，當(dāng)延時結(jié)束時由于多線程并發(fā)執(zhí)行導(dǎo)致多服務(wù)隨機(jī)注冊在多個端口。
 


2.啟動預(yù)熱


一些應(yīng)用在運(yùn)行期會通過本地緩存中間結(jié)果提升性能，而當(dāng)此類應(yīng)用重啟時本地緩存數(shù)據(jù)丟失，如果重啟后的機(jī)器立即有大量請求導(dǎo)流過來，由于沒有緩存加速會導(dǎo)致請求阻塞響應(yīng)性能降低。通過對重啟后的機(jī)器設(shè)置預(yù)熱期可有效緩解重啟緩存失效問題：具體做法是降低預(yù)熱期內(nèi)的機(jī)器權(quán)重，引導(dǎo)少部分流量到此機(jī)器，此機(jī)器可以在預(yù)熱期內(nèi)逐步建立緩存，待預(yù)熱期過后恢復(fù)正常權(quán)重與其他機(jī)器平均分?jǐn)偭髁俊?br />

 


3.優(yōu)雅停機(jī)


在集群部署的情況下，單個消費(fèi)者或提供者機(jī)器上下線對整個產(chǎn)品的運(yùn)轉(zhuǎn)應(yīng)該是近乎無感知的，Dubbo提供了優(yōu)雅停機(jī)功機(jī)制保障在進(jìn)程關(guān)閉前請求都得到妥善處理。


 


消費(fèi)方優(yōu)雅停機(jī)：控制不再有新的請求發(fā)出；等待已經(jīng)發(fā)出的請求正確返回；釋放連接等資源。


 


提供方優(yōu)雅停機(jī)：通知消費(fèi)端停止發(fā)送請求到當(dāng)前機(jī)器；通知注冊中心服務(wù)下線；等待已經(jīng)接收的請求處理完成并返回；釋放連接等資源。


 


考拉再每次服務(wù)上下線過程中，每個工程總是收到大量的消費(fèi)方/提供方報(bào)出的服務(wù)調(diào)用異常，經(jīng)排查是Dubbo優(yōu)雅停機(jī)實(shí)現(xiàn)的問題，修復(fù)問題后工程上線階段異常數(shù)明顯減少。
 


另外停機(jī)階段總是莫名的收到zk連接為空的異常信息。是由于在通知注冊中心服務(wù)下線的過程中，Spring銷毀線程和jvm hook線程并發(fā)執(zhí)行，導(dǎo)致zk客戶端被提前銷毀導(dǎo)致拋出異常。
 


4.Provider重啟，注冊中心發(fā)送大量服務(wù)銷毀與注冊通知導(dǎo)致consumer工程Full GC。


歷史原因，考拉內(nèi)部仍存在一個提供近200個Dubbo服務(wù)的單體工程，而每次當(dāng)這個工程上線時，消費(fèi)它的consumer工程就會出現(xiàn)頻繁Full GC（3-5次，非內(nèi)存泄露）。 
是Dubbo為保證高可用而設(shè)計(jì)的注冊中心緩存導(dǎo)致的問題：在每次收到注冊中心變更時consumer會在本地磁盤保存一份服務(wù)數(shù)據(jù)副本，由于多注冊中心共享同一份緩存文件，為了避免相互覆蓋，每個注冊中心實(shí)例會在收到變更時重新從磁盤加載文件到緩存，和變更數(shù)據(jù)對比后重新寫回磁盤，在近100提供者機(jī)器不斷重啟的過程中，大量的變更通知導(dǎo)致的頻繁加載緩存文件占用大量內(nèi)存導(dǎo)致Full GC。
 


Dubbok近期優(yōu)化目標(biāo)
提供端線程池隔離，解決提供端線程池阻塞等問題；優(yōu)化消費(fèi)端線程池分配方案
服務(wù)治理動態(tài)配置功能增加應(yīng)用、機(jī)器粒度的配置
多注冊中心消費(fèi)端負(fù)載均衡策略
Dubbo內(nèi)部資源JMX監(jiān)控
結(jié)合SOA平臺優(yōu)化監(jiān)控統(tǒng)計(jì)數(shù)據(jù)：錯誤類型細(xì)分（超時、限流、網(wǎng)絡(luò)異常等）；執(zhí)行時間細(xì)分如90%、99% RT等；統(tǒng)計(jì)占用線程數(shù)較多的服務(wù)、傳送數(shù)據(jù)量較大的服務(wù)，為分線程池或連接做參考
對Spring boot推行的Javaconfig配置方式提供更友好、全面的注解支持
一些框架升級，如Javassist、Netty等
替代Zookeeper的高性能、可擴(kuò)展注冊中心
服務(wù)安全、授權(quán)問題調(diào)研
Spring Cloud的一些{yx}特性將作為Dubbok改進(jìn)的一個持續(xù)關(guān)注點(diǎn)
……
 
總結(jié)
文中提到的一些改進(jìn)點(diǎn)只是簡略描述，Dubbok的很多改進(jìn)點(diǎn)也沒有一一提及，后續(xù)有時間再詳細(xì)道來。 
Dubbok框架、SOA服務(wù)治理平臺、分布式調(diào)用鏈路跟蹤以及其他考拉內(nèi)部維護(hù)的如分布式事務(wù)、消息中間件等共同支撐了考拉微服務(wù)化的正常運(yùn)轉(zhuǎn)。上文也提到微服務(wù)需要有開發(fā)、測試、運(yùn)行、運(yùn)維、部署、發(fā)布等各階段的全鏈路支撐才能發(fā)揮{zd0}價值，后續(xù)我們將繼續(xù)聯(lián)合其他兄弟部門，對微服務(wù)化實(shí)踐進(jìn)一步優(yōu)化。


——劉軍


網(wǎng)易考拉海購