配置中心_关于配置中心、元数据中心和注册中心

有同学在设计一个分布式系统里的配置中心和注册中心，找我讨论是不是可以都按zk的getChildren方式设计接口。

以下是我的一些认识和想法。

一个分布式系统，整个集群里有很多个不同的节点，他们中有一些是具有同样作用的节点，也有一些跟其他的作用不同，这样其实有很多不同的角色。可能有计算节点、有存储节点、有控制节点（对于分布式数据相关系统），有服务提供者、服务消费者、服务治理节点（对于分布式服务相关系统）。

我们则需要通过合理的设计，把很多的信息数据在多个节点之间共享使用，同时需要让一些节点自己在运行时把各种状态之类的数据，传播给其他节点，用来作为控制和调整整个集群的依据。

配置中心、元数据中心、注册中心，是三个非常不同的需求。

1、配置中心里的是系统启动需要的参数和依赖的各类外部信息，比如spring boot里的配置项，一般情况都是。这种信息我们一般用key-value来存取，也可以做成是一个有层次结构的key-value。配置中心一般用来控制系统的启动，运行时的部分参数的调整，比如线程数之类的。这些数据的特点是，一般情况下变化不大，但是需要考虑不同环境(有时也叫组)的隔离性，就是说同时需要考虑存在很多套不同的配置，不同环境的系统通过这样的一个配置中心来去拉取自己的参数。这一块基本上常见的apollo、zk、etcd、nacos都支持的很好。

2、元数据中心，是关键的需要大家共享的数据模型实例，这些信息是系统运行起来后，能准确给拱业务能力的一个关键信息抽象。比如在dubbo之类的框架，就是如何能定义和描述一个具体的业务服务。在ss里，应该就是具体的一些db实例里的metadata信息。这些信息一般情况也是准静态的。nacos支持的很好，zk，etcd之类的也都可以。

3、注册中心，是动态数据，这些数据在开发情况是不存在的，通过一些实例的启动停止，而产生和变动。比如一个新节点加入到了系统，或者有一个新的client订阅了所有的服务变动，可以通过某个服务查找所有在线的实例。这一块除了前面说的zk、etc、nacos、etcd之外，还可以用redis、consul、eruka之类的技术实现。

具体到这三个接口设计，我觉得应该都是业务相关的，像zkclient的getChildren方法，只是一个具体实现的内部细节，不应该在接口层关心。接口层应该只有我们需要拉取回来一套配置，或者一类元数据，或者查找一批可以服务的实例，具体怎么获取和转换成这些信息，应该隐藏在每个不同的组建实现的内部。比如说zk和etcd里有树结构，可以把业务数据按原本的结构变成树，然后getChildren，然后监听节点；nacos可以直接用服务来组织结构和监听；redis可以set，然后用pubsub做监听；apollo可以直接按key来拉value值，然后监听可以用前缀匹配等等。

这些设计，都可以参与dubbo里的一些做法，个人觉得现在版本的设计比较合理。