(給ImportNew加星標(biāo)，提高Java技能)

作者：why技術(shù)(本文來(lái)自作者投稿)

本文是對(duì)于Dubbo負(fù)載均衡策略之一的最小活躍數(shù)算法的詳細(xì)分析。文中所示源碼，沒(méi)有特別標(biāo)注的地方均為2.6.0版本。

為什么沒(méi)有用截止目前的最新的版本號(hào)2.7.4.1呢？因?yàn)?.6.0這個(gè)版本里面有兩個(gè)bug。從bug講起來(lái)，印象更加深刻。

最后會(huì)對(duì)2.6.0/2.6.5/2.7.4.1版本進(jìn)行對(duì)比，通過(guò)對(duì)比學(xué)習(xí)，加深印象。

本文目錄

第一節(jié)：Demo準(zhǔn)備。

本小節(jié)主要是為了演示方便，搭建了一個(gè)Demo服務(wù)。Demo中啟動(dòng)三個(gè)服務(wù)端，負(fù)載均衡策略均是最小活躍數(shù)，權(quán)重各不相同。

第二節(jié)：斷點(diǎn)打在哪？

本小節(jié)主要是分享我看源碼的方式。以及我們看源碼時(shí)斷點(diǎn)如何設(shè)置，怎么避免在源碼里面"瞎逛"。

第三節(jié)：模擬環(huán)境。

本小節(jié)主要是基于Demo的改造，模擬真實(shí)環(huán)境。在此過(guò)程中發(fā)現(xiàn)了問(wèn)題，引申出下一小節(jié)。

第四節(jié)：active為什么是0？

本小節(jié)主要介紹了RpcStatus類(lèi)中的active字段在最小活躍數(shù)算法中所承擔(dān)的作用，以及其什么時(shí)候發(fā)生變化。讓讀者明白為什么需要在customer端配置ActiveLimitFilter攔截器。

第五節(jié)：剖析源碼

本小節(jié)對(duì)于最小活躍數(shù)算法的實(shí)現(xiàn)類(lèi)進(jìn)行了逐行代碼的解讀，基本上在每一行代碼上加入了注釋。屬于全文重點(diǎn)部分。

第六節(jié)：Bug在哪里？

逐行解讀完源碼后，引出了2.6.0版本最小活躍數(shù)算法的兩個(gè)Bug。并通過(guò)2.6.0/2.6.5/2.7.4.1三個(gè)版本的異同點(diǎn)進(jìn)行交叉對(duì)比，加深讀者印象。

第七節(jié)：意外收獲?

看官方文檔的時(shí)候發(fā)現(xiàn)了一處小小的筆誤，我對(duì)其進(jìn)行了修改并被merged。主要是介紹給開(kāi)源項(xiàng)目貢獻(xiàn)代碼的流程。

PS：前一到三節(jié)主要是分享我看源碼的一點(diǎn)思路和技巧，如果你不感興趣可以直接從第四節(jié)開(kāi)始看起。本文的重點(diǎn)是第四到第六節(jié)。

另：閱讀本文需要對(duì)Dubbo有一定的了解。

一.Demo準(zhǔn)備

我看源碼的習(xí)慣是先搞個(gè)Demo把調(diào)試環(huán)境搭起來(lái)。然后帶著疑問(wèn)去抽絲剝繭的Debug，不放過(guò)在這個(gè)過(guò)程中在腦海里面一閃而過(guò)的任何疑問(wèn)。

這篇文章分享的是Dubbo負(fù)載均衡策略之一最小活躍數(shù)(LeastActiveLoadBalance)。所以我先搭建一個(gè)Dubbo的項(xiàng)目，并啟動(dòng)三個(gè)provider供consumer調(diào)用。

三個(gè)provider的loadbalance均配置的是leastactive。權(quán)重分別是默認(rèn)權(quán)重、200、300。

