浅析Dubbo核心设计

大家好，我是易安！

当今互联网时代，随着企业业务的不断扩展和用户量的增加，分布式系统已成为大型企业必不可少的组成部分。而Dubbo框架作为阿里巴巴开源的高性能Java RPC框架，一直以来都备受关注和使用。其核心设计思想和架构特点，对于分布式系统的开发和运维具有重要的参考价值。今天我将深入探讨Dubbo框架的核心设计，来帮助你更好地理解分布式系统架构和设计思想。本文主要分为服务注册与动态发现、服务调用、网络通信模型、高度灵活的扩展机制和泛化调用五个部分。

服务注册与动态发现

我们首先来看一下Dubbo的服务注册与动态发现机制。

Dubbo的服务注册与发现机制如下图所示：

Dubbo中主要包括四类角色，它们分别是注册中心（Registry）、服务调用者&消费端（Consumer）、服务提供者（Provider）和监控中心（Monitor）。

在实现服务注册与发现时，有三个要点。

服务提供者(Provider)在启动的时候在注册中心(Register)注册服务，注册中心(Registry)会存储服务提供者的相关信息。
服务调用者(Consumer)在启动的时候向注册中心订阅指定服务，注册中心将以某种机制（推或拉）告知消费端服务提供者列表。
当服务提供者数量变化（服务提供者扩容、缩容、宕机等因素）时，注册中心需要以某种方式(推或拉)告知消费端，以便消费端进行正常的负载均衡。

Dubbo官方提供了多种注册中心，我们选择使用最为普遍的ZooKeeper进一步理解注册中心的原理。

我们先来看一下Zookeeper注册中心中的数据存储目录结构。

可以看到，它的目录组织结构为 /dubbo/{ServiceName}，其中，ServiceName表示一个具体的服务，通常用包名+类名表示，在每一个服务名下又会创建四个目录，它们分别是：

providers，服务提供者列表；
consumers，消费者列表；
routers，路由规则列表（一个服务可以设置多个路由规则）；
configurators，动态配置条目。

在Dubbo中，我们可以在不重启消费者、服务提供者的前提下动态修改服务提供者、服务消费者的配置，配置信息发生变化后会存储在configurators子节点中。此时，服务提供者、消费者会动态监听配置信息的变化，变化一旦发生就使用最新的配置重构服务提供者和服务消费者。

基于Zookeeper注册中心的服务注册与发现有下面三个实现细节。

服务提供者启动时会向注册中心进行注册，具体是在对应服务的providers目录下增加一条记录（临时节点），记录服务提供者的IP、端口等信息。同时服务提供者会监听configurators节点的变化。
服务消费者在启动时会向注册中心订阅服务，具体是在对应服务的consumers目录下增加一条记录（临时节点），记录消费者的IP、端口等信息，同时监听 configurators、routers 目录的变化，所谓的监听就是利用ZooKeeper提供的watch机制。
当有新的服务提供者上线后， providers 目录会增加一条记录，注册中心会将最新的服务提供者列表推送给服务调用方（消费端），这样消费者可以立刻收到通知，知道服务提供者的列表产生了变化。如果一个服务提供者宕机，因为它是临时节点，所以ZooKeeper会把这个节点移除，同样会触发事件，消费端一样能得知最新的服务提供者列表，从而实现路由的动态注册与发现。

服务调用

接下来我们再来看看服务调用。Dubbo的服务调用设计十分优雅，其实现原理图如下：

服务调用重点阐述的是客户端发起一个RPC服务调用时的所有实现细节， 它包括服务发现、故障转移、路由转发、负载均衡等方面，是Dubbo实现灰度发布、多环境隔离的理论指导。

刚才，我们已经就服务发现做了详细介绍，接下来我们重点关注负载均衡、路由、故障转移这几个方面。

客户端通过服务发现机制，能动态发现当前存活的服务提供者列表，接下来要考虑的就是如何从服务提供者列表中选择一个服务提供者发起调用，这就是所谓的 负载均衡（LoadBalance）。

