dubbo作為目前國內主流的微服務框架之一
一、dubbo的呼叫流程分析
dubbo本身主要支援兩種呼叫流程，包括直連提供者和基於註冊中心的呼叫
直連提供者一般都是在開發和測試環境下使用
我們將所有的配置和實現細節過濾，其實它就只是說明一件事， consumer明確知道provider的家庭住址，稍不順心就直接抄傢伙去provider家去找它麻煩，這其實就是直連提供者。
在我們的分布式環境中，直連提供者會帶來很大的問題 - 動態擴容，設想我們如果每上線乙個新的服務都要讓consumer知道producer的位址，是乙個非常麻煩的事情，實現的不好的就是將這些寫在**裡了。實現的靈活點的會將位址寫在配置檔案裡，但無論哪種形式，都需要重啟所有consumer，是不是很崩潰，所以我們說，這種實現僅僅適用於測試和開發環境。
dubbo基於註冊中心呼叫架構圖：
基於註冊中心呼叫形式對直連提供者的演進或補充
，解釋一下這個流程：【按照圖中標註的0，1，2，3，4，5的順序】
0：container是dubbo提供的容器，用於承載provider，這個我們可以暫時忽略
2：consumer這個私家偵探，會在註冊中心留下眼線【subscribe】
4：當consumer需要時，就會根據本地快取的住址列表，抄傢伙去對應的家庭住址找provider的麻煩
5：dubbo本身是有監控的【monitor】，provider和consumer都會將一些統計資訊進行監控。
刨除0和5我們不管，其實我們可以很容易的發現，無論是直連提供者還是註冊中心的形式，最終consumer都會根據詳細住址找到的provider，只不過是獲取家庭住址的形式變化了。
dubbo的註冊中心最常見的是zookeeper和redis這些常見的分布式中介軟體，同時dubbo也支援自定義擴充套件中心和多註冊中心的配置。詳情可以參見以下內容：
二、dubbo協議剖析
dubbo的協議部分已經被大家總結過很多遍，推薦搭建看一篇部落格：
dubbo框架預設支援的阿里的dubbo協議，同時還支援包括rmi、hessian、http、webservice、thrift、redis在內的多種協議，下面我們來了解一下這些協議的區別與適用場景
dubbo協議特點： 傳入傳出引數資料報較小（建議小於100k），消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大檔案或超大字串，基於以上描述，我們一般建議dubbo用於小資料量大併發的服務呼叫，以及服務消費者機器數遠大於服務提供者機器數的情況。
rmi協議特點： 傳入傳出引數資料報大小混合，消費者與提供者個數差不多，可傳檔案。基於以上描述，我們一般對傳輸管道和效率沒有那麼高的要求，同時又有傳輸檔案這一類的要求時，可以嘗試採用rmi協議。
webservice協議特點： 基於cxf的frontend-******和transports-http實現，適用於系統整合，跨語言呼叫。 不過如非必要，強烈不推薦使用這個方式，webservice是乙個相對比較重的協議傳輸型別，無論從效能、效率和安全性上都不太能滿足微服務的需要，如果確實存在異構系統的呼叫，建議可以採用其他的形式。
其餘的memcached、redis的協議之類的，使用的場景比較少，在這裡就不擴充套件，了解即可
Dubbo 服務呼叫流程
工作流涉及到服務提供者 provider 註冊中心 registration 網路 network 和服務消費者 consumer 服務提供者在啟動的時候，會通過讀取一些配置將服務例項化。proxy 封裝服務呼叫介面，方便呼叫者呼叫。客戶端獲取 proxy 時，可以像呼叫本地服務一樣，呼叫遠端服務。...
dubbo框架呼叫關係簡單理解
前言 因為專案有用的dubbo框架,所以去官方文件了解了一下,對於整體架構有了點淺顯的理解,記錄一下 個人理解 看圖理解 把服務提供者當作乙個馬戲團,把註冊中心當作一塊場地提供者,把消費者當作要看馬戲的遊客.監控中心就當場地攝像頭 1.首先馬戲團向場地提供者報備要表演的專案 2.遊客入場地的時候向場...
簡單理解 Binder 呼叫流程
從大年初一購買電影票說起 客戶端 獲取服務端在 binder 驅動中對應的引用，然後呼叫它的 transact 方法，向服務端傳送訊息 客戶端程序 服務端 該物件被建立後，內部則會啟動乙個隱藏執行緒，不斷的接收從客戶端傳送過來的資料，然後執行 binder 物件中的 ontransact 函式 bi...