从零开始实现简单 RPC 框架 4：注册中心

RPC 中服务消费端(Consumer) 需要请求服务提供方(Provider)的接口，必须要知道 Provider 的地址才能请求到。
那么，Consumer 要从哪里获取 Provider 的地址呢？

能不能 Consumer 自己配置 Provider 的地址？
这种方式理论上是可行的，不过事实上没人这么做。这种方式有以下缺点：

1. Consumer 每引用一个接口，需要配置一次 Provider 的服务地址，配置繁琐易错。
2. Consumer 引用其他业务组的服务，需要跨团队沟通，沟通成本高。
3. Provider 如果换服务器、挂掉、新增，都需要通知到 Consumer 去修改服务地址，配置修改可能不及时造成服务异常。
4. Consumer 如果引用很多服务，那么配置会非常杂乱，管理起来非常麻烦。

从上面的缺点来看，最好的方式是找个地方把配置管理起来。
例如，把配置放到统一的数据库中，Provider 启动的时候，把自己的地址和接口写到表中; Consumer 在请求接口之前，就可以从表里获取该接口对应的Provider地址。
其实，这种把配置统一管理的地方，就叫 注册中心

注册中心就像中间桥梁，连接Provider和Consumer。三方关系示意图如下：

注册中心 只是 Provider 感知 Consumer 的一种方式而已，最终 Provider 调用 Consumer 接口还是以直连的方式进行。
Provider 注册或者取消注册，注册中心会通知 Consumer，保证 Consumer 感知服务状态的及时性。

注册中心的特性

一个合格的注册中心，需要有以下的特性：

1. 存储

可以简单地将注册中心理解为一个存储系统，存储着服务与服务提供方的映射表。一般注册中心对存储没有太多特别的要求，甚至夸张一点，你可以基于数据库来实现一个注册中心。

2. 高可用

注册中心一旦挂掉，Consumer 将无法获取 Provider 的地址，整个微服务将无法运转。
当然 Consumer 可以添加本地缓存，从某种角度上看，是允许注册中心短暂挂掉的。

3. 健康检查

Provider 向注册中心注册服务之后，注册中心需要定时向 Provider 发起健康检查，当 Provider 宕机的时候，注册中心能更快发现 ，从而将宕机的 Provider 从注册表中移除。
这特性数据库、Redis 都不具有，因此他们不适合做注册中心。

4. 监听状态

当服务增加、减少 Provider 的时候，注册中心除了能及时更新，还要能主动通知 Consumer，以便 Consumer 能快速更新本地缓存，减少错误请求的次数。
这一特性同样数据库、Redis都不具有。

目前主流的注册中心有：Zookeeper、Eureka、Nacos、Consul 等。
由于本文主要是讲注册中心的实现，就不详细讲各种注册中心的差异、优缺点了，有兴趣的同学可以看这里

下面我们来讲 ccx-rpc 的注册中心是如何实现的。

注册中心的设计与实现

接口定义

下面是注册中心的接口，最简单就包含两个方法：注册、查找。

public interface Registry {
   

    /**
     * 向注册中心注册服务
     *
     * @param url 注册者的信息
     */
    void register(URL url);

    /**
     * 查找注册的服务
     *
     * @param condition 查询条件
     * @return 符合查询条件的所有注册者
     */
    List<URL> lookup(URL condition);
}

本地缓存

为了减缓注册中心的压力，需要加上本地缓存，减少请求。同时也可以增加可用性，当注册中心挂的时候，本地还可以使用缓存中的数据。这部分逻辑否装在 AbstractRegistry 中，其他的实现都继承 AbstractRegistry。

变量 registered 将服务信息缓存在 Map 中，服务名为 Key，Value 则是该服务注册的 Provider 列表。

/**
* 已注册的服务的本地缓存。{serviceName: [URL]}
*/
privat