注册中心概述:
Dubbo通过注册中心实现了分布式环境的服务注册和发现,是分布式节点的纽带，主要作用如下:
1.动态加入，一个服务提供者通过注册中心可以动态地把自己暴露给其他消费者,无需消费者逐个去更新配置文件。
2.动态发现，一个消费者可以动态的感知新的配置、路由规则和新的服务提供者.无需重启服务使之生效
3.动态调整,注册中心支持参数的动态调整，新参数自动更新到所有服务相关节点。
4.统一配置，避免了本地配置导致每个服务的配置不一致问题。
官方推荐使用zookeeper，阿里内部没有使用过redis作为注册中心,故没有长时间运行的可靠验证.
工作流程:
服务提供者启动的时候,会向注册中心写入自己的元数据信息,同时会订阅配置元数据的信息.
消费者启动的也会想注册中心写入自己的元数据信息，并订阅服务提供者，路由和配置元数据
服务治理中心(dubbo-admin)启动时，会同时订阅所有消费者和路由以及配置元数据的信息。
当服务提供者离开或者新的服务加入的时候，注册中心服务提供者的信息会发生变化，变化信息会动态通知消费者、服务治理中心
服务消费者服务调用的时候会异步将调用统计等上报给监控中心。
原理概述:
可以在这里看到所有的都是在dubbo层级下的dubbo跟节点下面是当前所拥有的接口名称，如果有多个接口，则会以多个子节点的形式展开
每个服务下面又分别有四个配置项
consumers: 当前服务下面所有的消费者列表(URL)
providers:当前服务下面所有的提供者列表(URL)
configuration:当前服务下面的配置信息信息，provider或者consumer会通过读取这里的配置信息来获取配置
routers: 当消费者在进行获取提供者的时，会通过这里配置好的路由来进行适配匹配规则。
可以看到，dubbo基本上很多时候都是通过URL的形式来进行交互获取数据的，在URL中也会保存
很多的信息。
提供者会在 providers目录下进行自身的服务注册。
消费者会在consumers 目录下进行自身注册，并且监听 provider 目录，以此通过监听提供者增加或者减少，实现服务发现。
Monitor模块会对整个服务级别做监听，用来得知整体的服务情况。以此就能更多的对整体情况做监控。
服务注册流程分析:
首先 ServiceConfig 类拿到对外提供服务的实际类 ref(如:HelloServiceImpl),然后通过ProxyFactory 接口实现类中的 getInvoker 方法使用 ref 生成一个 AbstractProxyInvoker 实例，到这一步就完成具体服务到 Invoker 的转化。接下来就是 Invoker 转换到 Exporter 的过程。
、、、
public interface RegistryService {
/**
*进行对URL的注册操作，比如provider，consumer，routers等
*/
void register(URL url);
/**
*解除对指定URL的注册，比如provider，consumer，routers等
*/
void unregister(URL url);
/**
*增加对指定URL的路径监听，当有变化的时候进行通知操作
*/
void subscribe(URL url, NotifyListener listener);
/**
*解除对指定URL的路径监听，取消指定的listener
*/
void unsubscribe(URL url, NotifyListener listener);
/**
*查询指定URL下面的URL列表，比如查询指定服务下面的consumer列表
*/
List<URL> lookup(URL url);
}
