dubbo provider异步_一文了解Dubbo框架的通信方式

导读：Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，,致力于提供高性能和透明化的远程服务调用方案。本文将主要讨论Dubbo框架中提供者、消费者、注册中心等之间是如何进行通信的。

1、Dubbo架构概述

• Consumer 服务消费者
• Provider 服务提供者
• Registry 注册中心
• Monitor 监控中心

解析：图中Register，Provider 和 Consumer三者之间默认是通过长连接来通信的。Provider和Consumer在启动后将各自信息注册到Registry注册中心里(注册中心不做转发请求)，之后Consumer从Registry获取Provider服务提供者地址列表，并根据LB(负载均衡)算法直接调用提供者。下面将进行详细讨论。

2、Dubbo协议

2.1 概念

通信协议：可以理解为两个网络实体间完成通信所必须遵循的规则。要使两个实体间能协同工作实现信息交换，它们之间必须具有共同的语言。必须遵循某种互相都能接受的规则。这个规则就是通信协议。

Dubbo框架支持dubbo、http、webservice、redis等多种协议，但是官方是推荐使用Dubbo协议。

2.2 Dubbo协议的特点

• 采用单一长连接
• NIO 异步通信

解析：Dubbo框架中默认和推荐使用该通信协议，所以在框架中Provider、Consumer 、Registry 三者间默认通过单一长连接方式通信。通过使用NIO异步通信，高效处理了多个消费者们同时对同一个提供者发起调用时的场景(传输层默认使用Netty，Netty是一个高性能、异步事件驱动的NIO框架。推荐感兴趣的朋友可以去深入了解，本文这里不做深入讨论)。

2.3Dubbo协议适用场景：

• 适合于小数据量大并发的服务调用
• 服务消费者机器数远大于服务提供者机器数的情况
• 传入和传出数据包很小(建议小于100K)，尽量不要使用Dubbo协议传输大文件或大字符串。

3、注册服务器

3.1概念

Dubbo框架支持多种注册表，如Dubbo注册表(不需要设置任何中央节点，采用广播-订阅方式)、Zookeeper注册表(推荐生产环境使用，稳定)、Redis注册表等。

注册表主要作用：提供Consumer和Provider将各自服务的URL地址注册到其中，并提供给Consumer订阅和获取Provider的URL地址用于调用服务。在这期间注册中心不做请求转发，而是作为一个中间记录表使用。下面我们通过zookeeper注册中心来展开讨论。

3.2 Zookeeper注册中心

Zookeeper由于它提供了类似树的目录服务并支持更改通知，所以它适合用作Dubbo的注册中心，而且这是一个经过多次现场验证的产品，因此建议在生产环境中使用。

下面通过一个官网Demo进行解析：

1. 当提供者Provider启动时会在目录/dubbo/com.foo.barservice/providers下写入其服务URL地
2. 当消费者Consumer启动时会订阅/dubbo/com.foo.barservice/providers以获取提供者的URL地址。同时，在/dubbo/com.foo.barservice/consumers下写入其的URL地址。
3. 当监控中心Monitor 启动时会订阅/dubbo/com.foo.barservice以获取来自所有提供商和消费者的URL地址。
4. 当Consumer通过负载均衡算法获取到Provider的URL的地址后，会根据Dubb协议采用单一的长连接方式与提供者进行直接的通信(也可以使用其他的(自定义)的通讯方式)

4.总结

Dubbo内部间消费者、提供者、注册中心都默认遵守Dubbo协议(可自由配置，官方推荐Dubbo协议)采用单一长连接方式进行通信。消费者和提供者在启动时将URL地址写入到注册中心(可自由选择，推荐Zookeeper)，消费者从注册中心获取提供者服务列表，并遵守负载均衡算法直接调用(注册中心不做转发)提供者。

感谢您的阅读，如果喜欢本文欢迎关注和转发，本头条号将持续分享IT技术知识。对于文章内容有其他想法或意见建议等，欢迎提出共同讨论共同进步。