默認(rèn)權(quán)重是多少？后面看源碼的時(shí)候，源碼會(huì)告訴你。

三個(gè)不同的服務(wù)提供者會(huì)給調(diào)用方返回自己是什么權(quán)重的服務(wù)。

啟動(dòng)三個(gè)實(shí)例。(注:上面的provider.xml和DemoServiceImpl其實(shí)只有一個(gè)，每次啟動(dòng)的時(shí)候手動(dòng)修改端口、權(quán)重即可。)

到zookeeper上檢查一下，服務(wù)提供者是否正常：

可以看到三個(gè)服務(wù)提供者分別在20880、20881、20882端口。(每個(gè)紅框的最后5個(gè)數(shù)字就是端口號(hào))。

最后，我們?cè)倏捶?wù)消費(fèi)者。消費(fèi)者很簡(jiǎn)單，配置consumer.xml

直接調(diào)用接口并打印返回值即可。

二.斷點(diǎn)打在哪？

相信很多朋友也很想看源碼，但是不知道從何處下手。處于一種在源碼里面"亂逛"的狀態(tài)，一圈逛下來(lái)，收獲并不大。

這一小節(jié)我想分享一下我是怎么去看源碼。首先我會(huì)帶著問(wèn)題去源碼里面尋找答案，即有針對(duì)性的看源碼。

如果是這種框架類(lèi)的，正如上面寫(xiě)的，我會(huì)先搭建一個(gè)簡(jiǎn)單的Demo項(xiàng)目，然后Debug跟進(jìn)去看。Debug的時(shí)候當(dāng)然需要是設(shè)置斷點(diǎn)的，那么這個(gè)斷點(diǎn)如何設(shè)置呢？

第一個(gè)斷點(diǎn)，當(dāng)然毋庸置疑，是打在調(diào)用方法的地方，比如本文中，第一個(gè)斷點(diǎn)是在這個(gè)地方：

接下里怎么辦？

你當(dāng)然可以從第一個(gè)斷點(diǎn)處，一步一步的跟進(jìn)去。但是在這個(gè)過(guò)程中，你發(fā)現(xiàn)了嗎？大多數(shù)情況你都是被源碼牽著鼻子走的。本來(lái)你就只帶著一個(gè)問(wèn)題去看源碼的，有可能你Debug了十分鐘，還沒(méi)找到關(guān)鍵的代碼。也有可能你Debug了十分鐘，問(wèn)題從一個(gè)變成了無(wú)數(shù)個(gè)。

那么我們?cè)趺幢苊獗辉创a牽著四處亂逛呢？我們得找到一個(gè)突破口，還記得我在《很開(kāi)心，在使用mybatis的過(guò)程中我踩到一個(gè)坑》這篇文章中提到的逆向排查的方法嗎？這次的文章,我再次展示一下該方法。

看源碼之前，我們得冷靜的分析。目標(biāo)要十分明確，就是想要找到Dubbo最小活躍數(shù)算法的具體實(shí)現(xiàn)類(lèi)以及實(shí)現(xiàn)類(lèi)的具體邏輯是什么。根據(jù)我們的provider.xml里面的：

很明顯，我們知道loadbalance是關(guān)鍵字。所以我們拿著loadbalance全局搜索，可以看到dubbo包下面的LoadBalance。

這是一個(gè)SPI接口com.alibaba.dubbo.rpc.cluster.LoadBalance：

其實(shí)現(xiàn)類(lèi)為:

com.alibaba.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance

AbstractLoadBalance是一個(gè)抽象類(lèi)，該類(lèi)里面有一個(gè)抽象方法doSelect。這個(gè)抽象方法其中的一個(gè)實(shí)現(xiàn)類(lèi)就是我們要分析的最少活躍次數(shù)負(fù)載均衡的源碼。

