[[422543]]

本文轉(zhuǎn)載自微信公眾號(hào)「Kirito的技術(shù)分享」，作者kiritomoe。轉(zhuǎn)載本文請(qǐng)聯(lián)系Kirito的技術(shù)分享公眾號(hào)。

前言

剛發(fā)現(xiàn)微信公眾號(hào)有了標(biāo)簽功能，于是乎，我將我 Dubbo 相關(guān)的文章都打上了標(biāo)簽，仔細(xì)一統(tǒng)計(jì)，這已經(jīng)是我第 41 篇原創(chuàng)的 Dubbo 文章了，如果你希望看到我其他的 Dubbo 文章，可以從話題標(biāo)簽點(diǎn)擊進(jìn)入。

這是一篇很久之前就想動(dòng)筆寫(xiě)的文章，最近正好看到群里有小伙伴分享了 Dubbo 連接相關(guān)的文章，才又讓我想起了這個(gè)話題。今天想跟大家聊的便是 Dubbo 中的連接控制這一話題。說(shuō)到“連接控制”，可能有讀者還沒(méi)反應(yīng)過(guò)來(lái)，但你對(duì)下面的配置可能不會(huì)感到陌生：

<dubbo:reference interface="com.foo.BarService" connections="10" /> 

如果你還不了解 Dubbo 中連接控制的用法，可以參考官方文檔：https://dubbo.apache.org/zh/docs/advanced/config-connections/ ，話說(shuō)最近 Dubbo 官方文檔來(lái)了一次大換血，好多熟悉的文檔差點(diǎn)都沒(méi)找到在哪兒 Orz。

眾所周知，dubbo 協(xié)議通信默認(rèn)是長(zhǎng)連接，連接配置功能用于決定消費(fèi)者與提供者建立的長(zhǎng)連接數(shù)。但官方文檔只給出了該功能的使用方法，卻并沒(méi)有說(shuō)明什么時(shí)候應(yīng)該配置連接控制，本文將主要圍繞該話題進(jìn)行探討。

本文也會(huì)涉及長(zhǎng)連接相關(guān)的一些知識(shí)點(diǎn)。

##使用方式

先來(lái)看一個(gè) Dubbo 構(gòu)建的簡(jiǎn)單 demo，啟動(dòng)一個(gè)消費(fèi)者(192.168.4.226)和一個(gè)提供者(192.168.4.224)，配置他們的直連。

消費(fèi)者：

<dubbo:reference id="userService" check="false" 
    interface="org.apache.dubbo.benchmark.service.UserService" 
    url="dubbo://192.168.4.224:20880"/> 

提供者：

<dubbo:service interface="org.apache.dubbo.benchmark.service.UserService" ref="userService" /> 
<bean id="userService" class="org.apache.dubbo.benchmark.service.UserServiceServerImpl"/> 

長(zhǎng)連接是看不見(jiàn)摸不著的東西，我們需要一個(gè)觀測(cè)性工作來(lái)”看到“它。啟動(dòng)提供者和消費(fèi)者之后，可以使用如下的命令查看 tcp 連接情況

• Mac 下可使用：lsof -i:20880
• Linux 下可使用：netstat -ano | grep 20880

提供者：

[root ~]# netstat -ano | grep 20880 
tcp6       0      0 192.168.4.224:20880      :::*                    LISTEN      off (0.00/0/0) 
tcp6    2502      0 192.168.4.224:20880      192.168.4.226:59100     ESTABLISHED off (0.00/0/0) 

消費(fèi)者：

[root@ ~]# netstat -ano | grep 20880 
tcp6     320    720 192.168.4.226:59110     192.168.4.224:20880      ESTABLISHED on (0.00/0/0) 

通過(guò)上述觀察到的現(xiàn)象我們可以發(fā)現(xiàn)幾個(gè)事實(shí)。

僅僅是啟動(dòng)了提供者和消費(fèi)者，上述的 TCP 連接就已經(jīng)了存在，要知道我并沒(méi)有觸發(fā)調(diào)用。也就是說(shuō)，Dubbo 建連的默認(rèn)策略是在地址發(fā)現(xiàn)時(shí)，而不是在調(diào)用時(shí)。當(dāng)然，你也可以通過(guò)延遲加載 lazy="true" 來(lái)修改這一行為，這樣可以將建聯(lián)延遲到調(diào)用時(shí)。

<dubbo:reference id="userService" check="false" 
    interface="org.apache.dubbo.benchmark.service.UserService" 
    url="dubbo://${server.host}:${server.port}" 
    lazy="true"/> 

