1、Dubbo 是一种使用长连接的RPC框架。在Dubbo中，客户端与服务端之间建立的是长连接，这意味着一旦连接建立，它会被保持活跃状态以供多次请求和响应使用，减少了频繁建立和断开连接的开销，提升了通信效率。Dubbo还实现了连接池机制，以便更高效地复用这些长连接。
2、dubbo默认是使用单一长连接，即消费者与每个服务提供者建立一个单一长连接，即如果有消费者soa-user1，soa-user2,提供者soa-account三台，则每台消费者user都会与3台account建立一个连接，结果是每台消费者user有3个长连接到分别到3台提供者，每台提供者account维持到soa-user1和soa-user2的2个长连接。
3、既然在dubbo中描述消费者和提供者之间采用的是单一长连接，那么如果消费者端是高并发多线程模型的web应用，单一长连接如何解决多线程并发请求问题呢？
- dubbo的Client、Channel、Handler都使用了装饰器模式，真正工作的是传入的对象，外层对象是对传入的对象的工作进行了一定的装饰或增强。
- Client包裹着Channel（NettyChannel，这个NettyChannel中也包括传入的Client的引用）和传入的真正的Client，如NettyClient和MinaClient。这里以NettyClient为例，NettyClient中包裹着netty原生的channel，这个channel是长连接的那个channel，也是最终真正工作的那个。
- consumer端多线程的请求进入Client后会先调用request方法，非阻塞地返回DefaultFuture对象，然后从future对象中获取响应结果，获取结果的方式有两种，一种是通过get方法阻塞获取，还有一种是通过传入回调方法，在响应的时候进行回调。
- DefaultFuture中维护着Map CHANNELS和Map FUTURES，这两个static map都以requestId作为key，其中每个response中也维护着和它对应的request相同的id，在响应时是通过这个id来寻找client端返回的那个DefaultFuture然后进行响应信息的获取。
- 这个相当于用DefaultFuture中的两个静态map维护着等待响应的请求信息，然后一个长连接作为worker来处理(在handler中进行)，每有一个响应过来，静态map中对应的kv被移除，get方法阻塞的部分被唤醒。这样就完成了一个长连接，多个并发请求都能正常工作的效果。
4、Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及 服务消费者机器数远大于服务提供者机器数的情况。 反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很 低。
dubbo源码之单一长连接与客户端多线程并发请求是如何协调的-腾讯云开发者社区-腾讯云 (tencent.com)
Dubbo协议异步单一长连接原理与优势-阿里云开发者社区 (aliyun.com)
dubbo 长连接-腾讯云开发者社区-腾讯云 (tencent.com)
Dubbo并发控制和连接控制_dubbo最大并发数-CSDN博客
dubbo协议下的单一长连接与多线程并发如何协同工作-阿里云开发者社区 (aliyun.com)