同時(shí)，到這里。我們知道了LoadBalance是一個(gè)SPI接口，說(shuō)明我們可以擴(kuò)展自己的負(fù)載均衡策略。抽象方法doSelect有四個(gè)實(shí)現(xiàn)類(lèi)。這個(gè)四個(gè)實(shí)現(xiàn)類(lèi)，就是Dubbo官方提供的負(fù)載均衡策略，他們分別是:

• ConsistentHashLoadBalance 一致性哈希算法?

• LeastActiveLoadBalance 最小活躍數(shù)算法?

• RandomLoadBalance? 加權(quán)隨機(jī)算法?

• RoundRobinLoadBalance 加權(quán)輪詢(xún)算法

我們已經(jīng)找到了LeastActiveLoadBalance這個(gè)類(lèi)了，那么我們的第二個(gè)斷點(diǎn)打在哪里已經(jīng)很明確了。

目前看來(lái)，兩個(gè)斷點(diǎn)就可以支撐我們的分析了。

有的朋友可能想問(wèn)，那我想知道Dubbo是怎么識(shí)別出我們想要的是最少活躍次數(shù)算法，而不是其他的算法呢？其他的算法是怎么實(shí)現(xiàn)的呢？從第一個(gè)斷點(diǎn)到第二個(gè)斷點(diǎn)直接有著怎樣的調(diào)用鏈呢？

在沒(méi)有徹底搞清楚最少活躍數(shù)算法之前，這些統(tǒng)統(tǒng)先記錄在案但不予理睬。一定要明確目標(biāo)，帶著一個(gè)問(wèn)題進(jìn)來(lái)，就先把帶來(lái)的問(wèn)題解決了。之后再去解決在這個(gè)過(guò)程中碰到的其他問(wèn)題。在這樣環(huán)環(huán)相扣解決問(wèn)題的過(guò)程中，你就慢慢的把握了源碼的精髓。這是我個(gè)人的一點(diǎn)看源碼的心得。供諸君參考。

三.模擬環(huán)境

既然叫做最小活躍數(shù)策略。那我們得讓現(xiàn)有的三個(gè)消費(fèi)者都有一些調(diào)用次數(shù)。所以我們得改造一下服務(wù)提供者和消費(fèi)者。

服務(wù)提供者端的改造如下:

PS：這里以權(quán)重為300的服務(wù)端為例。另外的兩個(gè)服務(wù)端改造點(diǎn)相同。

客戶(hù)端的改造點(diǎn)如下(for循環(huán)里面的i應(yīng)該為<20)：

一共發(fā)送21個(gè)請(qǐng)求：其中前20個(gè)先發(fā)到服務(wù)端讓其hold住(因?yàn)榉?wù)端有sleep)，最后一個(gè)請(qǐng)求就是我們需要Debug跟蹤的請(qǐng)求。

運(yùn)行一下，讓程序停在斷點(diǎn)的地方,然后看看控制臺(tái)的輸出:

• 權(quán)重為300的服務(wù)端共計(jì)收到9個(gè)請(qǐng)求

• 權(quán)重為200的服務(wù)端共計(jì)收到6個(gè)請(qǐng)求

• 默認(rèn)權(quán)重的服務(wù)端共計(jì)收到5個(gè)請(qǐng)求

我們還有一個(gè)請(qǐng)求在Debug。直接進(jìn)入到我們的第二個(gè)斷點(diǎn)的位置，并Debug到下圖所示的一行代碼(可以點(diǎn)看查看大圖):

正如上面這圖所說(shuō)的：weight=100回答了一個(gè)問(wèn)題，active=0提出的一個(gè)問(wèn)題。

weight=100回答了什么問(wèn)題呢？

默認(rèn)權(quán)重是多少？是100。

我們服務(wù)端的活躍數(shù)分別應(yīng)該是下面這樣的

• 權(quán)重為300的服務(wù)端，active=9?

• 權(quán)重為200的服務(wù)端，active=6?