除此之外，還可以發(fā)現(xiàn)消費(fèi)者和提供者之間只有一條長(zhǎng)連接，20880 是 Dubbo 提供者默認(rèn)開(kāi)放的端口，就跟 tomcat 默認(rèn)開(kāi)放的 8080 一個(gè)地位，而 59110 是消費(fèi)者隨機(jī)生成的一個(gè)端口。(我之前跟一些朋友交流過(guò)，發(fā)現(xiàn)很多人不知道消費(fèi)者也是需要占用一個(gè)端口的)

而今天的主角”連接控制“便可以控制長(zhǎng)連接的數(shù)量，例如我們可以進(jìn)行如下的配置

<dubbo:reference id="userService" check="false" 
    interface="org.apache.dubbo.benchmark.service.UserService" 
    url="dubbo://192.168.4.224:20880" 
    connections="2" /> 

再啟動(dòng)一次消費(fèi)者，觀察長(zhǎng)連接情況

提供者：

[root@ ~]# netstat -ano | grep 20880 
tcp6       0      0 192.168.4.224:20880      :::*                    LISTEN      off (0.00/0/0) 
tcp6    2508     96 192.168.4.224:20880      192.168.4.226:59436     ESTABLISHED on (0.00/0/0) 
tcp6    5016    256 192.168.4.224:20880      192.168.4.226:59434     ESTABLISHED on (0.00/0/0) 

消費(fèi)者：

[root@ ~]# netstat -ano | grep 20880 
tcp6       0   2520 192.168.4.226:59436     192.168.4.224:20880      ESTABLISHED on (0.00/0/0) 
tcp6      48   1680 192.168.4.226:59434     192.168.4.224:20880      ESTABLISHED on (0.00/0/0) 

可以看到，這里已經(jīng)變成了兩條長(zhǎng)連接了。

什么時(shí)候需要配置多條長(zhǎng)連接

現(xiàn)在我們知道了如何進(jìn)行連接控制，但什么時(shí)候我們應(yīng)該配置多少條長(zhǎng)連接呢?這個(gè)時(shí)候我可以跟你說(shuō)，具體視生產(chǎn)情況而定，但你如果你經(jīng)常看我的公眾號(hào)，肯定會(huì)知道這不是我的風(fēng)格，我的風(fēng)格是什么?benchmark!

寫(xiě)作之前，我跟幾個(gè)同事和網(wǎng)友對(duì)這個(gè)話題進(jìn)行了簡(jiǎn)單的討論，其實(shí)也沒(méi)有什么定論，無(wú)非是對(duì)單連接和多連接吞吐量高低不同的論調(diào)。參考既往 Dubbo github 中的 issue，例如：https://github.com/apache/dubbo/pull/2457，我也參與了這個(gè) pr 的討論，講道理，我是持懷疑態(tài)度的，我當(dāng)時(shí)的觀點(diǎn)是多連接不一定能夠提升服務(wù)的吞吐量(還是挺保守的，沒(méi)有這么絕對(duì))。

那接下來(lái)，還是用 benchmark 來(lái)說(shuō)話吧，測(cè)試工程還是我們的老朋友，使用 Dubbo 官方提供的 dubbo-benchmark 工程。

• 測(cè)試工程地址：https://github.com/apache/dubbo-benchmark.git
• 測(cè)試環(huán)境：2 臺(tái)阿里云 Linux 4c8g ECS

測(cè)試工程在之前的文章介紹過(guò)，這里就不過(guò)多贅述了，測(cè)試方案也非常簡(jiǎn)單，兩輪 benchmark，分別測(cè)試 connections=1 和 connections=2 時(shí)，觀察測(cè)試方法的吞吐量。

說(shuō)干就干，省略一堆測(cè)試步驟，直接給出測(cè)試結(jié)果。

Benchmark           Mode  Cnt      Score      Error  Units 
Client.createUser  thrpt    3  22265.286 ± 3060.319  ops/s 
Client.existUser   thrpt    3  33129.331 ± 1488.404  ops/s 
Client.getUser     thrpt    3  19916.133 ± 1745.249  ops/s 
Client.listUser    thrpt    3   3523.905 ±  590.250  ops/s 

connections=2

Benchmark           Mode  Cnt      Score      Error  Units 
Client.createUser  thrpt    3  31111.698 ± 3039.052  ops/s 
Client.existUser   thrpt    3  42449.230 ± 2964.239  ops/s 
Client.getUser     thrpt    3  30647.173 ± 2551.448  ops/s 
Client.listUser    thrpt    3   6581.876 ±  469.831  ops/s 

從測(cè)試結(jié)果來(lái)看，似乎單連接和多連接的差距是非常大的，近乎可以看做是 2 倍了!看起來(lái)連接控制的效果真是好呀，那么事實(shí)真的如此嗎?

