一起学RPC(七)

上一篇文章中说到要继续讨论关于“Registry”注册器的实现。然而我反悔了。注册器的实现涉及到了客户端程序，而客户端是属于consumer的部分。因此我决定将这个部分稍微放一放。这篇文章开始介绍“注册中心”的实现。

    public static void main(String[] args) {
        RegistryServer registryServer = RegistryServer.Default.createRegistryServer(20001, 1);
        MonitorServer monitor = new MonitorServer(19998);
        try {
            monitor.setRegistryMonitor(registryServer);
            monitor.start();
            registryServer.startRegistryServer();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

启动一个注册中心server很简单。注册中心中有一个监控“MonitorServer”，这个不仅仅在注册中心中有，在provider中也有。

public interface RegistryServer extends RegistryMonitor {
    void startRegistryServer();
}

public interface RegistryMonitor {

    /**
     * Returns the address list of publisher.
     */
    List listPublisherHosts();

    /**
     * Returns the address list of subscriber.
     */
    List listSubscriberAddresses();

    /**
     * Returns to the service of all the specified service provider's address.
     */
    List listAddressesByService(String group, String serviceProviderName, String version);

    /**
     * Finds the address(host, port) of the corresponding node and returns all
     * the service names it provides.
     */
    List listServicesByAddress(String host, int port);
}

注册中心抽象接口中只提供了一个操作--启动注册中心。其超级继承自Monitor，而这个Monitor提供的操作也很简单。默认的实现是由DefaultRegistryServer来完成的。这个实例的创建并不是显示的，而是使用反射方式去实例化。在某些情况下不想使用默认的注册中心而是使用别的如zk，如果jupiter-registry-default依赖包没有显示的添加进来，编译会直接报错的。这种思路在很多框架中都有体现。

注册中心的作用除了保存provider的一些信息外，还有一个重要的职责--监听注册信息的变化。当一个provider断线了，那么注册中心就得及时将这个provide发布的信息给清理掉（下线）并且告诉consumer：你订阅的服务不可用了。如果重连后，provider会重新发布服务信息，注册中心又得将这些变化告诉consumer：你订阅的服务又能使用了。对于consumer来说，当consumer断线了注册中心将consumer订阅的服务给清理掉，连接重建后又会自动订阅。

和provider一样，注册中心也是一个server。因此需要关心的核心逻辑其实就是handler的实现。

boot.childHandler(new ChannelInitializer() {
            @Override
            protected void initChannel(Channel ch) throws Exception {
                ch.pipeline().addLast(
                        new IdleStateChecker(timer, JConstants.READER_IDLE_TIME_SECONDS, 0, 0),
                        idleStateTrigger,
                        new MessageDecoder(),
                        encoder,
                        ackEncoder,
                        handler);
            }
        });

这里还多了一个ackEncoder编码器。

protected void encode(ChannelHandlerContext ctx, Acknowledge ack, ByteBuf out) throws Exception {
        out.writeShort(JProtocolHeader.MAGIC)
                .writeByte(JProtocolHeader.ACK)
                .writeByte(0)
                .writeLong(ack.sequence())
                .writeInt(0);
    }

从具体的实现逻辑中可以看出，这个编码器实际上仅仅只做了一件事：构造一个ack的消息包。

解码器的逻辑和之前provider的类似，只不过接收的消息格式类型不同。

protected void decode(ChannelHandlerContext ctx, ByteBuf in, List