• 默認(rèn)權(quán)重(100)的服務(wù)端，active=5

但是這里為什么active會(huì)等于0呢？這是一個(gè)問(wèn)題。

繼續(xù)往下Debug你會(huì)發(fā)現(xiàn)，每一個(gè)服務(wù)端的active都是0。所以相比之下沒(méi)有一個(gè)invoker有最小active。于是程序走到了根據(jù)權(quán)重選擇invoker的邏輯中。

四.active為什么是0？

active為0說(shuō)明在dubbo調(diào)用的過(guò)程中active并沒(méi)有發(fā)生變化。那active為什么是0，其實(shí)就是在問(wèn)active什么時(shí)候發(fā)生變化？

要回答這個(gè)問(wèn)題我們得知道active是在哪里定義的，因?yàn)樵谄涠x的地方，必有其修改的方法。

下面這圖說(shuō)明了active是定義在RpcStatus類(lèi)里面的一個(gè)類(lèi)型為AtomicInteger的成員變量。

在RpcStatus類(lèi)中，有三處()調(diào)用active值的方法，一個(gè)增加、一個(gè)減少、一個(gè)獲取：

很明顯，我們需要看的是第一個(gè)，在哪里增加。

所以我們找到了beginCount(URL,String)方法，該方法只有兩個(gè)Filter調(diào)用。ActiveLimitFilter，見(jiàn)名知意，這就是我們要找的東西。

com.alibaba.dubbo.rpc.filter.ActiveLimitFilter具體如下：

看到這里，我們就知道怎么去回答這個(gè)問(wèn)題了：為什么active是0呢？因?yàn)樵诳蛻?hù)端沒(méi)有配置ActiveLimitFilter。所以，ActiveLimitFilter沒(méi)有生效，導(dǎo)致active沒(méi)有發(fā)生變化。

怎么讓其生效呢？已經(jīng)呼之欲出了。

好了，再來(lái)試驗(yàn)一次:

加上Filter之后，我們通過(guò)Debug可以看到，對(duì)應(yīng)權(quán)重的活躍數(shù)就和我們預(yù)期的是一致的了。

• 權(quán)重為300的活躍數(shù)為6?

• 權(quán)重為200的活躍數(shù)為11?

• 默認(rèn)權(quán)重(100)的活躍數(shù)為3

根據(jù)活躍數(shù)我們可以分析出來(lái)，最后我們Debug住的這個(gè)請(qǐng)求，一定會(huì)選擇默認(rèn)權(quán)重的invoker去執(zhí)行，因?yàn)樗钱?dāng)前活躍數(shù)最小的invoker。如下所示：

雖然到這里我們還沒(méi)開(kāi)始進(jìn)行源碼的分析，只是把流程梳理清楚了。但是把Demo完整的搭建了起來(lái)，而且知道了最少活躍數(shù)負(fù)載均衡算法必須配合ActiveLimitFilter使用，位于RpcStatus類(lèi)的active字段才會(huì)起作用，否則，它就是一個(gè)基于權(quán)重的算法。

比起其他地方直接告訴你，要配置ActiveLimitFilter才行哦，我們自己實(shí)驗(yàn)得出的結(jié)論，能讓我們的印象更加深刻。

我們?cè)僮屑?xì)看一下加上ActiveLimitFilter之后的各個(gè)服務(wù)的活躍數(shù)情況：

• 權(quán)重為300的活躍數(shù)為6??

• 權(quán)重為200的活躍數(shù)為11??

• 默認(rèn)權(quán)重(100)的活躍數(shù)為3

你不覺(jué)得奇怪嗎，為什么權(quán)重為200的活躍數(shù)是最高的？

其在業(yè)務(wù)上的含義是：我們有三臺(tái)性能各異的服務(wù)器，A服務(wù)器性能最好，所以權(quán)重為300，B服務(wù)器性能中等，所以權(quán)重為200，C服務(wù)器性能最差，所以權(quán)重為100。

