• 用於遠端服務呼叫的分散式框架
• 高效能和透明化的RPC遠端服務呼叫方案（RPC VS http）
• SOA服務治理方案（SOA VS 微服務）

1. 傳入傳出引數資料包較小
2. 消費者比提供者多
3. 常規遠端服務方法呼叫
4. 不適合傳送大資料量的服務，比如檔案、視訊

管理介面：

（1）各部分的名字和作用： Provider：服務提供方（暴露服務） Consumer：服務消費方（呼叫遠端服務） Registry：註冊中心（服務註冊和發現） Monitor：監控中心（統計服務的呼叫次數和呼叫時間） Container：服務執行容器

（2）呼叫流程如下： 0.服務執行容器啟動、載入、執行服務提供方。 1.服務提供方在啟動時，向註冊中心註冊自己提供的服務。 2.服務消費方在啟動時，向註冊中心訂閱自己所需的服務。 3.註冊中心返回服務提供方地址列表給消費方，而且是“終身服務”，一但有變更，註冊中心會立即將變更資料推送給消費方。 4.服務消費方從地址列表中選一臺提供方進行呼叫，如果呼叫失敗，再選另一臺。這個過程基於軟負載均衡演算法。 5.服務提供方和消費方在記憶體中累計呼叫次數和時間，每分鐘向監控中心傳送一次統計資料。

• 能實現的功能方面
  可以看出，dubbo只實現了服務治理，不過如果想實現如上“無”的要素，可以通過擴充套件Filter來完善；Spring Cloud覆蓋的面更廣一些。
• 記憶體損耗方面 dubbo是二進位制傳輸的，所以其佔用頻寬較少； springcloud是http協議傳輸的，而且使用了json報文，所以損耗較大。 總體來說，如果使用dubbo，需要自己“組裝”。如果使用Spring Cloud，直接拿來用就好。但是如果想用Spring Could整體外的東西，再加入進去就相對費事一點。