Dubbo 面試題，淦?。。?/h1>
大家好，今天是分享 Dubbo 知識點/面試題總結(jié)的 Guide！
這篇文章是我根據(jù)官方文檔以及自己平時的使用情況，對 Dubbo 所做的一個總結(jié)。
文章內(nèi)容有一點長，一次看不完的話，記得收藏起來，找時間再看！
原創(chuàng)不易，若有幫助，點贊/分享就是對我最大的鼓勵！
個人能力有限。如果文章有任何需要補(bǔ)充/完善/修改的地方，歡迎在評論區(qū)指出，共同進(jìn)步！
RPC 基礎(chǔ)
何為 RPC?
RPC（Remote Procedure Call） 即遠(yuǎn)程過程調(diào)用，通過名字我們就能看出 RPC 關(guān)注的是遠(yuǎn)程調(diào)用而非本地調(diào)用。
為什么要 RPC ？ 因為，兩個不同的服務(wù)器上的服務(wù)提供的方法不在一個內(nèi)存空間，所以，需要通過網(wǎng)絡(luò)編程才能傳遞方法調(diào)用所需要的參數(shù)。并且，方法調(diào)用的結(jié)果也需要通過網(wǎng)絡(luò)編程來接收。但是，如果我們自己手動網(wǎng)絡(luò)編程來實現(xiàn)這個調(diào)用過程的話工作量是非常大的，因為，我們需要考慮底層傳輸方式（TCP 還是 UDP）、序列化方式等等方面。
RPC 能幫助我們做什么呢？ 簡單來說，通過 RPC 可以幫助我們調(diào)用遠(yuǎn)程計算機(jī)上某個服務(wù)的方法，這個過程就像調(diào)用本地方法一樣簡單。并且！我們不需要了解底層網(wǎng)絡(luò)編程的具體細(xì)節(jié)。
舉個例子：兩個不同的服務(wù) A、B 部署在兩臺不同的機(jī)器上，服務(wù) A 如果想要調(diào)用服務(wù) B 中的某個方法的話就可以通過 RPC 來做。
一言蔽之：RPC 的出現(xiàn)就是為了讓你調(diào)用遠(yuǎn)程方法像調(diào)用本地方法一樣簡單。
RPC 的原理是什么?
為了能夠幫助小伙伴們理解 RPC 原理，我們可以將整個 RPC 的 核心功能看作是下面 ?? 6 個部分實現(xiàn)的：
客戶端（服務(wù)消費端） ：調(diào)用遠(yuǎn)程方法的一端。 客戶端 Stub（樁） ：這其實就是一代理類。代理類主要做的事情很簡單，就是把你調(diào)用方法、類、方法參數(shù)等信息傳遞到服務(wù)端。 網(wǎng)絡(luò)傳輸 ：網(wǎng)絡(luò)傳輸就是你要把你調(diào)用的方法的信息比如說參數(shù)啊這些東西傳輸?shù)椒?wù)端，然后服務(wù)端執(zhí)行完之后再把返回結(jié)果通過網(wǎng)絡(luò)傳輸給你傳輸回來。網(wǎng)絡(luò)傳輸?shù)膶崿F(xiàn)方式有很多種比如最近基本的 Socket 或者性能以及封裝更加優(yōu)秀的 Netty（推薦）。 服務(wù)端 Stub（樁） ：這個樁就不是代理類了。我覺得理解為樁實際不太好，大家注意一下就好。這里的服務(wù)端 Stub 實際指的就是接收到客戶端執(zhí)行方法的請求后，去指定對應(yīng)的方法然后返回結(jié)果給客戶端的類。 服務(wù)端（服務(wù)提供端） ：提供遠(yuǎn)程方法的一端。
具體原理圖如下，后面我會串起來將整個 RPC 的過程給大家說一下。
RPC原理圖 服務(wù)消費端（client）以本地調(diào)用的方式調(diào)用遠(yuǎn)程服務(wù)； 客戶端 Stub（client stub） 接收到調(diào)用后負(fù)責(zé)將方法、參數(shù)等組裝成能夠進(jìn)行網(wǎng)絡(luò)傳輸?shù)南Ⅲw（序列化）：RpcRequest； 客戶端 Stub（client stub） 找到遠(yuǎn)程服務(wù)的地址，并將消息發(fā)送到服務(wù)提供端； 服務(wù)端 Stub（樁）收到消息將消息反序列化為 Java 對象: RpcRequest； 服務(wù)端 Stub（樁）根據(jù)RpcRequest中的類、方法、方法參數(shù)等信息調(diào)用本地的方法； 服務(wù)端 Stub（樁）得到方法執(zhí)行結(jié)果并將組裝成能夠進(jìn)行網(wǎng)絡(luò)傳輸?shù)南Ⅲw：RpcResponse（序列化）發(fā)送至消費方； 客戶端 Stub（client stub）接收到消息并將消息反序列化為 Java 對象:RpcResponse ，這樣也就得到了最終結(jié)果。over!
相信小伙伴們看完上面的講解之后，已經(jīng)了解了 RPC 的原理。
雖然篇幅不多，但是基本把 RPC 框架的核心原理講清楚了！另外，對于上面的技術(shù)細(xì)節(jié)，我會在后面的章節(jié)介紹到。
最后，對于 RPC 的原理，希望小伙伴不單單要理解，還要能夠自己畫出來并且能夠給別人講出來。因為，在面試中這個問題在面試官問到 RPC 相關(guān)內(nèi)容的時候基本都會碰到。
Dubbo 基礎(chǔ)
什么是 Dubbo?
Apache Dubbo (incubating) |?d?b??| 是一款高性能、輕量級的開源 Java RPC 框架。
根據(jù) Dubbo 官方文檔的介紹，Dubbo 提供了六大核心能力
面向接口代理的高性能 RPC 調(diào)用。 智能容錯和負(fù)載均衡。 服務(wù)自動注冊和發(fā)現(xiàn)。 高度可擴(kuò)展能力。 運(yùn)行期流量調(diào)度。 可視化的服務(wù)治理與運(yùn)維。
Dubbo提供的六大核心能力 簡單來說就是：Dubbo 不光可以幫助我們調(diào)用遠(yuǎn)程服務(wù)，還提供了一些其他開箱即用的功能比如智能負(fù)載均衡。
Dubbo 目前已經(jīng)有接近 34.4 k 的 Star 。
在 2020 年度 OSC 中國開源項目 評選活動中，Dubbo 位列開發(fā)框架和基礎(chǔ)組件類項目的第 7 名。想比幾年前來說，熱度和排名有所下降。
Dubbo 是由阿里開源，后來加入了 Apache 。正式由于 Dubbo 的出現(xiàn)，才使得越來越多的公司開始使用以及接受分布式架構(gòu)。
為什么要用 Dubbo?
隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)站的規(guī)模越來越大，用戶數(shù)量越來越多。單一應(yīng)用架構(gòu) 、垂直應(yīng)用架構(gòu)無法滿足我們的需求，這個時候分布式服務(wù)架構(gòu)就誕生了。
分布式服務(wù)架構(gòu)下，系統(tǒng)被拆分成不同的服務(wù)比如短信服務(wù)、安全服務(wù)，每個服務(wù)獨立提供系統(tǒng)的某個核心服務(wù)。
我們可以使用 Java RMI（Java Remote Method Invocation）、Hessian 這種支持遠(yuǎn)程調(diào)用的框架來簡單地暴露和引用遠(yuǎn)程服務(wù)。但是！當(dāng)服務(wù)越來越多之后，服務(wù)調(diào)用關(guān)系越來越復(fù)雜。當(dāng)應(yīng)用訪問壓力越來越大后，負(fù)載均衡以及服務(wù)監(jiān)控的需求也迫在眉睫。我們可以用 F5 這類硬件來做負(fù)載均衡，但這樣增加了成本，并且存在單點故障的風(fēng)險。
不過，Dubbo 的出現(xiàn)讓上述問題得到了解決。Dubbo 幫助我們解決了什么問題呢？
負(fù)載均衡 ：同一個服務(wù)部署在不同的機(jī)器時該調(diào)用那一臺機(jī)器上的服務(wù)。 服務(wù)調(diào)用鏈路生成 ：隨著系統(tǒng)的發(fā)展，服務(wù)越來越多，服務(wù)間依賴關(guān)系變得錯蹤復(fù)雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。Dubbo 可以為我們解決服務(wù)之間互相是如何調(diào)用的。 服務(wù)訪問壓力以及時長統(tǒng)計、資源調(diào)度和治理 ：基于訪問壓力實時管理集群容量，提高集群利用率。 ......
另外，Dubbo 除了能夠應(yīng)用在分布式系統(tǒng)中，也可以應(yīng)用在現(xiàn)在比較火的微服務(wù)系統(tǒng)中。不過，由于 Spring Cloud 在微服務(wù)中應(yīng)用更加廣泛，所以，我覺得一般我們提 Dubbo 的話，大部分是分布式系統(tǒng)的情況。
我們剛剛提到了分布式這個概念，下面再給大家介紹一下什么是分布式？為什么要分布式？
分布式基礎(chǔ)
什么是分布式?
分布式或者說 SOA 分布式重要的就是面向服務(wù)，說簡單的分布式就是我們把整個系統(tǒng)拆分成不同的服務(wù)然后將這些服務(wù)放在不同的服務(wù)器上減輕單體服務(wù)的壓力提高并發(fā)量和性能。比如電商系統(tǒng)可以簡單地拆分成訂單系統(tǒng)、商品系統(tǒng)、登錄系統(tǒng)等等，拆分之后的每個服務(wù)可以部署在不同的機(jī)器上，如果某一個服務(wù)的訪問量比較大的話也可以將這個服務(wù)同時部署在多臺機(jī)器上。
分布式事務(wù)示意圖 為什么要分布式?
從開發(fā)角度來講單體應(yīng)用的代碼都集中在一起，而分布式系統(tǒng)的代碼根據(jù)業(yè)務(wù)被拆分。所以，每個團(tuán)隊可以負(fù)責(zé)一個服務(wù)的開發(fā)，這樣提升了開發(fā)效率。另外，代碼根據(jù)業(yè)務(wù)拆分之后更加便于維護(hù)和擴(kuò)展。
另外，我覺得將系統(tǒng)拆分成分布式之后不光便于系統(tǒng)擴(kuò)展和維護(hù)，更能提高整個系統(tǒng)的性能。你想一想嘛？把整個系統(tǒng)拆分成不同的服務(wù)/系統(tǒng)，然后每個服務(wù)/系統(tǒng) 單獨部署在一臺服務(wù)器上，是不是很大程度上提高了系統(tǒng)性能呢？
Dubbo 架構(gòu)
Dubbo 架構(gòu)中的核心角色有哪些？
官方文檔中的框架設(shè)計章節(jié) 已經(jīng)介紹的非常詳細(xì)了，我這里把一些比較重要的點再提一下。
dubbo-relation 上述節(jié)點簡單介紹以及他們之間的關(guān)系：
Container： 服務(wù)運(yùn)行容器，負(fù)責(zé)加載、運(yùn)行服務(wù)提供者。必須。 Provider： 暴露服務(wù)的服務(wù)提供方，會向注冊中心注冊自己提供的服務(wù)。必須。 Consumer： 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方，會向注冊中心訂閱自己所需的服務(wù)。必須。 Registry： 服務(wù)注冊與發(fā)現(xiàn)的注冊中心。注冊中心會返回服務(wù)提供者地址列表給消費者。非必須。 Monitor： 統(tǒng)計服務(wù)的調(diào)用次數(shù)和調(diào)用時間的監(jiān)控中心。服務(wù)消費者和提供者會定時發(fā)送統(tǒng)計數(shù)據(jù)到監(jiān)控中心。非必須。
Dubbo 中的 Invoker 概念了解么？
Invoker 是 Dubbo 領(lǐng)域模型中非常重要的一個概念，你如果閱讀過 Dubbo 源碼的話，你會無數(shù)次看到這玩意。就比如下面我要說的負(fù)載均衡這塊的源碼中就有大量 Invoker 的身影。
簡單來說，Invoker 就是 Dubbo 對遠(yuǎn)程調(diào)用的抽象。
dubbo_rpc_invoke.jpg 按照 Dubbo 官方的話來說，Invoker 分為
服務(wù)提供 Invoker 服務(wù)消費 Invoker
假如我們需要調(diào)用一個遠(yuǎn)程方法，我們需要動態(tài)代理來屏蔽遠(yuǎn)程調(diào)用的細(xì)節(jié)吧！我們屏蔽掉的這些細(xì)節(jié)就依賴對應(yīng)的 Invoker 實現(xiàn)， Invoker 實現(xiàn)了真正的遠(yuǎn)程服務(wù)調(diào)用。
Dubbo 的工作原理了解么？
下圖是 Dubbo 的整體設(shè)計，從下至上分為十層，各層均為單向依賴。
左邊淡藍(lán)背景的為服務(wù)消費方使用的接口，右邊淡綠色背景的為服務(wù)提供方使用的接口，位于中軸線上的為雙方都用到的接口。
dubbo-framework config 配置層：Dubbo 相關(guān)的配置。支持代碼配置，同時也支持基于 Spring 來做配置，以 ServiceConfig, ReferenceConfig 為中心 proxy 服務(wù)代理層：調(diào)用遠(yuǎn)程方法像調(diào)用本地的方法一樣簡單的一個關(guān)鍵，真實調(diào)用過程依賴代理類，以 ServiceProxy 為中心。 registry 注冊中心層：封裝服務(wù)地址的注冊與發(fā)現(xiàn)。 cluster 路由層：封裝多個提供者的路由及負(fù)載均衡，并橋接注冊中心，以 Invoker 為中心。 monitor 監(jiān)控層：RPC 調(diào)用次數(shù)和調(diào)用時間監(jiān)控，以 Statistics 為中心。 protocol 遠(yuǎn)程調(diào)用層：封裝 RPC 調(diào)用，以 Invocation, Result 為中心。 exchange 信息交換層：封裝請求響應(yīng)模式，同步轉(zhuǎn)異步，以 Request, Response 為中心。 transport 網(wǎng)絡(luò)傳輸層：抽象 mina 和 netty 為統(tǒng)一接口，以 Message 為中心。 serialize 數(shù)據(jù)序列化層 ：對需要在網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)進(jìn)行序列化。
Dubbo 的 SPI 機(jī)制了解么？如何擴(kuò)展 Dubbo 中的默認(rèn)實現(xiàn)？
SPI（Service Provider Interface） 機(jī)制被大量用在開源項目中，它可以幫助我們動態(tài)尋找服務(wù)/功能（比如負(fù)載均衡策略）的實現(xiàn)。
SPI 的具體原理是這樣的：我們將接口的實現(xiàn)類放在配置文件中，我們在程序運(yùn)行過程中讀取配置文件，通過反射加載實現(xiàn)類。這樣，我們可以在運(yùn)行的時候，動態(tài)替換接口的實現(xiàn)類。和 IoC 的解耦思想是類似的。
Java 本身就提供了 SPI 機(jī)制的實現(xiàn)。不過，Dubbo 沒有直接用，而是對 Java 原生的 SPI 機(jī)制進(jìn)行了增強(qiáng)，以便更好滿足自己的需求。
那我們?nèi)绾螖U(kuò)展 Dubbo 中的默認(rèn)實現(xiàn)呢？
比如說我們想要實現(xiàn)自己的負(fù)載均衡策略，我們創(chuàng)建對應(yīng)的實現(xiàn)類 XxxLoadBalance 實現(xiàn) LoadBalance 接口或者 AbstractLoadBalance 類。
package com.xxx;
import org.apache.dubbo.rpc.cluster.LoadBalance;
import org.apache.dubbo.rpc.Invoker;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.RpcException;
public class XxxLoadBalance implements LoadBalance {
public <T> Invoker<T> select(List<Invoker<T>> invokers, Invocation invocation) throws RpcException {
// ...
}
}
我們將這個是實現(xiàn)類的路徑寫入到resources 目錄下的 META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance文件中即可。
src
|-main
|-java
|-com
|-xxx
|-XxxLoadBalance.java (實現(xiàn)LoadBalance接口)
|-resources
|-META-INF
|-dubbo
|-org.apache.dubbo.rpc.cluster.LoadBalance (純文本文件，內(nèi)容為：xxx=com.xxx.XxxLoadBalance)
org.apache.dubbo.rpc.cluster.LoadBalance
xxx=com.xxx.XxxLoadBalance
其他還有很多可供擴(kuò)展的選擇，你可以在官方文檔@SPI 擴(kuò)展實現(xiàn)這里找到。
Dubbo 的微內(nèi)核架構(gòu)了解嗎？
Dubbo 采用 微內(nèi)核（Microkernel） + 插件（Plugin） 模式，簡單來說就是微內(nèi)核架構(gòu)。微內(nèi)核只負(fù)責(zé)組裝插件。
何為微內(nèi)核架構(gòu)呢？ 《軟件架構(gòu)模式》 這本書是這樣介紹的：
微內(nèi)核架構(gòu)模式（有時被稱為插件架構(gòu)模式）是實現(xiàn)基于產(chǎn)品應(yīng)用程序的一種自然模式?；诋a(chǎn)品的應(yīng)用程序是已經(jīng)打包好并且擁有不同版本，可作為第三方插件下載的。然后，很多公司也在開發(fā)、發(fā)布自己內(nèi)部商業(yè)應(yīng)用像有版本號、說明及可加載插件式的應(yīng)用軟件（這也是這種模式的特征）。微內(nèi)核系統(tǒng)可讓用戶添加額外的應(yīng)用如插件，到核心應(yīng)用，繼而提供了可擴(kuò)展性和功能分離的用法。
微內(nèi)核架構(gòu)包含兩類組件：核心系統(tǒng)（core system） 和 插件模塊（plug-in modules）。
核心系統(tǒng)提供系統(tǒng)所需核心能力，插件模塊可以擴(kuò)展系統(tǒng)的功能。因此， 基于微內(nèi)核架構(gòu)的系統(tǒng)，非常易于擴(kuò)展功能。
我們常見的一些 IDE，都可以看作是基于微內(nèi)核架構(gòu)設(shè)計的。絕大多數(shù) IDE 比如 IDEA、VSCode 都提供了插件來豐富自己的功能。
正是因為 Dubbo 基于微內(nèi)核架構(gòu)，才使得我們可以隨心所欲替換 Dubbo 的功能點。比如你覺得 Dubbo 的序列化模塊實現(xiàn)的不滿足自己要求，沒關(guān)系??！你自己實現(xiàn)一個序列化模塊就好了??！
通常情況下，微核心都會采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依賴 Spring 等 IoC 容器，也不想自已造一個小的 IoC 容器（過度設(shè)計），因此采用了一種最簡單的 Factory 方式管理插件 ：JDK 標(biāo)準(zhǔn)的 SPI 擴(kuò)展機(jī)制 （java.util.ServiceLoader）。
關(guān)于 Dubbo 架構(gòu)的一些自測小問題
注冊中心的作用了解么？
注冊中心負(fù)責(zé)服務(wù)地址的注冊與查找，相當(dāng)于目錄服務(wù)，服務(wù)提供者和消費者只在啟動時與注冊中心交互。
服務(wù)提供者宕機(jī)后，注冊中心會做什么？
注冊中心會立即推送事件通知消費者。
監(jiān)控中心的作用呢？
監(jiān)控中心負(fù)責(zé)統(tǒng)計各服務(wù)調(diào)用次數(shù)，調(diào)用時間等。
注冊中心和監(jiān)控中心都宕機(jī)的話，服務(wù)都會掛掉嗎？
不會。兩者都宕機(jī)也不影響已運(yùn)行的提供者和消費者，消費者在本地緩存了提供者列表。注冊中心和監(jiān)控中心都是可選的，服務(wù)消費者可以直連服務(wù)提供者。
Dubbo 的負(fù)載均衡策略
什么是負(fù)載均衡？
先來看一下稍微官方點的解釋。下面這段話摘自維基百科對負(fù)載均衡的定義：
負(fù)載均衡改善了跨多個計算資源（例如計算機(jī)，計算機(jī)集群，網(wǎng)絡(luò)鏈接，中央處理單元或磁盤驅(qū)動）的工作負(fù)載分布。負(fù)載平衡旨在優(yōu)化資源使用，最大化吞吐量，最小化響應(yīng)時間，并避免任何單個資源的過載。使用具有負(fù)載平衡而不是單個組件的多個組件可以通過冗余提高可靠性和可用性。負(fù)載平衡通常涉及專用軟件或硬件。
上面講的大家可能不太好理解，再用通俗的話給大家說一下。
我們的系統(tǒng)中的某個服務(wù)的訪問量特別大，我們將這個服務(wù)部署在了多臺服務(wù)器上，當(dāng)客戶端發(fā)起請求的時候，多臺服務(wù)器都可以處理這個請求。那么，如何正確選擇處理該請求的服務(wù)器就很關(guān)鍵。假如，你就要一臺服務(wù)器來處理該服務(wù)的請求，那該服務(wù)部署在多臺服務(wù)器的意義就不復(fù)存在了。負(fù)載均衡就是為了避免單個服務(wù)器響應(yīng)同一請求，容易造成服務(wù)器宕機(jī)、崩潰等問題，我們從負(fù)載均衡的這四個字就能明顯感受到它的意義。
Dubbo 提供的負(fù)載均衡策略有哪些？
在集群負(fù)載均衡時，Dubbo 提供了多種均衡策略，默認(rèn)為 random 隨機(jī)調(diào)用。我們還可以自行擴(kuò)展負(fù)載均衡策略（參考 Dubbo SPI 機(jī)制）。
在 Dubbo 中，所有負(fù)載均衡實現(xiàn)類均繼承自 AbstractLoadBalance，該類實現(xiàn)了 LoadBalance 接口，并封裝了一些公共的邏輯。
public abstract class AbstractLoadBalance implements LoadBalance {
static int calculateWarmupWeight(int uptime, int warmup, int weight) {
}
@Override
public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
}
protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);
int getWeight(Invoker<?> invoker, Invocation invocation) {
}
}
AbstractLoadBalance 的實現(xiàn)類有下面這些：
官方文檔對負(fù)載均衡這部分的介紹非常詳細(xì)，推薦小伙伴們看看，地址：https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#m-zhdocsv27devsourceloadbalance 。
RandomLoadBalance
根據(jù)權(quán)重隨機(jī)選擇（對加權(quán)隨機(jī)算法的實現(xiàn)）。這是 Dubbo 默認(rèn)采用的一種負(fù)載均衡策略。
RandomLoadBalance 具體的實現(xiàn)原理非常簡單，假如有兩個提供相同服務(wù)的服務(wù)器 S1,S2，S1 的權(quán)重為 7，S2 的權(quán)重為 3。
我們把這些權(quán)重值分布在坐標(biāo)區(qū)間會得到：S1->[0, 7) ，S2->(7, 10]。我們生成[0, 10) 之間的隨機(jī)數(shù)，隨機(jī)數(shù)落到對應(yīng)的區(qū)間，我們就選擇對應(yīng)的服務(wù)器來處理請求。
RandomLoadBalance RandomLoadBalance 的源碼非常簡單，簡單花幾分鐘時間看一下。
以下源碼來自 Dubbo master 分支上的最新的版本 2.7.9。
public class RandomLoadBalance extends AbstractLoadBalance {
public static final String NAME = "random";
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
int length = invokers.size();
boolean sameWeight = true;
int[] weights = new int[length];
int totalWeight = 0;
// 下面這個for循環(huán)的主要作用就是計算所有該服務(wù)的提供者的權(quán)重之和 totalWeight（），
// 除此之外，還會檢測每個服務(wù)提供者的權(quán)重是否相同
for (int i = 0; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
totalWeight += weight;
weights[i] = totalWeight;
if (sameWeight && totalWeight != weight * (i + 1)) {
sameWeight = false;
}
}
if (totalWeight > 0 && !sameWeight) {
// 隨機(jī)生成一個 [0, totalWeight) 區(qū)間內(nèi)的數(shù)字
int offset = ThreadLocalRandom.current().nextInt(totalWeight);
// 判斷會落在哪個服務(wù)提供者的區(qū)間
for (int i = 0; i < length; i++) {
if (offset < weights[i]) {
return invokers.get(i);
}
}
return invokers.get(ThreadLocalRandom.current().nextInt(length));
}
}
LeastActiveLoadBalance
LeastActiveLoadBalance 直譯過來就是最小活躍數(shù)負(fù)載均衡。
這個名字起得有點不直觀，不仔細(xì)看官方對活躍數(shù)的定義，你壓根不知道這玩意是干嘛的。
我這么說吧！初始狀態(tài)下所有服務(wù)提供者的活躍數(shù)均為 0（每個服務(wù)提供者的中特定方法都對應(yīng)一個活躍數(shù)，我在后面的源碼中會提到），每收到一個請求后，對應(yīng)的服務(wù)提供者的活躍數(shù) +1，當(dāng)這個請求處理完之后，活躍數(shù) -1。
因此，Dubbo 就認(rèn)為誰的活躍數(shù)越少，誰的處理速度就越快，性能也越好，這樣的話，我就優(yōu)先把請求給活躍數(shù)少的服務(wù)提供者處理。
如果有多個服務(wù)提供者的活躍數(shù)相等怎么辦？
很簡單，那就再走一遍 RandomLoadBalance 。
public class LeastActiveLoadBalance extends AbstractLoadBalance {
public static final String NAME = "leastactive";
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
int length = invokers.size();
int leastActive = -1;
int leastCount = 0;
int[] leastIndexes = new int[length];
int[] weights = new int[length];
int totalWeight = 0;
int firstWeight = 0;
boolean sameWeight = true;
// 這個 for 循環(huán)的主要作用是遍歷 invokers 列表，找出活躍數(shù)最小的 Invoker
// 如果有多個 Invoker 具有相同的最小活躍數(shù)，還會記錄下這些 Invoker 在 invokers 集合中的下標(biāo)，并累加它們的權(quán)重，比較它們的權(quán)重值是否相等
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
// 獲取 invoker 對應(yīng)的活躍(active)數(shù)
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
int afterWarmup = getWeight(invoker, invocation);
weights[i] = afterWarmup;
if (leastActive == -1 || active < leastActive) {
leastActive = active;
leastCount = 1;
leastIndexes[0] = i;
totalWeight = afterWarmup;
firstWeight = afterWarmup;
sameWeight = true;
} else if (active == leastActive) {
leastIndexes[leastCount++] = i;
totalWeight += afterWarmup;
if (sameWeight && afterWarmup != firstWeight) {
sameWeight = false;
}
}
}
// 如果只有一個 Invoker 具有最小的活躍數(shù)，此時直接返回該 Invoker 即可
if (leastCount == 1) {
return invokers.get(leastIndexes[0]);
}
// 如果有多個 Invoker 具有相同的最小活躍數(shù)，但它們之間的權(quán)重不同
// 這里的處理方式就和 RandomLoadBalance 一致了
if (!sameWeight && totalWeight > 0) {
int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
for (int i = 0; i < leastCount; i++) {
int leastIndex = leastIndexes[i];
offsetWeight -= weights[leastIndex];
if (offsetWeight < 0) {
return invokers.get(leastIndex);
}
}
}
return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
}
}
活躍數(shù)是通過 RpcStatus 中的一個 ConcurrentMap 保存的，根據(jù) URL 以及服務(wù)提供者被調(diào)用的方法的名稱，我們便可以獲取到對應(yīng)的活躍數(shù)。也就是說服務(wù)提供者中的每一個方法的活躍數(shù)都是互相獨立的。
public class RpcStatus {
private static final ConcurrentMap<String, ConcurrentMap<String, RpcStatus>> METHOD_STATISTICS =
new ConcurrentHashMap<String, ConcurrentMap<String, RpcStatus>>();
public static RpcStatus getStatus(URL url, String methodName) {
String uri = url.toIdentityString();
ConcurrentMap<String, RpcStatus> map = METHOD_STATISTICS.computeIfAbsent(uri, k -> new ConcurrentHashMap<>());
return map.computeIfAbsent(methodName, k -> new RpcStatus());
}
public int getActive() {
return active.get();
}
}
ConsistentHashLoadBalance
ConsistentHashLoadBalance 小伙伴們應(yīng)該也不會陌生，在分庫分表、各種集群中就經(jīng)常使用這個負(fù)載均衡策略。
ConsistentHashLoadBalance 即一致性 Hash 負(fù)載均衡策略。ConsistentHashLoadBalance 中沒有權(quán)重的概念，具體是哪個服務(wù)提供者處理請求是由你的請求的參數(shù)決定的，也就是說相同參數(shù)的請求總是發(fā)到同一個服務(wù)提供者。
另外，Dubbo 為了避免數(shù)據(jù)傾斜問題（節(jié)點不夠分散，大量請求落到同一節(jié)點），還引入了虛擬節(jié)點的概念。通過虛擬節(jié)點可以讓節(jié)點更加分散，有效均衡各個節(jié)點的請求量。
官方有詳細(xì)的源碼分析：https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#23-consistenthashloadbalance 。這里還有一個相關(guān)的 PR#5440 來修復(fù)老版本中 ConsistentHashLoadBalance 存在的一些 Bug。感興趣的小伙伴，可以多花點時間研究一下。我這里不多分析了，這個作業(yè)留給你們！
RoundRobinLoadBalance
加權(quán)輪詢負(fù)載均衡。
輪詢就是把請求依次分配給每個服務(wù)提供者。加權(quán)輪詢就是在輪詢的基礎(chǔ)上，讓更多的請求落到權(quán)重更大的服務(wù)提供者上。比如假如有兩個提供相同服務(wù)的服務(wù)器 S1,S2，S1 的權(quán)重為 7，S2 的權(quán)重為 3。
如果我們有 10 次請求，那么 7 次會被 S1 處理，3 次被 S2 處理。
但是，如果是 RandomLoadBalance 的話，很可能存在 10 次請求有 9 次都被 S1 處理的情況（概率性問題）。
Dubbo 中的 RoundRobinLoadBalance 的代碼實現(xiàn)被修改重建了好幾次，Dubbo-2.6.5 版本的 RoundRobinLoadBalance 為平滑加權(quán)輪詢算法。
Dubbo 序列化協(xié)議
Dubbo 支持哪些序列化方式呢？
Dubbo 支持多種序列化方式：JDK 自帶的序列化、hessian2、JSON、Kryo、FST、Protostuff，ProtoBuf 等等。
Dubbo 默認(rèn)使用的序列化方式是 hession2。
談?wù)勀銓@些序列化協(xié)議了解？
一般我們不會直接使用 JDK 自帶的序列化方式。主要原因有兩個：
不支持跨語言調(diào)用 : 如果調(diào)用的是其他語言開發(fā)的服務(wù)的時候就不支持了。 性能差 ：相比于其他序列化框架性能更低，主要原因是序列化之后的字節(jié)數(shù)組體積較大，導(dǎo)致傳輸成本加大。
JSON 序列化由于性能問題，我們一般也不會考慮使用。
像 Protostuff，ProtoBuf、hessian2 這些都是跨語言的序列化方式，如果有跨語言需求的話可以考慮使用。
Kryo 和 FST 這兩種序列化方式是 Dubbo 后來才引入的，性能非常好。不過，這兩者都是專門針對 Java 語言的。Dubbo 官網(wǎng)的一篇文章中提到說推薦使用 Kryo 作為生產(chǎn)環(huán)境的序列化方式。(文章地址：https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/rest/)
Dubbo 官方文檔中還有一個關(guān)于這些序列化協(xié)議的性能對比圖可供參考。
往期精選
我真不想學(xué) happens - before 了！
大家好，今天是分享 Dubbo 知識點/面試題總結(jié)的 Guide！
這篇文章是我根據(jù)官方文檔以及自己平時的使用情況，對 Dubbo 所做的一個總結(jié)。
文章內(nèi)容有一點長，一次看不完的話，記得收藏起來，找時間再看！
原創(chuàng)不易，若有幫助，點贊/分享就是對我最大的鼓勵！
個人能力有限。如果文章有任何需要補(bǔ)充/完善/修改的地方，歡迎在評論區(qū)指出，共同進(jìn)步！
RPC 基礎(chǔ)
何為 RPC?
RPC（Remote Procedure Call） 即遠(yuǎn)程過程調(diào)用，通過名字我們就能看出 RPC 關(guān)注的是遠(yuǎn)程調(diào)用而非本地調(diào)用。
為什么要 RPC ？ 因為，兩個不同的服務(wù)器上的服務(wù)提供的方法不在一個內(nèi)存空間，所以，需要通過網(wǎng)絡(luò)編程才能傳遞方法調(diào)用所需要的參數(shù)。并且，方法調(diào)用的結(jié)果也需要通過網(wǎng)絡(luò)編程來接收。但是，如果我們自己手動網(wǎng)絡(luò)編程來實現(xiàn)這個調(diào)用過程的話工作量是非常大的，因為，我們需要考慮底層傳輸方式（TCP 還是 UDP）、序列化方式等等方面。
RPC 能幫助我們做什么呢？ 簡單來說，通過 RPC 可以幫助我們調(diào)用遠(yuǎn)程計算機(jī)上某個服務(wù)的方法，這個過程就像調(diào)用本地方法一樣簡單。并且！我們不需要了解底層網(wǎng)絡(luò)編程的具體細(xì)節(jié)。
舉個例子：兩個不同的服務(wù) A、B 部署在兩臺不同的機(jī)器上，服務(wù) A 如果想要調(diào)用服務(wù) B 中的某個方法的話就可以通過 RPC 來做。
一言蔽之：RPC 的出現(xiàn)就是為了讓你調(diào)用遠(yuǎn)程方法像調(diào)用本地方法一樣簡單。
RPC 的原理是什么?
為了能夠幫助小伙伴們理解 RPC 原理，我們可以將整個 RPC 的 核心功能看作是下面 ?? 6 個部分實現(xiàn)的：
客戶端（服務(wù)消費端） ：調(diào)用遠(yuǎn)程方法的一端。 客戶端 Stub（樁） ：這其實就是一代理類。代理類主要做的事情很簡單，就是把你調(diào)用方法、類、方法參數(shù)等信息傳遞到服務(wù)端。 網(wǎng)絡(luò)傳輸 ：網(wǎng)絡(luò)傳輸就是你要把你調(diào)用的方法的信息比如說參數(shù)啊這些東西傳輸?shù)椒?wù)端，然后服務(wù)端執(zhí)行完之后再把返回結(jié)果通過網(wǎng)絡(luò)傳輸給你傳輸回來。網(wǎng)絡(luò)傳輸?shù)膶崿F(xiàn)方式有很多種比如最近基本的 Socket 或者性能以及封裝更加優(yōu)秀的 Netty（推薦）。 服務(wù)端 Stub（樁） ：這個樁就不是代理類了。我覺得理解為樁實際不太好，大家注意一下就好。這里的服務(wù)端 Stub 實際指的就是接收到客戶端執(zhí)行方法的請求后，去指定對應(yīng)的方法然后返回結(jié)果給客戶端的類。 服務(wù)端（服務(wù)提供端） ：提供遠(yuǎn)程方法的一端。
具體原理圖如下，后面我會串起來將整個 RPC 的過程給大家說一下。
服務(wù)消費端（client）以本地調(diào)用的方式調(diào)用遠(yuǎn)程服務(wù)； 客戶端 Stub（client stub） 接收到調(diào)用后負(fù)責(zé)將方法、參數(shù)等組裝成能夠進(jìn)行網(wǎng)絡(luò)傳輸?shù)南Ⅲw（序列化）： RpcRequest；客戶端 Stub（client stub） 找到遠(yuǎn)程服務(wù)的地址，并將消息發(fā)送到服務(wù)提供端； 服務(wù)端 Stub（樁）收到消息將消息反序列化為 Java 對象: RpcRequest；服務(wù)端 Stub（樁）根據(jù) RpcRequest中的類、方法、方法參數(shù)等信息調(diào)用本地的方法；服務(wù)端 Stub（樁）得到方法執(zhí)行結(jié)果并將組裝成能夠進(jìn)行網(wǎng)絡(luò)傳輸?shù)南Ⅲw： RpcResponse（序列化）發(fā)送至消費方；客戶端 Stub（client stub）接收到消息并將消息反序列化為 Java 對象: RpcResponse，這樣也就得到了最終結(jié)果。over!
相信小伙伴們看完上面的講解之后，已經(jīng)了解了 RPC 的原理。
雖然篇幅不多，但是基本把 RPC 框架的核心原理講清楚了！另外，對于上面的技術(shù)細(xì)節(jié)，我會在后面的章節(jié)介紹到。
最后，對于 RPC 的原理，希望小伙伴不單單要理解，還要能夠自己畫出來并且能夠給別人講出來。因為，在面試中這個問題在面試官問到 RPC 相關(guān)內(nèi)容的時候基本都會碰到。
Dubbo 基礎(chǔ)
什么是 Dubbo?
Apache Dubbo (incubating) |?d?b??| 是一款高性能、輕量級的開源 Java RPC 框架。
根據(jù) Dubbo 官方文檔的介紹，Dubbo 提供了六大核心能力
面向接口代理的高性能 RPC 調(diào)用。 智能容錯和負(fù)載均衡。 服務(wù)自動注冊和發(fā)現(xiàn)。 高度可擴(kuò)展能力。 運(yùn)行期流量調(diào)度。 可視化的服務(wù)治理與運(yùn)維。
簡單來說就是：Dubbo 不光可以幫助我們調(diào)用遠(yuǎn)程服務(wù)，還提供了一些其他開箱即用的功能比如智能負(fù)載均衡。
Dubbo 目前已經(jīng)有接近 34.4 k 的 Star 。
在 2020 年度 OSC 中國開源項目 評選活動中，Dubbo 位列開發(fā)框架和基礎(chǔ)組件類項目的第 7 名。想比幾年前來說，熱度和排名有所下降。
Dubbo 是由阿里開源，后來加入了 Apache 。正式由于 Dubbo 的出現(xiàn)，才使得越來越多的公司開始使用以及接受分布式架構(gòu)。
為什么要用 Dubbo?
隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)站的規(guī)模越來越大，用戶數(shù)量越來越多。單一應(yīng)用架構(gòu) 、垂直應(yīng)用架構(gòu)無法滿足我們的需求，這個時候分布式服務(wù)架構(gòu)就誕生了。
分布式服務(wù)架構(gòu)下，系統(tǒng)被拆分成不同的服務(wù)比如短信服務(wù)、安全服務(wù)，每個服務(wù)獨立提供系統(tǒng)的某個核心服務(wù)。
我們可以使用 Java RMI（Java Remote Method Invocation）、Hessian 這種支持遠(yuǎn)程調(diào)用的框架來簡單地暴露和引用遠(yuǎn)程服務(wù)。但是！當(dāng)服務(wù)越來越多之后，服務(wù)調(diào)用關(guān)系越來越復(fù)雜。當(dāng)應(yīng)用訪問壓力越來越大后，負(fù)載均衡以及服務(wù)監(jiān)控的需求也迫在眉睫。我們可以用 F5 這類硬件來做負(fù)載均衡，但這樣增加了成本，并且存在單點故障的風(fēng)險。
不過，Dubbo 的出現(xiàn)讓上述問題得到了解決。Dubbo 幫助我們解決了什么問題呢？
負(fù)載均衡 ：同一個服務(wù)部署在不同的機(jī)器時該調(diào)用那一臺機(jī)器上的服務(wù)。 服務(wù)調(diào)用鏈路生成 ：隨著系統(tǒng)的發(fā)展，服務(wù)越來越多，服務(wù)間依賴關(guān)系變得錯蹤復(fù)雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。Dubbo 可以為我們解決服務(wù)之間互相是如何調(diào)用的。 服務(wù)訪問壓力以及時長統(tǒng)計、資源調(diào)度和治理 ：基于訪問壓力實時管理集群容量，提高集群利用率。 ......
另外，Dubbo 除了能夠應(yīng)用在分布式系統(tǒng)中，也可以應(yīng)用在現(xiàn)在比較火的微服務(wù)系統(tǒng)中。不過，由于 Spring Cloud 在微服務(wù)中應(yīng)用更加廣泛，所以，我覺得一般我們提 Dubbo 的話，大部分是分布式系統(tǒng)的情況。
我們剛剛提到了分布式這個概念，下面再給大家介紹一下什么是分布式？為什么要分布式？
分布式基礎(chǔ)
什么是分布式?
分布式或者說 SOA 分布式重要的就是面向服務(wù)，說簡單的分布式就是我們把整個系統(tǒng)拆分成不同的服務(wù)然后將這些服務(wù)放在不同的服務(wù)器上減輕單體服務(wù)的壓力提高并發(fā)量和性能。比如電商系統(tǒng)可以簡單地拆分成訂單系統(tǒng)、商品系統(tǒng)、登錄系統(tǒng)等等，拆分之后的每個服務(wù)可以部署在不同的機(jī)器上，如果某一個服務(wù)的訪問量比較大的話也可以將這個服務(wù)同時部署在多臺機(jī)器上。
為什么要分布式?
從開發(fā)角度來講單體應(yīng)用的代碼都集中在一起，而分布式系統(tǒng)的代碼根據(jù)業(yè)務(wù)被拆分。所以，每個團(tuán)隊可以負(fù)責(zé)一個服務(wù)的開發(fā)，這樣提升了開發(fā)效率。另外，代碼根據(jù)業(yè)務(wù)拆分之后更加便于維護(hù)和擴(kuò)展。
另外，我覺得將系統(tǒng)拆分成分布式之后不光便于系統(tǒng)擴(kuò)展和維護(hù)，更能提高整個系統(tǒng)的性能。你想一想嘛？把整個系統(tǒng)拆分成不同的服務(wù)/系統(tǒng)，然后每個服務(wù)/系統(tǒng) 單獨部署在一臺服務(wù)器上，是不是很大程度上提高了系統(tǒng)性能呢？
Dubbo 架構(gòu)
Dubbo 架構(gòu)中的核心角色有哪些？
官方文檔中的框架設(shè)計章節(jié) 已經(jīng)介紹的非常詳細(xì)了，我這里把一些比較重要的點再提一下。
上述節(jié)點簡單介紹以及他們之間的關(guān)系：
Container： 服務(wù)運(yùn)行容器，負(fù)責(zé)加載、運(yùn)行服務(wù)提供者。必須。 Provider： 暴露服務(wù)的服務(wù)提供方，會向注冊中心注冊自己提供的服務(wù)。必須。 Consumer： 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方，會向注冊中心訂閱自己所需的服務(wù)。必須。 Registry： 服務(wù)注冊與發(fā)現(xiàn)的注冊中心。注冊中心會返回服務(wù)提供者地址列表給消費者。非必須。 Monitor： 統(tǒng)計服務(wù)的調(diào)用次數(shù)和調(diào)用時間的監(jiān)控中心。服務(wù)消費者和提供者會定時發(fā)送統(tǒng)計數(shù)據(jù)到監(jiān)控中心。非必須。
Dubbo 中的 Invoker 概念了解么？
Invoker 是 Dubbo 領(lǐng)域模型中非常重要的一個概念，你如果閱讀過 Dubbo 源碼的話，你會無數(shù)次看到這玩意。就比如下面我要說的負(fù)載均衡這塊的源碼中就有大量 Invoker 的身影。
簡單來說，Invoker 就是 Dubbo 對遠(yuǎn)程調(diào)用的抽象。
按照 Dubbo 官方的話來說，Invoker 分為
服務(wù)提供 Invoker服務(wù)消費 Invoker
假如我們需要調(diào)用一個遠(yuǎn)程方法，我們需要動態(tài)代理來屏蔽遠(yuǎn)程調(diào)用的細(xì)節(jié)吧！我們屏蔽掉的這些細(xì)節(jié)就依賴對應(yīng)的 Invoker 實現(xiàn)， Invoker 實現(xiàn)了真正的遠(yuǎn)程服務(wù)調(diào)用。
Dubbo 的工作原理了解么？
下圖是 Dubbo 的整體設(shè)計，從下至上分為十層，各層均為單向依賴。
左邊淡藍(lán)背景的為服務(wù)消費方使用的接口，右邊淡綠色背景的為服務(wù)提供方使用的接口，位于中軸線上的為雙方都用到的接口。
config 配置層：Dubbo 相關(guān)的配置。支持代碼配置，同時也支持基于 Spring 來做配置，以 ServiceConfig,ReferenceConfig為中心proxy 服務(wù)代理層：調(diào)用遠(yuǎn)程方法像調(diào)用本地的方法一樣簡單的一個關(guān)鍵，真實調(diào)用過程依賴代理類，以 ServiceProxy為中心。registry 注冊中心層：封裝服務(wù)地址的注冊與發(fā)現(xiàn)。 cluster 路由層：封裝多個提供者的路由及負(fù)載均衡，并橋接注冊中心，以 Invoker為中心。monitor 監(jiān)控層：RPC 調(diào)用次數(shù)和調(diào)用時間監(jiān)控，以 Statistics為中心。protocol 遠(yuǎn)程調(diào)用層：封裝 RPC 調(diào)用，以 Invocation,Result為中心。exchange 信息交換層：封裝請求響應(yīng)模式，同步轉(zhuǎn)異步，以 Request,Response為中心。transport 網(wǎng)絡(luò)傳輸層：抽象 mina 和 netty 為統(tǒng)一接口，以 Message為中心。serialize 數(shù)據(jù)序列化層 ：對需要在網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)進(jìn)行序列化。
Dubbo 的 SPI 機(jī)制了解么？如何擴(kuò)展 Dubbo 中的默認(rèn)實現(xiàn)？
SPI（Service Provider Interface） 機(jī)制被大量用在開源項目中，它可以幫助我們動態(tài)尋找服務(wù)/功能（比如負(fù)載均衡策略）的實現(xiàn)。
SPI 的具體原理是這樣的：我們將接口的實現(xiàn)類放在配置文件中，我們在程序運(yùn)行過程中讀取配置文件，通過反射加載實現(xiàn)類。這樣，我們可以在運(yùn)行的時候，動態(tài)替換接口的實現(xiàn)類。和 IoC 的解耦思想是類似的。
Java 本身就提供了 SPI 機(jī)制的實現(xiàn)。不過，Dubbo 沒有直接用，而是對 Java 原生的 SPI 機(jī)制進(jìn)行了增強(qiáng)，以便更好滿足自己的需求。
那我們?nèi)绾螖U(kuò)展 Dubbo 中的默認(rèn)實現(xiàn)呢？
比如說我們想要實現(xiàn)自己的負(fù)載均衡策略，我們創(chuàng)建對應(yīng)的實現(xiàn)類 XxxLoadBalance 實現(xiàn) LoadBalance 接口或者 AbstractLoadBalance 類。
package com.xxx;
import org.apache.dubbo.rpc.cluster.LoadBalance;
import org.apache.dubbo.rpc.Invoker;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.RpcException;
public class XxxLoadBalance implements LoadBalance {
public <T> Invoker<T> select(List<Invoker<T>> invokers, Invocation invocation) throws RpcException {
// ...
}
}
我們將這個是實現(xiàn)類的路徑寫入到resources 目錄下的 META-INF/dubbo/org.apache.dubbo.rpc.cluster.LoadBalance文件中即可。
src
|-main
|-java
|-com
|-xxx
|-XxxLoadBalance.java (實現(xiàn)LoadBalance接口)
|-resources
|-META-INF
|-dubbo
|-org.apache.dubbo.rpc.cluster.LoadBalance (純文本文件，內(nèi)容為：xxx=com.xxx.XxxLoadBalance)
org.apache.dubbo.rpc.cluster.LoadBalance
xxx=com.xxx.XxxLoadBalance
其他還有很多可供擴(kuò)展的選擇，你可以在官方文檔@SPI 擴(kuò)展實現(xiàn)這里找到。
Dubbo 的微內(nèi)核架構(gòu)了解嗎？
Dubbo 采用 微內(nèi)核（Microkernel） + 插件（Plugin） 模式，簡單來說就是微內(nèi)核架構(gòu)。微內(nèi)核只負(fù)責(zé)組裝插件。
何為微內(nèi)核架構(gòu)呢？ 《軟件架構(gòu)模式》 這本書是這樣介紹的：
微內(nèi)核架構(gòu)模式（有時被稱為插件架構(gòu)模式）是實現(xiàn)基于產(chǎn)品應(yīng)用程序的一種自然模式?；诋a(chǎn)品的應(yīng)用程序是已經(jīng)打包好并且擁有不同版本，可作為第三方插件下載的。然后，很多公司也在開發(fā)、發(fā)布自己內(nèi)部商業(yè)應(yīng)用像有版本號、說明及可加載插件式的應(yīng)用軟件（這也是這種模式的特征）。微內(nèi)核系統(tǒng)可讓用戶添加額外的應(yīng)用如插件，到核心應(yīng)用，繼而提供了可擴(kuò)展性和功能分離的用法。
微內(nèi)核架構(gòu)包含兩類組件：核心系統(tǒng)（core system） 和 插件模塊（plug-in modules）。
核心系統(tǒng)提供系統(tǒng)所需核心能力，插件模塊可以擴(kuò)展系統(tǒng)的功能。因此， 基于微內(nèi)核架構(gòu)的系統(tǒng)，非常易于擴(kuò)展功能。
我們常見的一些 IDE，都可以看作是基于微內(nèi)核架構(gòu)設(shè)計的。絕大多數(shù) IDE 比如 IDEA、VSCode 都提供了插件來豐富自己的功能。
正是因為 Dubbo 基于微內(nèi)核架構(gòu)，才使得我們可以隨心所欲替換 Dubbo 的功能點。比如你覺得 Dubbo 的序列化模塊實現(xiàn)的不滿足自己要求，沒關(guān)系??！你自己實現(xiàn)一個序列化模塊就好了??！
通常情況下，微核心都會采用 Factory、IoC、OSGi 等方式管理插件生命周期。Dubbo 不想依賴 Spring 等 IoC 容器，也不想自已造一個小的 IoC 容器（過度設(shè)計），因此采用了一種最簡單的 Factory 方式管理插件 ：JDK 標(biāo)準(zhǔn)的 SPI 擴(kuò)展機(jī)制 （java.util.ServiceLoader）。
關(guān)于 Dubbo 架構(gòu)的一些自測小問題
注冊中心的作用了解么？
注冊中心負(fù)責(zé)服務(wù)地址的注冊與查找，相當(dāng)于目錄服務(wù)，服務(wù)提供者和消費者只在啟動時與注冊中心交互。
服務(wù)提供者宕機(jī)后，注冊中心會做什么？
注冊中心會立即推送事件通知消費者。
監(jiān)控中心的作用呢？
監(jiān)控中心負(fù)責(zé)統(tǒng)計各服務(wù)調(diào)用次數(shù)，調(diào)用時間等。
注冊中心和監(jiān)控中心都宕機(jī)的話，服務(wù)都會掛掉嗎？
不會。兩者都宕機(jī)也不影響已運(yùn)行的提供者和消費者，消費者在本地緩存了提供者列表。注冊中心和監(jiān)控中心都是可選的，服務(wù)消費者可以直連服務(wù)提供者。
Dubbo 的負(fù)載均衡策略
什么是負(fù)載均衡？
先來看一下稍微官方點的解釋。下面這段話摘自維基百科對負(fù)載均衡的定義：
負(fù)載均衡改善了跨多個計算資源（例如計算機(jī)，計算機(jī)集群，網(wǎng)絡(luò)鏈接，中央處理單元或磁盤驅(qū)動）的工作負(fù)載分布。負(fù)載平衡旨在優(yōu)化資源使用，最大化吞吐量，最小化響應(yīng)時間，并避免任何單個資源的過載。使用具有負(fù)載平衡而不是單個組件的多個組件可以通過冗余提高可靠性和可用性。負(fù)載平衡通常涉及專用軟件或硬件。
上面講的大家可能不太好理解，再用通俗的話給大家說一下。
我們的系統(tǒng)中的某個服務(wù)的訪問量特別大，我們將這個服務(wù)部署在了多臺服務(wù)器上，當(dāng)客戶端發(fā)起請求的時候，多臺服務(wù)器都可以處理這個請求。那么，如何正確選擇處理該請求的服務(wù)器就很關(guān)鍵。假如，你就要一臺服務(wù)器來處理該服務(wù)的請求，那該服務(wù)部署在多臺服務(wù)器的意義就不復(fù)存在了。負(fù)載均衡就是為了避免單個服務(wù)器響應(yīng)同一請求，容易造成服務(wù)器宕機(jī)、崩潰等問題，我們從負(fù)載均衡的這四個字就能明顯感受到它的意義。
Dubbo 提供的負(fù)載均衡策略有哪些？
在集群負(fù)載均衡時，Dubbo 提供了多種均衡策略，默認(rèn)為 random 隨機(jī)調(diào)用。我們還可以自行擴(kuò)展負(fù)載均衡策略（參考 Dubbo SPI 機(jī)制）。
在 Dubbo 中，所有負(fù)載均衡實現(xiàn)類均繼承自 AbstractLoadBalance，該類實現(xiàn)了 LoadBalance 接口，并封裝了一些公共的邏輯。
public abstract class AbstractLoadBalance implements LoadBalance {
static int calculateWarmupWeight(int uptime, int warmup, int weight) {
}
@Override
public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
}
protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);
int getWeight(Invoker<?> invoker, Invocation invocation) {
}
}
AbstractLoadBalance 的實現(xiàn)類有下面這些：
官方文檔對負(fù)載均衡這部分的介紹非常詳細(xì)，推薦小伙伴們看看，地址：https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#m-zhdocsv27devsourceloadbalance 。
RandomLoadBalance
根據(jù)權(quán)重隨機(jī)選擇（對加權(quán)隨機(jī)算法的實現(xiàn)）。這是 Dubbo 默認(rèn)采用的一種負(fù)載均衡策略。
RandomLoadBalance 具體的實現(xiàn)原理非常簡單，假如有兩個提供相同服務(wù)的服務(wù)器 S1,S2，S1 的權(quán)重為 7，S2 的權(quán)重為 3。
我們把這些權(quán)重值分布在坐標(biāo)區(qū)間會得到：S1->[0, 7) ，S2->(7, 10]。我們生成[0, 10) 之間的隨機(jī)數(shù)，隨機(jī)數(shù)落到對應(yīng)的區(qū)間，我們就選擇對應(yīng)的服務(wù)器來處理請求。
RandomLoadBalance 的源碼非常簡單，簡單花幾分鐘時間看一下。
以下源碼來自 Dubbo master 分支上的最新的版本 2.7.9。
public class RandomLoadBalance extends AbstractLoadBalance {
public static final String NAME = "random";
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
int length = invokers.size();
boolean sameWeight = true;
int[] weights = new int[length];
int totalWeight = 0;
// 下面這個for循環(huán)的主要作用就是計算所有該服務(wù)的提供者的權(quán)重之和 totalWeight（），
// 除此之外，還會檢測每個服務(wù)提供者的權(quán)重是否相同
for (int i = 0; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
totalWeight += weight;
weights[i] = totalWeight;
if (sameWeight && totalWeight != weight * (i + 1)) {
sameWeight = false;
}
}
if (totalWeight > 0 && !sameWeight) {
// 隨機(jī)生成一個 [0, totalWeight) 區(qū)間內(nèi)的數(shù)字
int offset = ThreadLocalRandom.current().nextInt(totalWeight);
// 判斷會落在哪個服務(wù)提供者的區(qū)間
for (int i = 0; i < length; i++) {
if (offset < weights[i]) {
return invokers.get(i);
}
}
return invokers.get(ThreadLocalRandom.current().nextInt(length));
}
}
LeastActiveLoadBalance
LeastActiveLoadBalance 直譯過來就是最小活躍數(shù)負(fù)載均衡。
這個名字起得有點不直觀，不仔細(xì)看官方對活躍數(shù)的定義，你壓根不知道這玩意是干嘛的。
我這么說吧！初始狀態(tài)下所有服務(wù)提供者的活躍數(shù)均為 0（每個服務(wù)提供者的中特定方法都對應(yīng)一個活躍數(shù)，我在后面的源碼中會提到），每收到一個請求后，對應(yīng)的服務(wù)提供者的活躍數(shù) +1，當(dāng)這個請求處理完之后，活躍數(shù) -1。
因此，Dubbo 就認(rèn)為誰的活躍數(shù)越少，誰的處理速度就越快，性能也越好，這樣的話，我就優(yōu)先把請求給活躍數(shù)少的服務(wù)提供者處理。
如果有多個服務(wù)提供者的活躍數(shù)相等怎么辦？
很簡單，那就再走一遍 RandomLoadBalance 。
public class LeastActiveLoadBalance extends AbstractLoadBalance {
public static final String NAME = "leastactive";
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
int length = invokers.size();
int leastActive = -1;
int leastCount = 0;
int[] leastIndexes = new int[length];
int[] weights = new int[length];
int totalWeight = 0;
int firstWeight = 0;
boolean sameWeight = true;
// 這個 for 循環(huán)的主要作用是遍歷 invokers 列表，找出活躍數(shù)最小的 Invoker
// 如果有多個 Invoker 具有相同的最小活躍數(shù)，還會記錄下這些 Invoker 在 invokers 集合中的下標(biāo)，并累加它們的權(quán)重，比較它們的權(quán)重值是否相等
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
// 獲取 invoker 對應(yīng)的活躍(active)數(shù)
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
int afterWarmup = getWeight(invoker, invocation);
weights[i] = afterWarmup;
if (leastActive == -1 || active < leastActive) {
leastActive = active;
leastCount = 1;
leastIndexes[0] = i;
totalWeight = afterWarmup;
firstWeight = afterWarmup;
sameWeight = true;
} else if (active == leastActive) {
leastIndexes[leastCount++] = i;
totalWeight += afterWarmup;
if (sameWeight && afterWarmup != firstWeight) {
sameWeight = false;
}
}
}
// 如果只有一個 Invoker 具有最小的活躍數(shù)，此時直接返回該 Invoker 即可
if (leastCount == 1) {
return invokers.get(leastIndexes[0]);
}
// 如果有多個 Invoker 具有相同的最小活躍數(shù)，但它們之間的權(quán)重不同
// 這里的處理方式就和 RandomLoadBalance 一致了
if (!sameWeight && totalWeight > 0) {
int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
for (int i = 0; i < leastCount; i++) {
int leastIndex = leastIndexes[i];
offsetWeight -= weights[leastIndex];
if (offsetWeight < 0) {
return invokers.get(leastIndex);
}
}
}
return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
}
}
活躍數(shù)是通過 RpcStatus 中的一個 ConcurrentMap 保存的，根據(jù) URL 以及服務(wù)提供者被調(diào)用的方法的名稱，我們便可以獲取到對應(yīng)的活躍數(shù)。也就是說服務(wù)提供者中的每一個方法的活躍數(shù)都是互相獨立的。
public class RpcStatus {
private static final ConcurrentMap<String, ConcurrentMap<String, RpcStatus>> METHOD_STATISTICS =
new ConcurrentHashMap<String, ConcurrentMap<String, RpcStatus>>();
public static RpcStatus getStatus(URL url, String methodName) {
String uri = url.toIdentityString();
ConcurrentMap<String, RpcStatus> map = METHOD_STATISTICS.computeIfAbsent(uri, k -> new ConcurrentHashMap<>());
return map.computeIfAbsent(methodName, k -> new RpcStatus());
}
public int getActive() {
return active.get();
}
}
ConsistentHashLoadBalance
ConsistentHashLoadBalance 小伙伴們應(yīng)該也不會陌生，在分庫分表、各種集群中就經(jīng)常使用這個負(fù)載均衡策略。
ConsistentHashLoadBalance 即一致性 Hash 負(fù)載均衡策略。ConsistentHashLoadBalance 中沒有權(quán)重的概念，具體是哪個服務(wù)提供者處理請求是由你的請求的參數(shù)決定的，也就是說相同參數(shù)的請求總是發(fā)到同一個服務(wù)提供者。
另外，Dubbo 為了避免數(shù)據(jù)傾斜問題（節(jié)點不夠分散，大量請求落到同一節(jié)點），還引入了虛擬節(jié)點的概念。通過虛擬節(jié)點可以讓節(jié)點更加分散，有效均衡各個節(jié)點的請求量。
官方有詳細(xì)的源碼分析：https://dubbo.apache.org/zh/docs/v2.7/dev/source/loadbalance/#23-consistenthashloadbalance 。這里還有一個相關(guān)的 PR#5440 來修復(fù)老版本中 ConsistentHashLoadBalance 存在的一些 Bug。感興趣的小伙伴，可以多花點時間研究一下。我這里不多分析了，這個作業(yè)留給你們！
RoundRobinLoadBalance
加權(quán)輪詢負(fù)載均衡。
輪詢就是把請求依次分配給每個服務(wù)提供者。加權(quán)輪詢就是在輪詢的基礎(chǔ)上，讓更多的請求落到權(quán)重更大的服務(wù)提供者上。比如假如有兩個提供相同服務(wù)的服務(wù)器 S1,S2，S1 的權(quán)重為 7，S2 的權(quán)重為 3。
如果我們有 10 次請求，那么 7 次會被 S1 處理，3 次被 S2 處理。
但是，如果是 RandomLoadBalance 的話，很可能存在 10 次請求有 9 次都被 S1 處理的情況（概率性問題）。
Dubbo 中的 RoundRobinLoadBalance 的代碼實現(xiàn)被修改重建了好幾次，Dubbo-2.6.5 版本的 RoundRobinLoadBalance 為平滑加權(quán)輪詢算法。
Dubbo 序列化協(xié)議
Dubbo 支持哪些序列化方式呢？
Dubbo 支持多種序列化方式：JDK 自帶的序列化、hessian2、JSON、Kryo、FST、Protostuff，ProtoBuf 等等。
Dubbo 默認(rèn)使用的序列化方式是 hession2。
談?wù)勀銓@些序列化協(xié)議了解？
一般我們不會直接使用 JDK 自帶的序列化方式。主要原因有兩個：
不支持跨語言調(diào)用 : 如果調(diào)用的是其他語言開發(fā)的服務(wù)的時候就不支持了。 性能差 ：相比于其他序列化框架性能更低，主要原因是序列化之后的字節(jié)數(shù)組體積較大，導(dǎo)致傳輸成本加大。
JSON 序列化由于性能問題，我們一般也不會考慮使用。
像 Protostuff，ProtoBuf、hessian2 這些都是跨語言的序列化方式，如果有跨語言需求的話可以考慮使用。
Kryo 和 FST 這兩種序列化方式是 Dubbo 后來才引入的，性能非常好。不過，這兩者都是專門針對 Java 語言的。Dubbo 官網(wǎng)的一篇文章中提到說推薦使用 Kryo 作為生產(chǎn)環(huán)境的序列化方式。(文章地址：https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/rest/)
Dubbo 官方文檔中還有一個關(guān)于這些序列化協(xié)議的性能對比圖可供參考。
往期精選
我真不想學(xué) happens - before 了！