當(dāng)我們選擇最小活躍次數(shù)的負(fù)載均衡算法時(shí)，我們期望的是性能最好的A服務(wù)器承擔(dān)更多的請(qǐng)求，而真實(shí)的情況是性能中等的B服務(wù)器承擔(dān)的請(qǐng)求更多。這與我們的設(shè)定相悖。

如果你說(shuō)20個(gè)請(qǐng)求數(shù)據(jù)量太少，可能是巧合，不足以說(shuō)明問(wèn)題。說(shuō)明你還沒(méi)被我?guī)?#xff0c;我們不能基于巧合編程。

所以為了驗(yàn)證這個(gè)地方確實(shí)有問(wèn)題，我把請(qǐng)求擴(kuò)大到一萬(wàn)個(gè)。

同時(shí)，記得擴(kuò)大provider端的Dubbo線程池：

由于每個(gè)服務(wù)端運(yùn)行的代碼都是一樣的，所以我們期望的結(jié)果應(yīng)該是權(quán)重最高的承擔(dān)更多的請(qǐng)求。但是最終的結(jié)果如圖所示:

各個(gè)服務(wù)器均攤了請(qǐng)求。這就是我文章最開(kāi)始的時(shí)候說(shuō)的Dubbo 2.6.0版本中最小活躍數(shù)負(fù)載均衡算法的Bug之一。

接下來(lái)，我們帶著這個(gè)問(wèn)題，去分析源碼。

五.剖析源碼

com.alibaba.dubbo.rpc.cluster.loadbalance.LeastActiveLoadBalance的源碼如下，我逐行進(jìn)行了解讀。可以點(diǎn)開(kāi)查看大圖，細(xì)細(xì)品讀，非常爽：

下圖中紅框框起來(lái)的部分就是一個(gè)基于權(quán)重選擇invoker的邏輯：

我給大家畫(huà)圖分析一下：

請(qǐng)仔細(xì)分析圖中給出的舉例說(shuō)明。同時(shí)，上面這圖也是按照比例畫(huà)的，可以直觀的看到，對(duì)于某一個(gè)請(qǐng)求，區(qū)間(權(quán)重)越大的服務(wù)器，就越可能會(huì)承擔(dān)這個(gè)請(qǐng)求。所以，當(dāng)請(qǐng)求足夠多的時(shí)候，各個(gè)服務(wù)器承擔(dān)的請(qǐng)求數(shù)，應(yīng)該就是區(qū)間，即權(quán)重的比值。

其中第81行有調(diào)用getWeight方法，位于抽象類(lèi)AbstractLoadBalance中，也需要進(jìn)行重點(diǎn)解讀的代碼。

com.alibaba.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance的源碼如下，我也進(jìn)行了大量的備注:

在AbstractLoadBalance類(lèi)中提到了一個(gè)預(yù)熱的概念。官網(wǎng)中是這樣的介紹該功能的：

權(quán)重的計(jì)算過(guò)程主要用于保證當(dāng)服務(wù)運(yùn)行時(shí)長(zhǎng)小于服務(wù)預(yù)熱時(shí)間時(shí)，對(duì)服務(wù)進(jìn)行降權(quán)，避免讓服務(wù)在啟動(dòng)之初就處于高負(fù)載狀態(tài)。服務(wù)預(yù)熱是一個(gè)優(yōu)化手段，與此類(lèi)似的還有 JVM 預(yù)熱。主要目的是讓服務(wù)啟動(dòng)后“低功率”運(yùn)行一段時(shí)間，使其效率慢慢提升至最佳狀態(tài)。

