分佈式系統面試系列02-Dubbo 的底層原理，前面我們講了 SpringCloud 核心組件的底層原理，同樣的，作為微服務裡面的另外一大派系Dubbo ，使用的也是蠻多的，很多時候面試也會考到。
前言
平常我們在構建分佈式系統的時候，一般都是基於 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/。
把上面的圖瞭解了，再去看官方的，我認為會更好一些。
閱讀更多 科技伍小黑 的文章
