《RPC手撸专栏》第23章：服务消费者整合注册中心实现服务发现

作者：冰河
星球：http://m6z.cn/6aeFbs (opens new window)
博客：https://binghe.gitcode.host (opens new window)
文章汇总：https://binghe.gitcode.host/md/all/all.html (opens new window)

沉淀，成长，突破，帮助他人，成就自我。

大家好，我是冰河~~

我们写的RPC框架不仅实现了服务消费者与服务提供者之间正常的数据交互，也实现了注册中心的基础服务功能，同时，服务提供者也正常整合了注册中心的功能，整体上越来越完善了。

一、前言

服务提供者都整合了注册中心，服务消费者怎么能落下呢？

在前面的章节中，我们实现了注册中心的基础服务功能，也对这些基础服务功能进行了测试，能够正常向Zookeeper中注册和移除对应的元数据服务。在服务提供者端也整合了注册中心的基础功能，当服务提供者启动时，就会将自身标注有@RpcService注解的服务注册到注册中心。

既然服务提供者都整合了注册中心，那服务消费者又怎么能落下呢？在前面的章节中，我们在RPC框架的服务消费者中，都是将服务消费者要连接的服务提供者监听的IP和端口写死在了bhrpc-consumer-common工程下的io.binghe.rpc.consumer.common.RpcConsumer类中的sendRequest()方法中，源码如下所示。

@Override
public RPCFuture sendRequest(RpcProtocol<RpcRequest> protocol) throws Exception {
    //TODO 暂时写死，后续在引入注册中心时，从注册中心获取
    String serviceAddress = "127.0.0.1";
    int port = 27880;
    //#############省略其他代码#################
    return handler.sendRequest(protocol, request.getAsync(), request.getOneway());
}

通过这章之后，我们不再在服务消费者中写死任何服务监听的IP地址或端口号，通过订阅注册中心的服务来自动感知服务提供者发布的服务所监听的IP地址和端口号。

说干就干，我们开始吧。

二、目标

目前相当明确：就是将注册中心的基础服务功能整合到服务消费者，实现服务发现功能！

目前，我们一起手写的RPC框架，在服务提供者端实现了不依赖任何第三方框架的包扫描功能，能够将标注有@RpcService的注解注册到本地Map中。在服务消费者端能够实现通过直接调用接口的方法来实现远程方法调用，服务消费者整合动态代理后支持同步调用和异步调用两种方式。

同时，实现了服务注册中心的基础服务功能，并且将注册中心的基础服务功能整合到了服务提供者，实现了服务注册功能。当启动服务提供者时，服务提供者会使用自定义扫描器来扫描标注有@RpcService注解的类，并解析@RpcService注解，根据解析出的信息构建服务元数据，将服务元数据注册到注册中心，从而实现服务注册的功能。

本章，我们就一起实现将注册中心的基础服务功能整合到服务消费者，进而实现服务发现功能。

三、设计

如果让你设计如何整合服务消费者与注册中心，你会怎么设计呢？

服务消费者整合注册中心实现服务发现的整体流程如图23-1所示。

由图23-1可以看出如下信息：

（1）服务提供者会通过自定义类扫描器整合注册中心，将服务注册到注册中心。

（2）服务注册到注册中心的元数据，例如服务的名称、服务的版本号、服务地址、服务端口和服务分组等信息，元数据会贯穿整个服务的注册与发现流程。

（3）服务注册与发现接口对外提供服务注册与发现的方法，服务提供者通过自定义扫描器会调用服务注册与发现接口的方法实现服务注册功能。

（4）基于服务注册与发现的接口，服务提供者会实现多个服务注册与发现的实现类，每个实现类对应着一种注册中心服务。

（5）服务消费者会通过服务注册与发现接口订阅注册中心的服务，会从注册中心获取到服务提供者发布的服务信息，实现服务发现的功能。

（7）服务消费者从注册中心获取到服务提供者发布的服务信息后，会直接与服务提供者建立连接，实现数据交互。也就是说，后续服务消费者会与服务提供者直接实现数据交互。

四、实现

说了这么多，具体要怎么实现呢？

核心类实现关系

服务消费者整合注册中心实现服务发现的核心类关系如图23-2所示。

查看完整文章

加入冰河技术 (opens new window)知识星球，解锁完整技术文章与完整代码