Java架構直通車——Dubbo總結

之前對於Dubbo只做了點初步的瞭解，具體參考：Dubbo。主要是關於用法的，沒有怎麼去深究。

今天由於面試的需要，做一份總結吧。

什麼是 Dubbo?

Apache Dubbo是一款高性能、輕量級的開源Java RPC 框架，它提供了三大核心能力： 面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現 。

簡單來說 Dubbo 是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。

Dubbo 的誕生和 SOA 分佈式架構的流行有着莫大的關係。SOA 面向服務的架構（Service Oriented Architecture），也就是把工程按照業務邏輯拆分成 服務層、表現層 兩個工程。服務層中包含業務邏輯，只需要對外提供服務即可。表現層只需要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。
SOA架構中有兩個主要角色：服務提供者（Provider）和服務使用者（Consumer）。

RPC的原理是什麼？

1. 服務消費方（client）調用以本地調用方式調用服務。客戶端存根（client stub）接收到調用後負責將方法、參數等編碼成能在網絡中傳輸的消息體。然後，客戶端存根找到服務地址後，將消息發送給服務端。
2. 服務提供方（server）收到序列化後的消息，就按照解碼該消息。然後，根據解碼結果調用本地服務，執行完畢後，將結果打包發送給消費方。
3. 服務消費方收到執行結果後，也是進行解碼後得到結果。
   

既有 HTTP ,爲啥用 RPC 進行服務調用?

RPC(遠端過程調用)的出現就是爲了解決 服務之間的調用問題，它一般會包含傳輸協議 和 編碼協議 這兩個部分。

• RPC的傳輸協議可以是基於Http的，也可以是基於TCP的，使用不同的傳輸協議一般也是爲了適應不同的場景。
• 編碼協議包含: 如基於文本編碼的 xml json，也有二進制編碼的 protobuf binpack 等。

另外，成熟的 RPC框架還提供好了“服務自動註冊與發現”、“負載均衡”、“可視化的服務治理和運維”、“運行期流量調度”等等功能。

既有 HTTP ,爲什麼要使用自定義 tcp 協議的 rpc 做後端進程通信？

要解決這個問題就應該搞清楚 http 使用的 tcp 協議，和我們自定義的 tcp 協議在報文上的區別。

首先要否認一點 http 協議相較於自定義tcp報文協議，增加的開銷在於連接的建立與斷開。http協議是支持連接池複用的，也就是建立一定數量的連接不斷開，並不會頻繁的創建和銷燬連接。另外，要說的是http也可以使用protobuf這種二進制編碼協議對內容進行編碼，因此二者最大的區別還是在傳輸內容上：

• 傳輸http或者tpc，就像講普通話，好處就是誰都聽得懂，誰都會講。
• 而傳輸自定義的tpc，就像講黑話，好處是可以更精簡、更加保密、更加可定製，壞處就是要求“說”黑話的那一方（client端）也要懂，而且一旦大家都說一種黑話了，換黑話就困難了。

通用定義的http1.1協議的tcp報文包含太多廢信息，，一個POST協議的格式大致如下：
HTTP/1.0 200 OK Content-Type: text/plainContent-Length: 137582Expires: Thu, 05 Dec 1997 16:00:00 GMTLast-Modified: Wed, 5 August 1996 15:55:28 GMTServer: Apache 0.84 Hello World
即使編碼協議也就是body是使用二進制編碼協議，報文元數據也就是header頭的鍵值對卻用了文本編碼，非常佔字節數。如上圖所使用的報文中有效字節數僅僅佔約 30%，也就是70%的時間用於傳輸元數據廢編碼。當然實際情況下報文內容可能會比這個長，但是報頭所佔的比例也是非常可觀的。

爲什麼要用Dubbo?

如果你要開發分佈式程序，你也可以直接基於 HTTP 接口進行通信，但是爲什麼要用 Dubbo呢？

我覺得主要可以從 Dubbo 提供的下面四點特性來說爲什麼要用 Dubbo：

• 負載均衡——同一個服務部署在不同的機器時該調用那一臺機器上的服務。
• 服務調用鏈路生成——隨着系統的發展，服務越來越多，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啓動，架構師都不能完整的描述應用的架構關係。Dubbo 可以爲我們解決服務之間互相是如何調用的。
• 服務訪問壓力以及時長統計、資源調度和治理——基於訪問壓力實時管理集羣容量，提高集羣利用率。
• 服務降級——某個服務掛掉之後調用備用服務。

另外，Dubbo 除了能夠應用在分佈式系統中，也可以應用在現在比較火的微服務系統中。不過，由於 Spring Cloud 在微服務中應用更加廣泛，所以，我覺得一般我們提 Dubbo 的話，大部分是分佈式系統的情況。

Dubbo 的架構

• Provider： 暴露服務的服務提供方
• Consumer： 調用遠程服務的服務消費方
• Registry： 服務註冊與發現的註冊中心
• Monitor： 統計服務的調用次數和調用時間的監控中心
• Container： 服務運行容器

使用Registry好處

Dubbo的註冊中心一般使用zookeeper實現。

1. 註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。
2. 註冊中心，服務提供者，服務消費者三者之間均爲長連接。註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者。
3. 假如註冊中心宕掉，一段時間內服務消費方還是能夠調用提供方的服務的，實際上它使用的本地緩存進行通訊，這只是dubbo健壯性的一種體現。
4. 服務提供者無狀態，任意一臺宕掉後，不影響使用。服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復。

另外，註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者。

Dubbo 提供的負載均衡策略

• Random LoadBalance(默認，基於權重的隨機負載均衡機制)
• RoundRobin LoadBalance(不推薦，基於權重的輪詢負載均衡機制)
  存在慢的提供者累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
• LeastActive LoadBalance
  使慢的提供者收到更少請求，因爲越慢的提供者的調用前後計數差會越大。
• ConsistentHash LoadBalance（一致性Hash）
  相同參數的請求總是發到同一提供者，當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。