從上圖代碼里面的公式(演變后)：計(jì)算后的權(quán)重=(uptime/warmup)*weight可以看出：隨著服務(wù)啟動(dòng)時(shí)間的增加(uptime)，計(jì)算后的權(quán)重會(huì)越來(lái)越接近weight。從實(shí)際場(chǎng)景的角度來(lái)看，隨著服務(wù)啟動(dòng)時(shí)間的增加，服務(wù)承擔(dān)的流量會(huì)慢慢上升，沒(méi)有一個(gè)陡升的過(guò)程。所以這是一個(gè)優(yōu)化手段。同時(shí)Dubbo接口還支持延遲暴露。

在仔細(xì)的看完上面的源碼解析圖后，配合官網(wǎng)的總結(jié)加上我的靈魂畫(huà)作，相信你可以對(duì)最小活躍數(shù)負(fù)載均衡算法有一個(gè)比較深入的理解：

1. 遍歷 invokers 列表，尋找活躍數(shù)最小的 Invoker

2. 如果有多個(gè) Invoker 具有相同的最小活躍數(shù)，此時(shí)記錄下這些 Invoker 在 invokers 集合中的下標(biāo)，并累加它們的權(quán)重，比較它們的權(quán)重值是否相等?

3. 如果只有一個(gè) Invoker 具有最小的活躍數(shù)，此時(shí)直接返回該 Invoker 即可

4. 如果有多個(gè) Invoker 具有最小活躍數(shù)，且它們的權(quán)重不相等，此時(shí)處理方式和 RandomLoadBalance 一致

5. 如果有多個(gè) Invoker 具有最小活躍數(shù)，但它們的權(quán)重相等，此時(shí)隨機(jī)返回一個(gè)即可

所以我覺(jué)得最小活躍數(shù)負(fù)載均衡的全稱(chēng)應(yīng)該叫做：有最小活躍數(shù)用最小活躍數(shù)，沒(méi)有最小活躍數(shù)根據(jù)權(quán)重選擇，權(quán)重一樣則隨機(jī)返回的負(fù)載均衡算法。

六.BUG在哪里

Dubbo2.6.0最小活躍數(shù)算法Bug一

問(wèn)題出在標(biāo)號(hào)為①和②這兩行代碼中：

標(biāo)號(hào)為①的代碼在url中取出的是沒(méi)有經(jīng)過(guò)getWeight方法降權(quán)處理的權(quán)重值，這個(gè)值會(huì)被累加到權(quán)重總和(totalWeight)中。

標(biāo)號(hào)為②的代碼取的是經(jīng)過(guò)getWeight方法處理后的權(quán)重值。

取值的差異會(huì)導(dǎo)致一個(gè)問(wèn)題，標(biāo)號(hào)為②的代碼的左邊，offsetWeight是一個(gè)在[0，totalWeight)范圍內(nèi)的隨機(jī)數(shù)，右邊是經(jīng)過(guò)getWeight方法降權(quán)后的權(quán)重。所以在經(jīng)過(guò)leastCount次的循環(huán)減法后，offsetWeight在服務(wù)啟動(dòng)時(shí)間還沒(méi)到熱啟動(dòng)設(shè)置(默認(rèn)10分鐘)的這段時(shí)間內(nèi)，極大可能仍然大于0。導(dǎo)致不會(huì)進(jìn)入到標(biāo)號(hào)為③的代碼中。直接到標(biāo)號(hào)為④的代碼處，變成了隨機(jī)調(diào)用策略。這與設(shè)計(jì)不符，所以是個(gè)bug。

前面章節(jié)說(shuō)的情況就是這個(gè)Bug導(dǎo)致的。

這個(gè)Bug對(duì)應(yīng)的issues地址和pull request分為:

• https://github.com/apache/dubbo/issues/904

• https://github.com/apache/dubbo/pull/2172

那怎么修復(fù)的呢？我們直接對(duì)比Dubbo 2.7.4.1(目前最新版本)的代碼:

可以看到獲取weight的方法變了：從url中直接獲取變成了通過(guò)getWeight方法獲取。獲取到的變量名稱(chēng)也變了：從weight變成了afterWarmup，更加的見(jiàn)名知意。