Dubbo默认提供了随机、加权随机、最少活跃连接、一致性Hash等负载均衡算法。

值得注意的是，Dubbo不仅提供了负载均衡机制，还提供了智能路由机制，这是实现Dubbo灰度发布的重要理论基础。

所谓路由机制，是指设置一定的规则对服务提供者列表进行过滤。负载均衡时，只在经过了路由机制的服务提供者列表中进行选择。为了更好地理解路由机制的工作原理，你可以看看下面这张示意图：

我们为查找用户信息服务设置了一条路由规则，即“查询机构ID为102的查询用户请求信息将被发送到新版本（192.168.3.102）上。具体的做法是，在进行负载均衡之前先执行路由选择，按照路由规则对原始的服务提供者列表进行过滤，从中挑选出符合要求的提供者列表，然后再进行负载均衡。

接下来，客户端就要向服务提供者发起RPC请求调用了。远程服务调用通常涉及到网络等因素，因此并不能保证100%成功，当调用失败时应该采用什么策略呢？

Dubbo提供了下面五种策略：

failover，失败后选择另外一台服务提供者进行重试，重试次数可配置，通常适合实现幂等服务的场景；
failfast，快速失败，失败后立即返回错误；
failsafe，调用失败后打印错误日志，返回成功，通常用于记录审计日志等场景；
failback，调用失败后，返回成功，但会在后台定时无限次重试，重启后不再重试；
forking，并发调用，收到第一个响应结果后返回给客户端。通常适合实时性要求比较高的场景。但这一策略浪费服务器资源，通常可以通过forks参数设置并发调用度。

如果将服务调用落到底层，就不得不说说网络通信模型了，这部分包含了很多 性能调优手段。

网络通信模型

来看看Dubbo的网络通信模型，如下图所示：

Dubbo的网络通信模型主要包括 网络通信协议和线程派发机制（Dispatcher） 两部分。

网络传输通常需要自定义通信协议，我们常用的协议设计方式是 Header + Body,其中Header 长度固定，包含一个长度字段，用于记录整个协议包的大小。

同时，为了提高传输效率，我们一般会对传输数据也就是Body的内容进行序列化与压缩处理。

Dubbo支持目前支持 java、compactedjava、nativejava、fastjson、fst、hessian2、kryo等序列化协议，生产环境默认为hessian2。

网络通信模型的另一部分是线程派发机制。Dubbo中会默认创建200个线程处理业务，这时候就需要线程派发机制来指导IO线程与业务线程如何分工。

Dubbo提供了下面几种线程派发机制：

all，所有的请求转发到业务线程池中执行（IO读写、心跳包除外，因为在Dubbo中这两种请求都必须在IO线程中执行，不能通过配置修改）；
message，只有请求事件在线程池中执行，其他请求在IO线程上执行；
connection ，求事件在线程池中执行， 连接和断开连接的事件排队执行（含一个线程的线程池）；
direct，所有请求直接在IO线程中执行。

为什么线程派发机制有这么多种策略呢？其实这主要是考虑到线程切换带来的开销问题。也就是说，我们希望通过多种策略让线程切换带来的开销小于多线程处理带来的提升。

我举个例子，Dubbo中的心跳包都必须在IO线程中执行。在处理心跳包时，我们只需直接返回PONG包（OK）就可以了，逻辑非常简单，处理速度也很快。如果将心跳包转换到业务线程池，性能不升反降，因为切换线程会带来额外的性能损耗，得不偿失。

网络编程中需要遵循一条最佳实践： IO线程中不能有阻塞操作，通常将阻塞操作转发到业务线程池异步执行。

与网络通信协议相关的参数定义在dubbo:protocol，关键的设置属性如下。

