Apache Dubbo 云原生服务自省架构设计

本文基于dubbo 2.7.5版本代码

作者简介：小马哥@mercyblitz，Apache Dubbo PMC，Spring Cloud Alibaba项目架构师，《SpringBoot编程思想》作者。目前主要负责阿里巴巴集团中间件开源项目、微服务技术实施、架构衍进、基础设施构建等。GitHub主页：https://github.com/mercyblitz/

小马哥发表了文章《Apache Dubbo 云原生服务自省架构设计》：
https://mp.weixin.qq.com/s/ksFV4hV7BiG9dHKQLVeEdQ
这篇文章详细介绍了dubbo关于服务自省的设计与思考，文章首先指出了dubbo目前的问题：

• 如何解决或缓解注册中心压力过载；
• 如何支持以应用为粒度的服务注册与发现；
• 如何精简 Dubbo URL 元数据。

针对上述问题，dubbo参考了spring cloud和Kubernetes 服务注册与发现模型，同时还要确保传统和新的 Dubbo 服务注册与发现模型之间能够相互发现，提出了一个全新的架构模型，该架构模型包含以下子模型：

• 服务注册与发现架构
• 元数据服务架构
• 事件驱动架构

之后文章详细分析了上述前两种子架构。

注册与发现架构

针对服务注册与发现架构，dubbo提出了如下架构模型：

该模型主要是注册中心和配置源，传统的注册中心注册的是服务提供者的URL，每一个服务提供者都会注册一个URL，新的架构下，注册不再是URL，而是服务实例，一个服务实例代表一个 Provider 或 Consumer Dubbo 应用进程。服务实例属性包括：

• 服务名（Service Name）：该名称必须在注册中心全局唯一；
  注：名称规则架构上不做约束，不过不同注册中心的规则存在差异。
• 主机地址（Host/IP）：能够被解析的主机名或者 TCP IP 地址；
• 服务端口（Port）：应用进程所暴露的 Dubbo 协议端口，如 Dubbo 默认端口 20880；
  注：如果应用进程暴露多个 Dubbo 协议端口，如 dubbo 和 rest，那么，服务端口随机挑选其一，架构上不强制检验端口是否可用。
• 元数据（Metadata）：服务实例的附加信息，用于存储 Dubbo 元信息，类似于通讯协议头或附件；
• 激活状态（Enabled）：用于标记当前实例是否对外提供服务。

注册中心仅仅是实例信息，每个实例发布了哪些服务则配置在配置源中。在2.7.6版本之前，配置源的角色由配置中心承担，本地配置功能还未就绪。配置中心中的结构如下图：

上图中group 存储 Dubbo 服务 ID，而 key 则关联对应的 Dubbo Service 名称，表示一个dubbo实例，value是服务的发布时间。通过查询组，可以获得所有的Dubbo Service 实例。

元数据服务架构

dubbo新增了MetadataService服务，在服务端启动时候，会以dubbo协议的形式发布MetadataService服务，MetadataService中包含一个实例发布的所有服务信息。MetadataService服务依赖于服务注册与发现架构。
因为MetadataService服务也是一种服务，所以dubbo将MetadataService服务发布到注册中心和配置中心，客户端可以获取到服务信息，之后订阅MetadataService服务。
通过两种架构的结合使用，客户端首先从配置中心找到MetadataService服务，然后在注册中心找到实例列表，之后访问各个实例，订阅MetadataService服务，通过MetadataService服务获取该实例上发布的所有服务信息。

通过这样的全新架构，dubbo将原来注册中心的压力分解到了各个dubbo实例上，配置中心和注册中心原则上只提供用于发现MetadataService服务。
对于文章开头提到的事件驱动架构，文章中也有提到，但是只做了很简单的描述，我理解事件驱动不应该作为一种架构，而应该是为了满足前面两种架构而增加的一种功能，类似于事件通知，比如服务端的服务下线了触发了一个事件，客户端和服务端针对该事件作出一些响应。
我在dubbo专栏写的文章也是基于dubbo2.7.5版本的，上面的这些架构源码实现原理，我会在后续文章中介绍。