前言

平常我們在構建分布式系統的時候，一般都是基于 Dubbo 技術棧或者是SpringCloud 技術棧來做。早期其實最先比較流行的是Dubbo，我記得我們當時有個部分的老大就是用的是Dubbo 來構建的一個系統，到后面才出來的 SpringCloud，由于它是基于 Spring 生態建立起來的，提供了一整套微服務組件，功能齊全，大受中小型公司開發者的青睞。

但是現在還是有不少公司沒有換成 SpringCloud 來做微服務的東西，還是基于 Dubbo，面試的時候不管是 SpringCloud 也好，Dubbo 也罷，基本上都會提到這兩個框架的底層原理。你想嘗試一下高級的職位，基本上跑不脫這個問題。

OK，今兒我們就大概聊聊 Dubbo 的底層架構原理吧。

服務注冊中心

分布式系統里面這個是必備的，服務提供者跟服務消費者都在啟動的時候都會注冊到服務注冊中心來。服務注冊中心會記錄。

動態代理層 Proxy

通常這些框架大多數采用的思想都是通過對你的方法，接口生成一個代理對象，然后在這個代理對象里面去寫它的功能。

所以這里我們需要每個服務都需要提供接口出來，在發起服務調用執勤，會創建一個動態代理對象，在我們的消費者中只有一個接口，我們可以認為動態代理類相當于為這個接口動態的創建一個實體類出來，然后用動態帶來對象進行接口調用。

Cluster 集群層

我們準備好了要去調用了遠程服務的接口，那么現在問題是我們的服務提供者會部署多臺機器，那么我們到底去調用哪臺機器呢？怎么選擇？

此時動態代理對象回去找一個叫 Cluster 這層的東西，這層就負責具體要調用哪一臺機器。

那么 Cluster 層就必須得拿到有哪些機器對不對，不然怎么選呢。那么這個過程就叫做動態感知。

Cluster 里面有很多組件，比如 Directory、Router 還有LoadBalance ，此時就會使用負載均衡組件 LoadBlance 挑選一臺機器。到這里，機器就選好了。

protocol 協議層

這層主要就是選擇一種協議來組織我們的請求。

Dubbo支持的協議很多，包括：dubbo、rmi、hessian、http、webservice、thrift、memcached、redis等。默認使用dubbo 協議。

Exchange 信息交換層

這層最主要的目的就是把我們的請求數據包裝成 Request 或者 Response 。

Transport 網絡通信層

現在我們挑選好了機器，也把請求按照協議進行組織好了，并且封裝好了請求。那么這個請求怎么發送到服務提供者的哪臺機器呢？

此時我們就需要選擇一個網絡通信的框架。由他來負責把你的請求通過網絡發送過去。比如比較常見的 netty、mina 等。

在發送過去之前，還得對請求進行序列化。序列化有多種方式可以選擇，比如Json、Protobuf、Protostuff、Hessian、Kryo等、Java序列化等等。

服務消費者接受到請求后的處理

那么服務提供者怎么才能收到這個請求呢？此時服務提供者里面也得需要一個網絡通信框架，他去監聽你開放的某個端口，比如就啟動一個 netty 去監聽消費者發送過來的請求。

接受到請求過后，然后進行反序列化，然后，前面我們發過來的是 通過 Exchange 層包裝的 Request 請求，那么這里也需要 這層來對 請求進行解析。解析的時候，也需要根據一種協議來進行解析。

實際上 解析完成請求以后，還會創建一個動態代理對象，再去調用我們的服務提供者接口，最后返回數據。

整個調用流程圖

希望你在面試的時候，能夠給面試官畫出來這個圖。

參考資料

可能面試的時候還會有更多的細節，那么根據上面大體的幾層，一層一層的了解各自的細節。這樣子可能會更有把握一些。

dubbo 中文文檔：http://dubbo.apache.org/zh-cn/docs/user/quick-start.html

Dubbo 實現原理及架構詳解：http://crazyfzw.github.io/2018/06/10/dubbo-architecture/^[1]。

把上面的圖了解了，再去看官方的，我認為會更好一些。

關注我的頭條號并在后臺私信我：555，即可(獲取Java高級架構資料)。

不知道怎么私信的朋友可以關注公眾號：Java耕耘者。(點擊小助理獲取)

總結

以上是生活随笔為你收集整理的cgblib 代理接口原理_Java开发者你还不知道？告诉你Dubbo 的底层原理，面试不再怕...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。