按照這種方案第一次測(cè)試下來(lái)之后，我也不太相信這個(gè)結(jié)果，因?yàn)槲抑鞍凑掌渌绞阶鲞^(guò)多連接的測(cè)試，并且我也參加過(guò)第三屆中間件挑戰(zhàn)賽，使得我對(duì)長(zhǎng)連接的認(rèn)知是：大多數(shù)時(shí)候，單連接往往能發(fā)揮出最優(yōu)的性能。即使由于硬件原因，這個(gè)差距也不應(yīng)該是兩倍。懷著這樣的疑問(wèn)，我開(kāi)始研究，是不是我的測(cè)試場(chǎng)景出了什么問(wèn)題呢?

發(fā)現(xiàn)測(cè)試方案的問(wèn)題

經(jīng)過(guò)和閃電俠的討論，他的一席話最終讓我定位到了問(wèn)題的所在。

不知道大家看完我和閃電俠的對(duì)話，有沒(méi)有立刻定位到問(wèn)題所在。

之前測(cè)試方案最大的問(wèn)題便是沒(méi)有控制好變量，殊不知：在連接數(shù)變化的同時(shí)，實(shí)際使用的 IO 線程數(shù)實(shí)際也發(fā)生了變化。

Dubbo 使用 Netty 來(lái)實(shí)現(xiàn)長(zhǎng)連接通信，提到長(zhǎng)連接和 IO 線程的關(guān)系，這里就要介紹到 Netty 的連接模型了。一言以蔽之，Netty 的設(shè)置 IO worker 線程和 channel 是一對(duì)多的綁定關(guān)系，即一個(gè) channel 在建連之后，便會(huì)完全由一個(gè) IO 線程來(lái)負(fù)責(zé)全部的 IO 操作。再來(lái)看看 Dubbo 是如何設(shè)置 NettyClient 和 NettyServer 的 worker 線程組的：

客戶(hù)端 org.apache.dubbo.remoting.transport.netty4.NettyClient：

private static final EventLoopGroup NIO_EVENT_LOOP_GROUP = eventLoopGroup(Constants.DEFAULT_IO_THREADS, "NettyClientWorker"); 
   
  @Override 
  protected void doOpen() throws Throwable { 
      final NettyClientHandler nettyClientHandler = new NettyClientHandler(getUrl(), this); 
      bootstrap = new Bootstrap(); 
      bootstrap.group(NIO_EVENT_LOOP_GROUP) 
              .option(ChannelOption.SO_KEEPALIVE, true) 
              .option(ChannelOption.TCP_NODELAY, true) 
              .option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT); 
    ... 
  } 

Constants.DEFAULT_IO_THREADS 在 org.apache.dubbo.remoting.Constants 中被寫(xiě)死了

int DEFAULT_IO_THREADS = Math.min(Runtime.getRuntime().availableProcessors() + 1, 32); 

在我的 4c8g 的機(jī)器上，默認(rèn)等于 5。

服務(wù)端 org.apache.dubbo.remoting.transport.netty4.NettyServer：

protected void doOpen() throws Throwable { 
        bootstrap = new ServerBootstrap(); 
 
        bossGroup = NettyEventLoopFactory.eventLoopGroup(1, "NettyServerBoss"); 
        workerGroup = NettyEventLoopFactory.eventLoopGroup( 
                getUrl().getPositiveParameter(IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS), 
                "NettyServerWorker"); 
 
        final NettyServerHandler nettyServerHandler = new NettyServerHandler(getUrl(), this); 
        channels = nettyServerHandler.getChannels(); 
 
        ServerBootstrap serverBootstrap = bootstrap.group(bossGroup, workerGroup) 
            .channel(NettyEventLoopFactory.serverSocketChannelClass()); 
        .option(ChannelOption.SO_REUSEADDR, Boolean.TRUE) 
                .childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE) 
                .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT); 
                 
 } 

服務(wù)端倒是可以配置，例如我們可以通過(guò) protocol 來(lái)控制服務(wù)端的 IO 線程數(shù)：

<dubbo:protocol name="dubbo" host="${server.host}" server="netty4" port="${server.port}" iothreads="5"/> 

如果不設(shè)置，則跟客戶(hù)端邏輯一致，是 core + 1 個(gè)線程。

好了，問(wèn)題就在這兒，由于我并沒(méi)有進(jìn)行任何 IO 線程的設(shè)置，所以客戶(hù)端和服務(wù)端都會(huì)默認(rèn)開(kāi)啟 5 個(gè) IO 線程。當(dāng) connections=1 時(shí)，Netty 會(huì)將 channel1 綁定到一個(gè) IO 線程上，而當(dāng) connections=2 時(shí)，Netty 會(huì)將 channel1 和 channel2 按照順序綁定到 NettyWorkerThread-1和 NettyWorkerThread-2 上，這樣就會(huì)有兩個(gè) IO 線程在工作，這樣的測(cè)試結(jié)果當(dāng)然是不公平的。

