Dubbo 框架
模塊註解：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
流程詳解：
0 服務容器負責啓動，加載，運行服務提供者（Standalone 容器）。
1 服務提供者在啓動時，向註冊中心註冊自己提供的服務（Zookeeper/Redis）。
2 服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
3 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
5 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心（根據數據可以動態調整權重）。
Spring Cloud
流程：
請求統一通過 API 網關（Zuul）來訪問內部服務。
網關接收到請求後，從註冊中心（Eureka）獲取可用服務。
由 Ribbon 進行均衡負載後，分發到後端具體實例。
微服務之間通過 Feign 進行通信處理業務。
Hystrix 負責處理服務超時熔斷。
Turbine 監控服務間的調用和熔斷相關指標。
服務調用方式的不同
Dubbo 基於 RPC 通信
Spring Cloud 基於 HTTP 的 REST 方式
這兩種方式各有優劣。雖然從一定程度上來說，後者犧牲了服務調用的性能，但也避免了上面提到的原生 RPC 帶來的問題。而且 REST 相比 RPC 更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。
REST與RPC
REST：表徵狀態轉移（Representational State Transfer），採用Web 服務使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 將所有 Web 系統的服務抽象爲資源，REST從資源的角度來觀察整個網絡，分佈在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表徵。Http協議所抽象的get,post,put,delete就好比數據庫中最基本的增刪改查，而互聯網上的各種資源就好比數據庫中的記錄（可能這麼比喻不是很好），對於各種資源的操作最後總是能抽象成爲這四種基本操作，在定義了定位資源的規則以後，對於資源的操作通過標準的Http協議就可以實現，開發者也會受益於這種輕量級的協議。REST是一種軟件架構風格而非協議也非規範，是一種針對網絡應用的開發方式，可以降低開發的複雜性，提高系統的可伸縮性。
RPC：遠程方法調用，就是像調用本地方法一樣調用遠程方法。
1、服務端如何確定客戶端要調用的函數；
在遠程調用中，客戶端和服務端分別維護一個【ID->函數】的對應表， ID在所有進程中都是唯一確定的。客戶端在做遠程過程調用時，附上這個ID，服務端通過查表，來確定客戶端需要調用的函數，然後執行相應函數的代碼。
2、如何進行序列化和反序列化；
客戶端和服務端交互時將參數或結果轉化爲字節流在網絡中傳輸，那麼數據轉化爲字節流的或者將字節流轉換成能讀取的固定格式時就需要進行序列化和反序列化，序列化和反序列化的速度也會影響遠程調用的效率。
3、如何進行網絡傳輸（選擇何種網絡協議）；
多數RPC框架選擇TCP作爲傳輸協議，也有部分選擇HTTP。如gRPC使用HTTP2。不同的協議各有利弊。TCP更加高效，而HTTP在實際應用中更加的靈活（HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。）。
| 比較項 規範 | REST | RPC |
|---|---|---|
| 通信協議 | HTTP | 一般使用TCP |
| 性能 | 低 | 高 |
| 靈活度 | 高 | 低 |
參考 https://blog.csdn.net/laomo_bible/article/details/79677677