dubbo解析-服务自省架构原理图

本文基于dubbo 2.7.5版本代码

前面通过五篇文章
《dubbo解析-详解配置中心》、
《dubbo解析-详解元数据中心MetadataReport》、
《dubbo解析-基于服务自省的ServiceDiscovery原理》、
《Apache Dubbo 云原生服务自省架构设计》、
《dubbo解析-详解MetadataService》
详细介绍了dubbo云原生服务自省架构的各个组件，本文将详细介绍这些组件如何配合完成服务自省。
架构图如下：

服务端：

1. 服务端发布全部应用服务；
2. 将全部应用服务的元数据发布到内存中（存储在对象InMemoryWritableMetadataService）；
3. 将dubbo的应用名发布到配置中心的“/dobbo/config/mapping/接口名/应用名”目录下（配置中心以zk为例，下同）；
4. 将InMemoryWritableMetadataService对象发布为MetadataService服务，服务协议是dubbo；
5. 将代表dubbo实例的ServiceInstance对象发布到注册中心的“/services/应用名/ServiceInstance的id属性值”目录下，ServiceInstance对象存储的数据有ip、应用名、MetadataService服务端口等；

消费端：

6. 消费端根据引用服务的接口名从配置中心查找合适的应用名；
7. 访问注册中心，找到应用名对应的ServiceInstance对象，从而得到MetadataService服务的连接地址，然后建立对注册中心的监听，当注册中心发生变化或者新增减少dubbo实例时，可重新执行下面第八和第九步；
8. 访问服务端的MetadataService服务，得到服务端发布的所有服务元数据；
9. 根据服务元数据建立与服务端的连接，后续直接进行服务调用。

从代码上来看，服务自省的实现与文章《Apache Dubbo 云原生服务自省架构设计》有些细节不一致，可能dubbo的后续版本会继续改造优化，最后实现可能会与设计保持一致，让我们期待后续的版本更新吧。

服务自省架构设计优点

1. 在之前的dubbo版本中，注册中心保存了所有的服务端和消费端的数据，一旦数据发生变化，注册中心便通知服务端和消费端，当服务比较少时候，缺点不明显，但是服务过多的时候，会造成注册中心一直忙于通知服务端和消费端数据发生了变化，而且通知还可能会延时比较长，在服务自省架构中，注册中心仅仅保存dubbo实例信息，一个dubbo实例也就是一个dubbo进程，dubbo实例信息相对比较固定，不经常变化，这样注册中心存储数据大大减少，也降低了注册中心通知的次数；
2. 消费端通过MetadataService服务获取服务元数据，这样做可以将获取服务信息的压力分散到各个服务端，避免了对注册中心的依赖；
3. 获取提供服务的应用名既可以从配置中心获取也可以通过参数指定，对需要访问指定应用的场景提供了便利；
4. 传统的服务发现是以服务为粒度，服务端将服务发布到注册中心，消费端从注册中心查找合适的服务。服务自省架构中，服务发现是以应用为粒度，消费端首先找到合适的dubbo应用，之后访问dubbo应用获取所有的服务，修改为应用为粒度也是为了降低注册中心压力；
5. 应用服务元数据保存在本地内存，而不是注册中心或者元数据中心，而且消费端对于同一个dubbo应用只访问一次MetadataService服务，这样减少了网络数据量，降低网络压力；
6. 使用以应用为粒度的服务发现，可以与spring cloud等其他应用交互。