threads，业务线程池线程个数，默认为200。
queues，业务线程池队列长度，默认为0，表示不支持排队，如果线程池满，则直接拒绝。该参数与threads配合使用，主要是对服务端进行限流，一旦超过其处理能力，就拒绝请求，快速失败，引导客户端重试。
iothreads：默认为CPU核数再加一，用于处理网络读写。在生产实践中，通常的瓶颈在于业务线程池，如果业务线程无明显瓶颈（jstack日志查询到业务线程基本没怎么干活），但吞吐量已经无法继续提升了，可以考虑调整iothreads，增加IO线程数量，提高IO读写并发度。该值建议保持在“2*CPU核数”以下。
serialization：序列化协议，新版本支持protobuf等高性能序列化机制。
dispatcher：线程派发机制，默认为all。

高度灵活的扩展机制

Dubbo出现之后迅速成为微服务领域最受欢迎的框架，除操作简单这个原因外，还有扩展机制的功劳。Dubbo高度灵活的扩展机制堪称“王者级别的设计”。

Dubbo的扩展设计主要是基于SPI设计理念，我们来看下具体的实现方案。

Dubbo所有的底层能力都通过接口来定义。用户在扩展时只需要实现对应的接口，定义一个统一的扩展目录（META-INF.dubbo.internal）存放所有的扩展定义即可。要注意的是，目录下的文件名是需要扩展的接口的全名，像下图这样：

在初次使用对应接口实例时，可以扫描扩展目录中的文件，并根据文件中存储的key-value初始化具体的实例。

我们以RPC模块为例看一下Dubbo强悍的扩展能力。众所周知，目前gRPC协议以优异的性能表现正在逐步成为RPC领域的王者，很多人误以为gRPC是来革Dubbo的“命”的。其实不然，我们可以认为Dubbo是微服务体系的完整解决方案，而RPC只是微服务体系中的重要一环，Dubbo完全可以吸收gRPC，让gRPC成为Dubbo的远程调用方式。

具体的做法只需要在dubbo-rpc模块中添加一个dubbo-rpc-grpc模块，然后使用gRPC实现org.apache.dubbo.rpc.protocol接口，并将其配置在扩展目录中：

面对gRPC这么强大的功能扩展机制，绝大部分人应该和我一样，都是作为中间件的应用人员，不需要使用模块级别的扩展机制。我们通常只是结合应用场景来进行功能扩展。

Dubbo在业务功能级别的扩展可以通过Filter机制来实现。Filter的工作机制如下：

这里， 过滤器链的执行时机是在服务消费者发起远程RPC请求之前。 最先执行的是消费端的过滤器链，每一个过滤器可以设置执行顺序。 服务端在解码之后、执行业务逻辑之前，也会首先调用过滤器链。

泛化调用

下面我们介绍一下Dubbo的泛化调用机制，它也是实现Dubbo网关的理论基础。

我们在开发Dubbo应用时通常会包含API、Consumer、Provider三个子模块。

其中API模块通常定义统一的服务接口，而Consumer、Provider模块都需要显示依赖API模块。这种设计理念虽然将Provider与Consumer进行了解耦合，但对API模块形成了强依赖，如果API模块发生改变，Provider和Consumer必须同时改变。也就是说，一旦API模块发生变化，服务调用方、服务消费方都需要重新部署，这对应用发布来说非常不友好。特别是在网关领域，几乎是不可接受的，如下图所示：

公司的微服务在不停地演进，如果网关需要跟着API模块不停地发布新版本，网关的可用性和稳定性都将受到极大挑战。怎么解决这个问题呢？

这就要说到Dubbo的机制了。泛化调用具体实现原理如下：

当服务消费端发生调用时，我们使用Map来存储一个具体的请求参数对象，然后传输到服务提供方。由于服务提供方引入了模型相关的Jar，服务提供方在执行业务方法之前，需要将Map转化成具体的模型对象，然后再执行业务逻辑。

Dubbo的泛化调用在服务提供方的转化是通过Filter机制统一处理的，服务端并不需要关注消费方采取何种方式进行调用。

通过泛化调用机制，客户端不再需要依赖服务端的Jar包，服务端可以不断地演变，而不会影响客户端已有服务的运行。

小结

本文主要介绍了Dubbo的服务注册与发现、服务调用、网络通信模型、扩展机制还有泛化调用等核心工作机制

本文由 mdnice 多平台发布