這里需要考慮實(shí)際情況，在實(shí)際生產(chǎn)中，大多數(shù)時(shí)候都是分布式場(chǎng)景，連接數(shù)一定都是大于 IO 線程數(shù)的，所以基本不會(huì)出現(xiàn)測(cè)試場(chǎng)景中的 channel 數(shù)少于 IO 線程數(shù)的場(chǎng)景。

解決方案也很簡(jiǎn)單，我們需要控制變量，讓 IO 線程數(shù)一致，僅僅觀察連接數(shù)對(duì)吞吐量的影響。針對(duì)服務(wù)端，可以在 protocol 層配置 iothreads=1;針對(duì)客戶(hù)端，由于源碼被寫(xiě)死了，這里我只能通過(guò)修改源碼的方式，重新本地打了一個(gè)包，使得客戶(hù)端 IO 線程數(shù)也可以通過(guò) -D 參數(shù)指定。

改造之后的，我們得到了如下的測(cè)試結(jié)果：

1 IO 線程 1 連接

Benchmark           Mode  Cnt      Score      Error  Units 
Client.createUser  thrpt    3  22265.286 ± 3060.319  ops/s 
Client.existUser   thrpt    3  33129.331 ± 1488.404  ops/s 
Client.getUser     thrpt    3  19916.133 ± 1745.249  ops/s 
Client.listUser    thrpt    3   3523.905 ±  590.250  ops/s 

1 IO 線程 2 連接

Benchmark           Mode  Cnt      Score      Error  Units 
Client.createUser  thrpt    3  21776.436 ± 1888.845  ops/s 
Client.existUser   thrpt    3  31826.320 ± 1350.434  ops/s 
Client.getUser     thrpt    3  19354.470 ±  369.486  ops/s 
Client.listUser    thrpt    3   3506.714 ±   18.924  ops/s 

可以發(fā)現(xiàn)，單純提升連接數(shù)并不會(huì)提升服務(wù)的吞吐量，這樣的測(cè)試結(jié)果也更加符合我認(rèn)知的預(yù)期。

總結(jié)

從上述測(cè)試的結(jié)果來(lái)看，一些配置參數(shù)并不是越大就代表了越好，類(lèi)似的例子我也在多線程寫(xiě)文件等場(chǎng)景分析過(guò)，唯有理論分析+實(shí)際測(cè)試才能得出值得信服的結(jié)論。當(dāng)然個(gè)人的測(cè)試，也可能會(huì)因?yàn)榫植啃躁P(guān)鍵信息的遺漏，導(dǎo)致誤差，例如，如果我最終沒(méi)有發(fā)現(xiàn) IO 線程數(shù)和連接數(shù)之間的隱性關(guān)聯(lián)，很容易就得出連接數(shù)和吞吐量成正比的錯(cuò)誤結(jié)論了。當(dāng)然，也不一定就代表本文最終的結(jié)論是靠譜的，說(shuō)不定還是不夠完善的，也歡迎大家留言，提出意見(jiàn)和建議。

最終回到最初的問(wèn)題，我們什么時(shí)候應(yīng)該配置 Dubbo 的連接控制呢?按照我個(gè)人的經(jīng)驗(yàn)，大多數(shù)時(shí)候，生產(chǎn)環(huán)境下連接數(shù)是非常多的，你可以挑選一臺(tái)線上的主機(jī)，通過(guò) netstat -ano| grep 20880| wc -l 來(lái)大概統(tǒng)計(jì)下，一般是遠(yuǎn)超 IO 線程數(shù)的，沒(méi)必要再多配置成倍的連接數(shù)，連接數(shù)和吞吐量并不是一個(gè)線性增長(zhǎng)的關(guān)系。

Dubbo 框架有這個(gè)能力和大家真的需要用這個(gè)能力完全是兩碼事，我相信大多數(shù)讀者應(yīng)該已經(jīng)過(guò)了技術(shù)新鮮感驅(qū)動(dòng)項(xiàng)目的階段了吧?如果有一天你需要控制連接數(shù)，去達(dá)到一定特殊的用途，你就會(huì)真心感嘆，Dubbo 真是強(qiáng)呀，這個(gè)擴(kuò)展點(diǎn)都有。

Dubbo 的連接控制真的完全沒(méi)有用嗎?也不盡然，我的測(cè)試場(chǎng)景還是非常有限的，可能在不同硬件上會(huì)跑出不一樣的效果，例如我在第三屆中間件性能挑戰(zhàn)賽中，就是用 2 連接跑出了最好的成績(jī)，并非單連接。

最后，你如果僅僅使用 Dubbo 去維系你們的微服務(wù)架構(gòu)，大部分情況不需要關(guān)注到連接控制這個(gè)特性，多花點(diǎn)時(shí)間搬磚吧，就醬，我也去搬磚了。