前言
ASP站长网刚发现微信公众号有了标签功能，于是乎，我将我 Dubbo 相关的文章都打上了标签，仔细一统计，这已经是我第 41 篇原创的 Dubbo 文章了，如果你希望看到我其他的 Dubbo 文章，可以从话题标签点击进入。
 
这是一篇很久之前就想动笔写的文章，最近正好看到群里有小伙伴分享了 Dubbo 连接相关的文章，才又让我想起了这个话题。今天想跟大家聊的便是 Dubbo 中的连接控制这一话题。说到“连接控制”，可能有读者还没反应过来，但你对下面的配置可能不会感到陌生：
 
<dubbo:reference interface="com.foo.BarService" connections="10" />
 
如果你还不了解 Dubbo 中连接控制的用法，可以参考官方文档：https://dubbo.apache.org/zh/docs/advanced/config-connections/ ，话说最近 Dubbo 官方文档来了一次大换血，好多熟悉的文档差点都没找到在哪儿 Orz。
 
众所周知，dubbo 协议通信默认是长连接，连接配置功能用于决定消费者与提供者建立的长连接数。但官方文档只给出了该功能的使用方法，却并没有说明什么时候应该配置连接控制，本文将主要围绕该话题进行探讨。
 
本文也会涉及长连接相关的一些知识点。
 
##使用方式
 
先来看一个 Dubbo 构建的简单 demo，启动一个消费者(192.168.4.226)和一个提供者(192.168.4.224)，配置他们的直连。
 
消费者：
 
<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"/>
 
 
长连接是看不见摸不着的东西，我们需要一个观测性工作来”看到“它。启动提供者和消费者之后，可以使用如下的命令查看 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)
消费者：
 
[root@ ~]# netstat -ano | grep 20880
tcp6     320    720 192.168.4.226:59110     192.168.4.224:20880      ESTABLISHED on (0.00/0/0)
通过上述观察到的现象我们可以发现几个事实。
 
仅仅是启动了提供者和消费者，上述的 TCP 连接就已经了存在，要知道我并没有触发调用。也就是说，Dubbo 建连的默认策略是在地址发现时，而不是在调用时。当然，你也可以通过延迟加载 lazy="true" 来修改这一行为，这样可以将建联延迟到调用时。
 
<dubbo:reference id="userService" check="false"
    interface="org.apache.dubbo.benchmark.service.UserService"
    url="dubbo://${server.host}:${server.port}"
    lazy="true"/>
除此之外，还可以发现消费者和提供者之间只有一条长连接，20880 是 Dubbo 提供者默认开放的端口，就跟 tomcat 默认开放的 8080 一个地位，而 59110 是消费者随机生成的一个端口。(我之前跟一些朋友交流过，发现很多人不知道消费者也是需要占用一个端口的)
 
而今天的主角”连接控制“便可以控制长连接的数量，例如我们可以进行如下的配置
 
<dubbo:reference id="userService" check="false"
    interface="org.apache.dubbo.benchmark.service.UserService"
    url="dubbo://192.168.4.224:20880"
    connections="2" />
再启动一次消费者，观察长连接情况
 
提供者：
 
[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)
消费者：
 
[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)
可以看到，这里已经变成了两条长连接了。
 
什么时候需要配置多条长连接
现在我们知道了如何进行连接控制，但什么时候我们应该配置多少条长连接呢?这个时候我可以跟你说，具体视生产情况而定，但你如果你经常看我的公众号，肯定会知道这不是我的风格，我的风格是什么?benchmark!
 
写作之前，我跟几个同事和网友对这个话题进行了简单的讨论，其实也没有什么定论，无非是对单连接和多连接吞吐量高低不同的论调。参考既往 Dubbo github 中的 issue，例如：https://github.com/apache/dubbo/pull/2457，我也参与了这个 pr 的讨论，讲道理，我是持怀疑态度的，我当时的观点是多连接不一定能够提升服务的吞吐量(还是挺保守的，没有这么绝对)。
 
那接下来，还是用 benchmark 来说话吧，测试工程还是我们的老朋友，使用 Dubbo 官方提供的 dubbo-benchmark 工程。
 
测试工程地址：https://github.com/apache/dubbo-benchmark.git
测试环境：2 台阿里云 Linux 4c8g ECS
测试工程在之前的文章介绍过，这里就不过多赘述了，测试方案也非常简单，两轮 benchmark，分别测试 connections=1 和 connections=2 时，观察测试方法的吞吐量。
 
说干就干，省略一堆测试步骤，直接给出测试结果。
 
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
从测试结果来看，似乎单连接和多连接的差距是非常大的，近乎可以看做是 2 倍了!看起来连接控制的效果真是好呀，那么事实真的如此吗?