Dubbo的學習筆記

Dubbo筆記

初步認爲Dubbo是一個分佈式調用其餘服務的框架，在沒有使用dubbo框架的時候，咱們調用其餘網站的接口時須要使用http發送一個請求到指定的服務接口上。而dubbo的主要功能就是將其餘網站的服務透明化，便可以像調用一個本地方法同樣調用遠程服務。

---

經過資料得知Dubbo是基於RPC框架,RPC框架帶來的幾個問題，關於RPC的具體內容能夠參考這篇https://www.jianshu.com/p/b0343bfd216e

1. Call ID映射

• 咱們須要調用一個方法，在本地環境中方法能夠經過指針來指定，而在遠程方法調用時，兩臺機器的進程尋址地址是不一樣的。因此在RPC框架中，每一個方法都有一個ID，這個ID在進程中都是惟一肯定的。客戶端在調用遠程方法時須要帶上ID。而後咱們還須要在客戶端和服務端分別維護一個 {函數 <--> Call ID} 的對應表。二者的表不必定須要徹底相同，但相同的方法對應的Call ID必須相同。當客戶端須要進行遠程調用時，它就查一下這個表，找出相應的Call ID，而後把它傳給服務端，服務端也經過查表，來肯定客戶端須要調用的方法，而後執行相應方法的代碼

2. 序列化和反序列化

• 客戶端怎麼把參數值傳給遠程的方法呢？在本地調用中，咱們只須要把參數壓到棧裏，而後讓函數本身去棧裏讀就行。可是在遠程過程調用時，客戶端跟服務端是不一樣的進程，不能經過內存來傳遞參數。甚至有時候客戶端和服務端使用的都不是同一種語言（好比服務端用C++，客戶端用Java或者Python）。這時候就須要客戶端把參數先轉成一個字節流，傳給服務端後，再把字節流轉成本身能讀取的格式。這個過程叫序列化和反序列化。同理，從服務端返回的值也須要序列化反序列化的過程。

3. 網絡傳輸

• 遠程調用每每用在網絡上，客戶端和服務端是經過網絡鏈接的。全部的數據都須要經過網絡傳輸，所以就須要有一個網絡傳輸層。網絡傳輸層須要把Call ID和序列化後的參數字節流傳給服務端，而後再把序列化後的調用結果傳回客戶端。只要能完成這二者的，均可以做爲傳輸層使用。所以，它所使用的協議實際上是不限的，能完成傳輸就行。

---

Dubbo的流程圖

經過這張流程圖能夠清晰看到dubbo是消費者和提供者的關係，程序運行時服務提供者將服務在註冊中心註冊，消費者在註冊中心訂閱服務。這樣消費者就能夠看到有哪些服務是能夠調用的，最後有一個監控模塊來監控服務的數量。

以上即是我的對dubbo的理解，若有錯誤，請指出！