Apache Dubbo学习实战-Dubbo注册中心

Dubbo注册中心简单介绍

  在Dubbo微服务体系中，注册中心是其核心组件之一。Dubbo实现通过注册中心实现了分布式环境中各个服务之间的注册与发现，是各个分布式节点之间的纽带。其主要的作用如下：

• 动态加入。一个服务提供者通过注册中心可以动态的将自己的服务注册到注册中心暴露给其他消费者使用，不需要消费者逐个的去修改配置文件进行操作。

• 动态发现。与上面相反，一个消费者可以动态的感知新的配置、路由变化和新的服务提供者进行联系，不需要重新启动服务使其生效。

• 动态调整。注册中心支持参数的动态调整，新的参数会调整自动更新到各个相关的节点，包括服务消费者，服务提供者等。

• 统一配置。这种避免了因为服务太多，导致每个服务的配置不一致的问题。

  Dubbo注册中心源码在dubbo-registry中，包含了如下所示的五个子模块

  从dubbo-registry 的模块中可以看到，Dubbo主要包含了四种注册中心的实现，分别是ZooKeeper、Redis、Simple、Multicast。

  在其中Zookeeper作为官方推荐的注册中心，在生成实践中得到广泛的使用，具体的内容在dubbo-registry-zookeeper模块中。在阿里内部并没有使用Redis作为注册中心，Redis也没有得到有效的验证是否运行可靠，它的稳定性主要是依赖于Redis。Simple注册中心是一个简单的基于内存的注册中心实现，它本身就是一个标准的RPC服务，不支持集群部署，也会出现单点故障。Multicast模式则是不需要任何注册中心，只要通过广播地址，就可以相互发现。服务提供者启动的时候 ，会广播自己的地址。消费者启动的时候，会广播订阅请求，服务提供者收到订阅请求，会根据配置广播活单播给订阅者，这种方式不建议生产环境使用。

  Dubbo拥有良好的扩展性，如果以上的注册中心都不能满足需求，就可以基于RegistryFactory和Registry进行扩展。

Dubbo注册中心工作流程

  注册中心的总体流程比较简单，Dubbo官网也是有详细的说明，总体流程如图所示

• 服务提供者启动时，会向注册中心写入自己的元数据信息，同时会订阅配置元数据信息。
• 服务消费者启动时，会想注册中心写入自己的元数据信息，并订阅服务提供者、路由和配置元数据信息。
• 服务治理中心(dubbo-admin)启动的时候，会同时订阅所有消费者、服务提供者、路由和配置元信息。
• 当服务提供者离开或者有新的服务提供者加入的时候，注册中心服务提供者目录会发生变化，变化信息会动态通知给消费者、服务治理中心等。
• 当消费方发起服务调用的时候，会异步将调用、统计信息等上报给监控中心(dubbo-monitor-simple)

Dubbo注册中心Zookeeper原理

  Zookeeper是类似于Linux文件树结构，分为如下的四类节点

• 持久节点：服务注册后保证节点不会丢失，注册中心重启依然是存在的
• 持久顺序节点：在持久节点的基础上增加的节点的先后顺序的能力
• 临时节点：服务注册后连接丢失或者是Session超时，注册的节点会自动被移除
• 临时顺序节点：在临时节点的特性上增加了节点的先后顺序能力

  Dubbo使用Zookeeper作为注册中心的时候，会创建持久节点和临时节点两种，对创建的顺序并没有太大的要求，当然在有些业务场景中可以利用这个特性来实现一些内容。

  例如/dubbo/com.nihui.TestService/providers 是服务提供者在Zookeeper注册中心路径的示例。是一种树型的结构

+dubbo
+--service
     +-- providers
     +-- consumers
     +-- routers
     +-- configurators
复制代码

  树形结构关系：

• (1) 树的根节点是注册中心分组，下面有多个服务接口，分别来自用户配置中的dubbo:registry中的group属性，默认是/dubbo.
• (2) 服务接口下包含4类的子目录，分布式provicers、consumers、routers、configurators，这些路径是持久节点。
• (3) 服务提供者的目录providers，包含的接口是多个服务者的URL元数据信息。
• (4) 服务消费者的目录consumers，包含接口是多个消费者的URL元数据信息。
• (5) 路由配置目录routers，下面包含多哥消费路由策略的元数据信息。
• (6) 动态配置目录configurators，下面包含多个用于服务者动态配置URL的元数据信息。

  在Dubbo框架启动的时候，会根据用户配置的服务，在注册中心中创建4个目录，在providers和consumers目录中分别存储服务提供方、消费方元数据信息，包括IP、端口、权重和应用名等数据。

  在Dubbo框架进行服务调用的时候，用户可以通过服务治理平台dubbo-admin 下发路由配置。如果在运行时需要改变参数，则用户可以通过服务治理平台dubbo-admin下发动态配置。服务端会通过订阅机制收到属性变更，并且重新暴露已经修改的服务信息。如下图所示

  服务元数据中的所有参数都是以键值对的形式存储。以服务元数据为例

<beans>
    <!--适用于Zookeeper集群-->
    <dubbo:registry protocol="zookeeper" address="ip:port,ip:port"/>
    <dubbo:registry protocol="zookeeper" address="ip:port,ip:port"/>
</beans>
复制代码

Dubbo注册中心Redis原理概述

  Redis注册中心也沿用的是Dubbo抽象的Root、Service、Type、URL的数据结构。但是由于Redis属于NoSQL数据库，数据是以键值对的形式保存，并不是像Zookeeper一样直接实现树形存储，所以，Redis适用可Key/Map的结构实现需求，Root、Service、Type组合成了Redis的Key。Redis的value是一个Map结构，URL作为Map的Key，超时时间作为Map的value，如图所示。

  在数据结构分装过程中有关代码如下

String key = toCategoryPath(url)

String value = url.toFullString();

jedis.hset(key,value,expire);

复制代码

总结

  上面的内容中主要介绍了关于Dubbo注册中心相关的内容，包括Dubbo注册中心的原理以及两种注册中心实现的方案。通过上面的分享主要是帮助理解Dubbo注册中心的工作原理以及，两种注册中心的数据结构。