還有一處變化是獲取隨機(jī)值的方法的變化，從Randmo變成了ThreadLoaclRandom，性能得到了提升。這處變化就不展開(kāi)講了，有興趣的朋友可以去了解一下。

ThreadLocalRandom

Dubbo2.6.0最小活躍數(shù)算法Bug二

這個(gè)Bug我沒(méi)有遇到，但是我在官方文檔上看了其描述(官方文檔中的版本是2.6.4)，引用如下：

官網(wǎng)上說(shuō)這個(gè)問(wèn)題在2.6.5版本進(jìn)行修復(fù)。我對(duì)比了2.6.0/2.6.5/2.7.4.1三個(gè)版本，發(fā)現(xiàn)每個(gè)版本都略有不同。如下所示：

圖中標(biāo)記為①的三處代碼：

2.6.0版本的是有Bug的代碼，原因在上面說(shuō)過(guò)了。

2.6.5版本的修復(fù)方式是獲取隨機(jī)數(shù)的時(shí)候加一，所以取值范圍就從[0,totalWeight)變成了[0,totalWeight]，這樣就可以避免這個(gè)問(wèn)題。

2.7.4.1版本的取值范圍還是[0,totalWeight)，但是它的修復(fù)方法體現(xiàn)在了標(biāo)記為②的代碼處。2.6.0/2.6.5版本標(biāo)記為②的地方都是if(offsetWeight<=0)，而2.7.4.1版本變成了if(offsetWeight<0)。

你品一品，是不是效果是一樣的，但是更加優(yōu)雅了。

朋友們，魔鬼，都在細(xì)節(jié)里啊！

七.意外收獲

在看官網(wǎng)文檔負(fù)載均衡介紹的時(shí)候。發(fā)現(xiàn)了一處筆誤。所以我對(duì)其進(jìn)行了修改并被merged。

可以看到，改動(dòng)點(diǎn)也是一個(gè)非常小的地方。但是，我也為Dubbo社區(qū)貢獻(xiàn)了一份自己的力量。我是Dubbo文檔的committer，簡(jiǎn)稱(chēng)"Dubbo committer"。

本小節(jié)主要是簡(jiǎn)單的介紹一下給開(kāi)源項(xiàng)目提pr的流程。

首先，fork項(xiàng)目到自己的倉(cāng)庫(kù)中。然后執(zhí)行以下命令，拉取項(xiàng)目并設(shè)置源：

git clone https://github.com/thisiswanghy/dubbo-website.git cd dubbo-website
git remote add upstream https://github.com/apache/dubbo-website.git git remote set-url --push upstream no_push

創(chuàng)建本地分支:

git checkout -b xxxx

開(kāi)發(fā)完成后提交代碼:

git fetch upstream
git checkout master
git merge upstream/master git checkout -b xxxx git rebase master git push origin xxxx:xxxx

然后到git上創(chuàng)建pull request后，靜候通知。

最后說(shuō)一句

之前也寫(xiě)過(guò)Dubbo的文章《Dubbo 2.7新特性之異步化改造》，通過(guò)對(duì)比Dubbo2.6.0/2.7.0/2.7.3版本的源碼，分析Dubbo2.7 異步化的改造的細(xì)節(jié)，可以看看哦。

推薦閱讀

(點(diǎn)擊標(biāo)題可跳轉(zhuǎn)閱讀)

一文聊透 Dubbo 優(yōu)雅上線

一文詳細(xì)解讀 Dubbo 中的 http 協(xié)議

Java 調(diào)試技能之 dubbo 調(diào)試 — telnet

看完本文有收獲？請(qǐng)轉(zhuǎn)發(fā)分享給更多人

關(guān)注「ImportNew」，提升Java技能

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的cstring只获取到第一个数_一文讲透 Dubbo 负载均衡之最小活跃数算法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。