0x00. 翻车现场

那是个月黑风高的夜晚，小黑哥成功将新版本发布到了生产，小心翼翼检查了应用日志，后续测试小姐姐验收成功。

恩，小黑哥我还是一如既往的稳~

接着小黑哥就跑到楼下食堂吃个夜宵，谁知正吃到一半，线上运维同学发来几条告警信息，服务器连接数过多警告，连接数已经飙升到上万。

天啦撸，赶紧放下正在啃的鸡腿，火速跑到工位上查看问题。

0x01. 历尽艰辛，深入排查

打开电脑，首先确认生产交易一切还正常。查看这段时间日志，发现并没有什么异常情况，日志都是正常输出。没办法只好再次走查此次改动的代码，发现全是业务代码，并没有任何与网络连接有关的代码改动。

问题真的请奇怪，一时半会想不到解决方案，只好先实施重启大法。重启过后，连接数下降了，到达了正常阈值。但是不一会连接数持续升高，不一会还是升到上万。

这下重启解决不了办法，只好从应用出发，找找到底什么问题。

这个应用是一个路由服务，会根据上游系统指定路由编码，将交易分发到下游子系统。架构图如下:

之前在这篇文章路由系统演化史讲过，路由系统使用 Dubbo API ，代码如下：

由于我们还有另外一套系统，也部署这个应用，但是该系统生产机器连接数却很少。交叉比对了两套系统应用的系统配置值，只有 connections 设置不一样，当前有问题的系统设置为 1000，另外一个系统为 10 。

大致找到原因，也将 connections 设置为 10，重启应用，生产机器连接数恢复正常。

0x02. 抽丝剥茧，还原经过

首先我们来看下 connections 这个配置的作用，可以直接查看官方文档http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-reference.html。

下面配置来源于：dubbo:reference

总共可以在三个地方配置 connections 参数，分别为：dubbo:reference，dubbo:consumer，dubbo:provider。

注意：图中标示地方实际上与源码存在出入。截止 Dubbo 2.7.3 版本，图中 ① 处，dubbo:consumer 文档上显示为 100，实际源码默认配置为 0，这点需要注意。另外 ② 处文字描述存在问题，目前 connections 参数主要对 dubbo 协议有用，http 短连接协议还未使用该配置

其中 reference.connections 为服务级别的配置，若未配置将会使用 consumer.connections 配置值。另外这个参数若在 provider.connections 配置，其对服务提供者无效，参数将通过注册中心传递给消费者成为其默认配置。三者实际作用顺序如下：

Debug 源码，connections 最终会在 DubboProtocol#getClients 被使用，方法源码如下：

Dubbo 协议默认将会使用 **Netty **与服务提供者建立长连接

首先将会获取 connections 配置，规则如上图，若其大于 0，建立 connections 数量的长连接。

如果一个提供者对外暴露 10 个接口，且其有两个节点。消费者端引入提供者所有服务，配置 connections=1000。当消费者启动之后，将会立刻创建 1000x2x10=20000 连接。这就是生产机器连接数飙升的根本原因。

路由服务使用 Dubbo API 编程，服务启动成功之后，只有上游系统调用路由服务时， Dubbo 才会与与下游服务提供者建立连接，所以现象看起来服务连接数是慢慢激增。

如果未设置 connections 参数，Dubbo 将会创建共享连接（shareconnections）。消费者调用的服务若为同一个服务提供者（IP+PORT 区分），这些服务接口将会共享这些连接。

shareconnections 可以在 dubbo:consumer 配置中配置，也可以在启动 JVM 参数加入如下配置：

1-Dshareconnections=10

如果消费者需要调用同个服务提供者应用的 10 个服务接口，服务提供者提供两个节点，shareconnections=1000，消费者服务启动之后，仅会创建 1000*2=2000 连接。

这么对比，shareconnections与connections建立连接不是一个量级。

2.1 使用连接

消费者调用服务时，将会随机从连接数组中取一个连接使用，代码位于 DubboInvoker#doInvoke。

2.2 如何正确配置连接数

首先我们来看下单一长连接性能，文档地址:http://dubbo.apache.org/zh-cn/docs/user/references/protocol/dubbo.html

对于只有少数消费者场景，我们可以使用默认配置，即不配置 connections 参数 。若调用同一个提供者服务过多，可以考虑适当多配增加 shareconnections。最后若某一服务接口调用量特别大，可以考虑为这个服务单独配置 connections。

0x03. 举一反三，聊聊其他配置

Dubbo 还有很多配置项，下面着重介绍一些配置参数。

3.1 dubbo.provider.executes

该参数用来控制每个方法最大并行数。如果该值设置为 10 ，每个服务方法若已有 10 个请求正在处理，第 11 个服务请求将会抛出异常，直到之前服务调用完成，正在请求数量小于 10 未知。

一旦设置 executes>0,Dubbo 将会通过 SPI 机制启用 ExecuteLimitFilter，源码还是比较简单。

3.2 dubbo.reference.actives

这个参数将会控制消费者每个服务每个方法最大并发数。可以通过 dubbo:method.actives 单独为服务方法设置。如果该值为 10，一旦某个服务某个方法并发数超过 10，第 11 个服务将会等待，若在超时时间内其他请求执行结束，计数值减值小于阈值，第 11 个请求将会被执行，否者将会抛错。

dubbo.provider 上也可以配置这个值，其将会与 connections 一样，将会传递给消费者。

原理等同上面方法，将会启用 ActiveLimitFilter，源码如下 ：

这里需要注意 actives 引起超时与服务端超时区别。

3.3 dubbo.protocol.accepts

服务提供者最大连接数，如果设置 accepts=10,一旦服务提供者连接数大于 10，其余新增连接将会被拒绝。

方法源码如下：

服务提供者断开连接，消费端将会打印连接断开日志。另外消费者会定时检查长连接可用性，若不可用，将会重新发起连接。所以在消费者端就会看到连接断开，重连，然后又被服务提供者断开的现象。

0x04. 总结

本文通过一次生产连接数过多的现象，详细剖析定位问题的原因。作为一个合格的开发，对于开源框架，我们不仅要会熟练使用，也要了解其底层实现，相关参数设置。一旦参数设置不合理就可能引发生产事故。

另外对于生产系统，监控系统非常重要。比如上面的问题，如果没有监控发现，小黑哥可能一时半会都不知道有这个问题存在，毕竟平时也不会太关注连接数这个指标。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼如有收获，点个在看，诚挚感谢