dubbo服务连接管理分析

1.概述

dubbo是高性能的rpc框架，而选型时，通常会认为其适用的场景是高qps、小包请求，这种说法的基本逻辑是 dubbo是共用连接的，如果单个请求过慢 或者 包体过大，会造成连接资源竞争，进而导致性能下降。 那如果已经用了dubbo，而确实请求的包体较大（例如我这里的500k），那么具体会有什么影响呢？

本文从这个角度去分析dubbo在连接管理相关的逻辑。

2. dubbo创建连接的几个场景

Dubbo 的连接可以分为以下几类：

• 注册中心连接：服务提供者和消费者与注册中心之间建立的连接，用于服务的注册和发现。注册中心负责维护服务提供者和消费者之间的关系，以及服务的元数据信息。

• 服务提供者连接：服务提供者与消费者之间建立的连接，用于服务的调用和响应。服务提供者负责暴露服务接口，并处理消费者的请求。

• 服务消费者连接：服务消费者与服务提供者之间建立的连接，用于发送请求并接收响应。消费者负责调用服务提供者暴露的接口，并处理返回的结果。

• 直连连接：服务提供者和消费者直接建立的连接，而不通过注册中心。这种连接方式适用于一些特殊情况，比如在同一局域网内部部署服务，可以直接指定服务提供者的 IP 地址和端口进行通信。

3. 详解调用方法用的连接

3.1 共享连接模式

默认情况下dubbo服务之间是共享连接的，即 在consumer和provider之间的所有reference和service是共享的同一个连接

共享连接是url维度的连接，关键代码 com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol#getSharedClient

3.2 独立连接池配置

如果希望不同的service使用独立的连接池，则可通过 connections参数配置，其配置方式如下：

消费者：

<dubbo:reference protocol="dubbo" id="demoApi" version="${dubbo.service.version}"
    interface="com.wlm.demoApi" check="false" timeout="2000" connections="5" />

生产者：

<dubbo:service version="${dubbo.service.version}" interface="com.wlm.demoApi"
    ref="demoApi" protocol="dubbo" timeout="5000" connections="5" />
<bean id="demoApi" class="com.wlm.demoApi"/>

4.其它相关信息

4.1 referenceBean的初始化入口

每个配置的 <dubbo:reference.> 都会对应着一个com.alibaba.dubbo.config.spring.ReferenceBean

每一个ReferenceBean的解析都会解析为一个 invoker ，每个 invoker 都独立进行连接管理，参考com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol#refer

4.2 DubboInvoker 调用方法

com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker#doInvoke