前語

平常咱們在構建分布式體系的時分，一般都是基于 Dubbo 技能?；蛟S是SpringCloud 技能棧來做。前期其實最早比較盛行的是Dubbo，我記得咱們當時有個部分的老邁便是用的是Dubbo 來構建的一個體系，到后面才出來的 SpringCloud，因為它是基于 Spring 生態(tài)建立起來的，供給了一整套微服務組件，功用完全，大受中小型公司開發(fā)者的喜愛。

但是現(xiàn)在仍是有不少公司沒有換成 SpringCloud 來做微服務的東西，仍是基于 Dubbo，面試的時分不管是 SpringCloud 也好，Dubbo 也罷，基本上都會說到這兩個結構的底層原理。你想測驗一下高檔的職位，基本上跑不脫這個問題。

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

服務注冊中心

分布式體系里邊這個是必備的，服務供給者跟服務顧客都在啟動的時分都會注冊到服務注冊中心來。服務注冊中心會記錄。

動態(tài)署理層 Proxy

通常這些結構大多數采用的思維都是經過對你的辦法，接口生成一個署理目標，然后在這個署理目標里邊去寫它的功用。

所以這兒咱們需求每個服務都需求供給接口出來，在發(fā)起服務調用執(zhí)勤，會創(chuàng)立一個動態(tài)署理目標，在咱們的顧客中只有一個接口，咱們可以認為動態(tài)署理類相當于為這個接口動態(tài)的創(chuàng)立一個實體類出來，然后用動態(tài)帶來目標進行接口調用。

Cluster 集群層

咱們準備好了要去調用了長途服務的接口，那么現(xiàn)在問題是咱們的服務供給者會布置多臺機器，那么咱們究竟去調用哪臺機器呢？怎樣挑選？

此刻動態(tài)署理目標回去找一個叫 Cluster 這層的東西，這層就負責具體要調用哪一臺機器。

那么 Cluster 層就必須得拿到有哪些機器對不對，否則怎樣選呢。那么這個進程就叫做動態(tài)感知。

Cluster 里邊有許多組件，比方 Directory、Router 還有LoadBalance ，此刻就會運用負載均衡組件 LoadBlance 挑選一臺機器。到這兒，機器就選好了。

protocol 協(xié)議層

這層首要便是挑選一種協(xié)議來組織咱們的懇求。

Dubbo支持的協(xié)議許多，包含：dubbo、rmi、hessian、http、webservice、thrift、memcached、redis等。默認運用dubbo 協(xié)議。

Exchange 信息交換層

這層最首要的意圖便是把咱們的懇求數據包裝成 Request 或許 Response 。

Transport 網絡通信層

現(xiàn)在咱們挑選好了機器，也把懇求按照協(xié)議進行組織好了，而且封裝好了懇求。那么這個懇求怎樣發(fā)送到服務供給者的哪臺機器呢？

此刻咱們就需求挑選一個網絡通信的結構。由他來負責把你的懇求經過網絡發(fā)送曩昔。比方比較常見的 netty、mina 等。

在發(fā)送曩昔之前，還得對懇求進行序列化。序列化有多種方式可以挑選，比方Json、Protobuf、Protostuff、Hessian、Kryo等、Java序列化等等。

服務顧客接受到懇求后的處理

那么服務供給者怎樣才干收到這個懇求呢？此刻服務供給者里邊也得需求一個網絡通信結構，他去監(jiān)聽你敞開的某個端口，比方就啟動一個 netty 去監(jiān)聽顧客發(fā)送過來的懇求。

接受到懇求過后，然后進行反序列化，然后，前面咱們發(fā)過來的是 經過 Exchange 層包裝的 Request 懇求，那么這兒也需求 這層來對 懇求進行解析。解析的時分，也需求依據一種協(xié)議來進行解析。

實際上 解析完成懇求以后，還會創(chuàng)立一個動態(tài)署理目標，再去調用咱們的服務供給者接口，最后回來數據。

整個調用流程圖

希望你在面試的時分，可以給面試官畫出來這個圖。

參考資料

或許面試的時分還會有更多的細節(jié)，那么依據上面大體的幾層，一層一層的了解各自的細節(jié)。這樣子或許會更有把握一些。