Dubbo筆記(一)

叉不到魚的harpoon發表於2020-06-14

一.簡介

在編寫分散式場景下高併發、高擴充套件的系統對技能的要求很高,因為這個過程會涉及到序列化/反序列化、多執行緒、網路程式設計、設計模式、效能優化等眾多專業知識。而Dubbo框架對這些專業知識做了更高層的抽象和封裝,提供了開箱即用的特性。所以換句話說Dubbo是為了解決大流量、高併發場景下提供高可用、提升系統效能的這樣一個服務治理方案,也是優秀的RPC框架之一,因此被眾多公司採用並根據自己的業務實現擴充套件。

Dubbo提供了註冊中心機制,解耦了服務方和消費方動態發現的問題,並提供了高可靠能力,大量採用微核心+富外掛設計思想,包括框架自身核心特性都作為擴充套件點實現,提供了靈活的擴充套件點能力。

 

二.架構

1.服務提供者Provider啟動時會向註冊中心把自己的後設資料註冊上去(比如服務IP、埠及需要註冊的介面定義等資訊);
2.服務消費方Consumer在啟動時會從註冊中心訂閱(第一次訂閱會拉取全量資料)服務提供方的後設資料;
3.而當註冊中心資料發生變更時會推送給訂閱的Consumer(比如Provider某個節點Down掉了,又或者服務提供方進行了擴容,增加了節點。);
4.Consumer獲取到後設資料後,Consumer可以發起RPC呼叫(本質其實是Socket通訊+動態代理這樣的一個實現機制);
5.RPC呼叫前後會向監控中心上報統計資訊(比如併發數和呼叫介面)。

 

 

Dubbo總體分為業務層(Biz)、RPC層、Remote三層。如果把每一層繼續細化,那一共可以分為10層。可以參考下圖,圖中左邊是具體的分層,右邊是該層中比較重要的介面:

 

 

 

 

其中ServiceConfig兩層可以認為是API層,主要提供給API使用者,使用者無需關係底層的實現,只需要配置和完成業務程式碼即可;後面所有層級合在一起,可以認為是SPI層,主要提供給擴充套件者使用,即使用者可以基於Dubbo框架做定製性的二次開發,擴充套件其功能。

 

 

Dubbo核心元件:

 

1.Service
業務層。包括業務程式碼介面與實現,即我們自己實現的業務程式碼。

 

2.config
配置層。主要圍繞ServiceConfig(暴露的服務配置)和ReferenceConfig(引用的服務配置)兩個實現類展開,初始化配置資訊。可以理解為該層管理整個Dubbo配置。

 

3.proxy
服務代理層。在Dubbo中,無論生產者還是消費者,框架都會生成一個代理類,整個過程對上層是透明的。當呼叫一個遠端介面時,看起來就像呼叫本地介面一樣,代理層會自動做遠端呼叫並返回結果,即讓業務層對遠端呼叫完全無感。

 

4.registry
註冊層。服務Dubbo框架的服務註冊與發現。當所有新的服務加入或者就服務下線時,註冊中心都會感知並通知訂閱方。整個過程不需要人工參與。

 

5.cluster
叢集容錯層。主要負責遠端呼叫失敗時的容錯策略(如失敗重試、快速失敗);選擇具體呼叫節點時的複雜均衡策略(如隨機、一致性Hash等);特殊呼叫路徑的路由策略(如某個Consumer只會呼叫某個IPProvider)。

 

6.monitor
監控層。複雜監控統計呼叫次數和呼叫時間等。

 

7.protocol
遠端呼叫層。封裝RPC呼叫的具體過程,ProtocolInvoker暴露(釋出一個新功能讓別人呼叫)和引用(引用一個遠端服務到本地)的主功能入口。它負責管理Invoker的整個生命週期。InvokerDubbo核心模型,框架中所有其他模型都向它靠攏,或者轉換成它,它代表一個可執行體。

 

8.exchange
資訊交換層。建立Request-Response模型,封裝請求響應模式,如吧同步請求轉化為一步請求。

 

9.transport
網路傳輸層。把網路傳輸抽象為同一的介面,如MinaNetty雖然介面不一樣,但是Dubbo在他們上面又封裝了統一的介面。我們也可以根據其擴充套件介面新增更多的網路傳輸方式。

 

10.Serialize
序列化層。如果資料要通過網路進行傳送,則需要先做做序列化,變成二進位制流。序列化層負責管理整個框架網路傳輸時的序列化/反序列化工作。

  

三.特性及解決問題

特性:

1.面向介面代理的改效能RPC呼叫
提供了高效能的基於代理的遠端呼叫能力,服務以介面為粒度,為開發者遮蔽呼叫的遠端細節。

2.服務自動註冊與發現
支援多種註冊中心服務,服務例項上下線實時感知(上圖中的第3步)。

3.執行期流量排程
內建條件、指令碼等路由策略,通過配置不同的路由規則,輕鬆實現灰度釋出、同機房優先等功能。

4.智慧負載均衡
內建多種負載均衡策略,智慧感知下游節點健康狀況,顯著減少呼叫延遲,提高系統吞吐量。

5.高度可擴充套件能力
遵循微核心+外掛的設計思想,所有核心能力如ProtocolTransportSerialization被設計為擴充套件點,平等對待內建實現和第三方實現。(Dubbo SPI 擴充套件點機制)

6.視覺化的服務治理與運維
提供了豐富服務治理、運維工具(Dubbo Admin):隨時查詢服務後設資料、服務簡況狀態及呼叫統計,實時下發路由策略、調整配置引數。

 

解決問題:

 

1) 高效能、透明的RPC呼叫。只要涉及服務之間的通訊,RPC就必不可。Dubbo可以讓我們像呼叫本地服務一樣簡單的去呼叫遠端服務,而不需要再程式碼中顯示的指定遠端呼叫。整個過程對上層開發者透明,Dubbo會自動完成後續的所有操作,例如:負載均衡、路由、協議轉換、序列化等。開發者只需要接收對應的呼叫結果。

 

2)服務的自動註冊與發現。當服務越來越多時,服務URL配置管理變得非常困難,服務的註冊與發現已經不可能由人工來管理。此時需要一個註冊中心,動態的註冊和發現服務,使服務的位置透明。Dubbo適配了多種註冊中心。

 

3)自動負載與容錯。 當服務越來越多時,F5一年負載均衡器的單點壓力也原來越大,Dubbo提供了完整的叢集容錯機制,可以實現軟體層面的負載均衡,依次降低硬體的壓力。Dubbo還提供了呼叫失敗的各種容錯機制,如FailoverFailfast、結果集合並等。

 

4)動態的流量排程。在應用執行時,某些服務節點可能因為硬體原因需要減少負載或者某些節點需要人工手動下線;又或者需要實現單元化的呼叫、灰度功能。通過Dubbo Admin管理控制檯,使用者可以在介面上動態地調整每個服務的權重、路由規則、禁用/啟用,實現執行時的流量排程。

 

5)依賴分析和呼叫統計
Dubbo可以介入第三方的APM做分散式鏈路追蹤與效能分析,或者使用已有的獨立監控中心的呼叫次數及耗時,我們可以通過這些資料反推系統容量,在合適的時候通過加機器進行擴容,並且可以預估需要新增多少臺機器。

 

 

 

 

相關文章