learn-tech/专栏/Dubbo源码解读与实战-完/12简易版RPC框架实现（下）.md

                        因收到Google相关通知，网站将会择期关闭。相关通知内容
                        
                        
                        12  简易版 RPC 框架实现（下）
                        在上一课时中，我们介绍了整个简易 RPC 框架项目的结构和工作原理，并且介绍了简易 RPC 框架底层的协议结构、序列化/反序列化实现、压缩实现以及编解码器的具体实现。本课时我们将继续自底向上，介绍简易 RPC 框架的剩余部分实现。

transport 相关实现

正如前文介绍 Netty 线程模型的时候提到，我们不能在 Netty 的 I/O 线程中执行耗时的业务逻辑。在 Demo RPC 框架的 Server 端接收到请求时，首先会通过上面介绍的 DemoRpcDecoder 反序列化得到请求消息，之后我们会通过一个自定义的 ChannelHandler（DemoRpcServerHandler）将请求提交给业务线程池进行处理。

在 Demo RPC 框架的 Client 端接收到响应消息的时候，也是先通过 DemoRpcDecoder 反序列化得到响应消息，之后通过一个自定义的 ChannelHandler（DemoRpcClientHandler）将响应返回给上层业务。

DemoRpcServerHandler 和 DemoRpcClientHandler 都继承自 SimpleChannelInboundHandler，如下图所示：

DemoRpcClientHandler 和 DemoRpcServerHandler 的继承关系图

下面我们就来看一下这两个自定义的 ChannelHandler 实现：

public class DemoRpcServerHandler extends

  SimpleChannelInboundHandler<Message<Request>> {

// 业务线程池

static Executor executor = Executors.newCachedThreadPool();

protected void channelRead0(final ChannelHandlerContext ctx, 

      Message<Request> message) throws Exception {

    byte extraInfo = message.getHeader().getExtraInfo();

    if (Constants.isHeartBeat(extraInfo)) { // 心跳消息，直接返回即可

        channelHandlerContext.writeAndFlush(message);

        return;

    }

    // 非心跳消息，直接封装成Runnable提交到业务线程

    executor.execute(new InvokeRunnable(message, cxt));

}

}

public class DemoRpcClientHandler extends

  SimpleChannelInboundHandler<Message<Response>> {

protected void channelRead0(ChannelHandlerContext ctx, 

    Message<Response> message) throws Exception {

    NettyResponseFuture responseFuture = 

          Connection.IN_FLIGHT_REQUEST_MAP

              .remove(message.getHeader().getMessageId());

    Response response = message.getContent();

    // 心跳消息特殊处理

    if (response == null && Constants.isHeartBeat(

              message.getHeader().getExtraInfo())) {

        response = new Response();

        response.setCode(Constants.HEARTBEAT_CODE);

    }

    responseFuture.getPromise().setSuccess(response);

}

}

注意，这里有两个点需要特别说明一下。一个点是 Server 端的 InvokeRunnable，在这个 Runnable 任务中会根据请求的 serviceName、methodName 以及参数信息，调用相应的方法：

class InvokeRunnable implements Runnable {

private ChannelHandlerContext ctx;

private Message<Request> message;

public void run() {

    Response response = new Response();

    Object result = null;

    try {

        Request request = message.getContent();

        String serviceName = request.getServiceName();

        // 这里提供BeanManager对所有业务Bean进行管理，其底层在内存中维护了

        // 一个业务Bean实例的集合。感兴趣的同学可以尝试接入Spring等容器管

        // 理业务Bean

        Object bean = BeanManager.getBean(serviceName);

        // 下面通过反射调用Bean中的相应方法

        Method method = bean.getClass().getMethod(

            request.getMethodName(), request.getArgTypes());

        result = method.invoke(bean, request.getArgs());

    } catch (Exception e) { // 省略异常处理

    } finally {

    }

    response.setResult(result); // 设置响应结果

    // 将响应消息返回给客户端

    ctx.writeAndFlush(new Message(message.getHeader(), response));

}

}

另一个点是 Client 端的 Connection，它是用来暂存已发送出去但未得到响应的请求，这样，在响应返回时，就可以查找到相应的请求以及 Future，从而将响应结果返回给上层业务逻辑，具体实现如下：

public class Connection implements Closeable {

private static AtomicLong ID_GENERATOR = new AtomicLong(0);

public static Map<Long, NettyResponseFuture<Response>> 

    IN_FLIGHT_REQUEST_MAP = new ConcurrentHashMap<>();

private ChannelFuture future;

private AtomicBoolean isConnected = new AtomicBoolean();

public Connection(ChannelFuture future, boolean isConnected) {

    this.future = future;

    this.isConnected.set(isConnected);

}

public NettyResponseFuture<Response> request(Message<Request> message, long timeOut) {

    // 生成并设置消息ID

    long messageId = ID_GENERATOR.incrementAndGet();

    message.getHeader().setMessageId(messageId);

    // 创建消息关联的Future

    NettyResponseFuture responseFuture = new NettyResponseFuture(System.currentTimeMillis(),

            timeOut, message, future.channel(), new DefaultPromise(new DefaultEventLoop()));

    // 将消息ID和关联的Future记录到IN_FLIGHT_REQUEST_MAP集合中

    IN_FLIGHT_REQUEST_MAP.put(messageId, responseFuture);

    try {

        future.channel().writeAndFlush(message); // 发送请求

    } catch (Exception e) {

        // 发送请求异常时，删除对应的Future

        IN_FLIGHT_REQUEST_MAP.remove(messageId);

        throw e;

    }

    return responseFuture;

}

// 省略getter/setter以及close()方法

}

我们可以看到，Connection 中没有定时清理 IN_FLIGHT_REQUEST_MAP 集合的操作，在无法正常获取响应的时候，就会导致 IN_FLIGHT_REQUEST_MAP 不断膨胀，最终 OOM。你也可以添加一个时间轮定时器，定时清理过期的请求消息，这里我们就不再展开讲述了。

完成自定义 ChannelHandler 的编写之后，我们需要再定义两个类—— DemoRpcClient 和 DemoRpcServer，分别作为 Client 和 Server 的启动入口。DemoRpcClient 的实现如下：

public class DemoRpcClient implements Closeable {

protected Bootstrap clientBootstrap;

protected EventLoopGroup group;

private String host;

private int port;

public DemoRpcClient(String host, int port) throws Exception {

    this.host = host;

    this.port = port;

    clientBootstrap = new Bootstrap();

    // 创建并配置客户端Bootstrap

    group = NettyEventLoopFactory.eventLoopGroup(

        Constants.DEFAULT_IO_THREADS, "NettyClientWorker");

    clientBootstrap.group(group)

            .option(ChannelOption.TCP_NODELAY, true)

            .option(ChannelOption.SO_KEEPALIVE, true)

            .channel(NioSocketChannel.class)

            // 指定ChannelHandler的顺序

            .handler(new ChannelInitializer<SocketChannel>() {

                protected void initChannel(SocketChannel ch) {

                    ch.pipeline().addLast("demo-rpc-encoder", 

                        new DemoRpcEncoder());

                    ch.pipeline().addLast("demo-rpc-decoder", 

                        new DemoRpcDecoder());

                    ch.pipeline().addLast("client-handler", 

                        new DemoRpcClientHandler());

                }

            });

}

public ChannelFuture connect() { // 连接指定的地址和端口

    ChannelFuture connect = clientBootstrap.connect(host, port);

    connect.awaitUninterruptibly();

    return connect;

}

public void close() {

    group.shutdownGracefully();

}

}

通过 DemoRpcClient 的代码我们可以看到其 ChannelHandler 的执行顺序如下：

客户端 ChannelHandler 结构图

另外，在创建EventLoopGroup时并没有直接使用NioEventLoopGroup，而是在 NettyEventLoopFactory 中根据当前操作系统进行选择，对于 Linux 系统，会使用 EpollEventLoopGroup，其他系统则使用 NioEventLoopGroup。

接下来我们再看DemoRpcServer 的具体实现：

public class DemoRpcServer {

private EventLoopGroup bossGroup;

private EventLoopGroup workerGroup;

private ServerBootstrap serverBootstrap;

private Channel channel;

protected int port;

public DemoRpcServer(int port) throws InterruptedException {

    this.port = port;

    // 创建boss和worker两个EventLoopGroup，注意一些小细节， 

    // workerGroup 是按照中的线程数是按照 CPU 核数计算得到的，

    bossGroup = NettyEventLoopFactory.eventLoopGroup(1, "boos");

    workerGroup = NettyEventLoopFactory.eventLoopGroup( 

        Math.min(Runtime.getRuntime().availableProcessors() + 1,

             32), "worker");

    serverBootstrap = new ServerBootstrap().group(bossGroup, 

                workerGroup).channel(NioServerSocketChannel.class)

            .option(ChannelOption.SO_REUSEADDR, Boolean.TRUE)

            .childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE)

            .handler(new LoggingHandler(LogLevel.INFO))

            .childHandler(new ChannelInitializer<SocketChannel>()

              { // 指定每个Channel上注册的ChannelHandler以及顺序

                protected void initChannel(SocketChannel ch) {

                   ch.pipeline().addLast("demp-rpc-decoder", 

                        new DemoRpcDecoder());

                   ch.pipeline().addLast("demo-rpc-encoder", 

                        new DemoRpcEncoder());

                   ch.pipeline().addLast("server-handler", 

                        new DemoRpcServerHandler());

                 }

     });

}

public ChannelFuture start() throws InterruptedException {

    ChannelFuture channelFuture = serverBootstrap.bind(port);

    channel = channelFuture.channel();

    channel.closeFuture();

    return channelFuture;

}

}

通过对 DemoRpcServer 实现的分析，我们可以知道每个 Channel 上的 ChannelHandler 顺序如下：

服务端 ChannelHandler 结构图

registry 相关实现

介绍完客户端和服务端的通信之后，我们再来看简易 RPC 框架的另一个基础能力——服务注册与服务发现能力，对应 demo-rpc 项目源码中的 registry 包。

registry 包主要是依赖 Apache Curator 实现了一个简易版本的 ZooKeeper 客户端，并基于 ZooKeeper 实现了注册中心最基本的两个功能：Provider 注册以及 Consumer 订阅。

这里我们先定义一个 Registry 接口，其中提供了注册以及查询服务实例的方法，如下图所示：

ZooKeeperRegistry 是基于 curator-x-discovery 对 Registry 接口的实现类型，其中封装了之前课时介绍的 ServiceDiscovery，并在其上添加了 ServiceCache 缓存提高查询效率。ZooKeeperRegistry 的具体实现如下：

public class ZookeeperRegistry implements Registry {

private InstanceSerializer serializer = 

      new JsonInstanceSerializer<>(ServerInfo.class);

private ServiceDiscovery<T> serviceDiscovery;

private ServiceCache<T> serviceCache;

private String address = "localhost:2181";

public void start() throws Exception {

    String root = "/demo/rpc";

    // 初始化CuratorFramework

    CuratorFramework client = CuratorFrameworkFactory

        .newClient(address, new ExponentialBackoffRetry(1000, 3));

    client.start(); // 启动Curator客户端

    client.blockUntilConnected();  // 阻塞当前线程，等待连接成

    client.createContainers(root);

    // 初始化ServiceDiscovery

    serviceDiscovery = ServiceDiscoveryBuilder

            .builder(ServerInfo.class)

            .client(client).basePath(root)

            .serializer(serializer)

            .build();

    serviceDiscovery.start(); // 启动ServiceDiscovery

    // 创建ServiceCache，监Zookeeper相应节点的变化，也方便后续的读取

    serviceCache = serviceDiscovery.serviceCacheBuilder()

            .name(root)

            .build();

    serviceCache.start(); // 启动ServiceCache

}

@Override

public void registerService(ServiceInstance<T> service)

         throws Exception {

    serviceDiscovery.registerService(service);

}

@Override

public void unregisterService(ServiceInstance service) 

      throws Exception {

    serviceDiscovery.unregisterService(service);

}

@Override

public List<ServiceInstance<T>> queryForInstances(

        String name) throws Exception {

    // 直接根据name进行过滤ServiceCache中的缓存数据 

    return serviceCache.getInstances().stream()

        .filter(s -> s.getName().equals(name))

            .collect(Collectors.toList());

}

}

通过对 ZooKeeperRegistry的分析可以得知，它是基于 Curator 中的 ServiceDiscovery 组件与 ZooKeeper 进行交互的，并且对 Registry 接口的实现也是通过直接调用 ServiceDiscovery 的相关方法实现的。在查询时，直接读取 ServiceCache 中的缓存数据，ServiceCache 底层在本地维护了一个 ConcurrentHashMap 缓存，通过 PathChildrenCache 监听 ZooKeeper 中各个子节点的变化，同步更新本地缓存。这里我们简单看一下 ServiceCache 的核心实现：

public class ServiceCacheImpl implements ServiceCache,

PathChildrenCacheListener{//实现PathChildrenCacheListener接口

// 关联的ServiceDiscovery实例

private final ServiceDiscoveryImpl<T>  discovery;

// 底层的PathChildrenCache，用于监听子节点的变化

private final PathChildrenCache cache; 

// 本地缓存

private final ConcurrentMap<String, ServiceInstance<T>> instances 

  = Maps.newConcurrentMap();

public List<ServiceInstance<T>> getInstances(){ // 返回本地缓存内容

    return Lists.newArrayList(instances.values());

}

public void childEvent(CuratorFramework client, 

      PathChildrenCacheEvent event) throws Exception{

    switch(event.getType()){

        case CHILD_ADDED:

        case CHILD_UPDATED:{

            addInstance(event.getData(), false); // 更新本地缓存

            notifyListeners = true;

            break;

        }

        case CHILD_REMOVED:{ // 更新本地缓存

            instances.remove(instanceIdFromData(event.getData()));

            notifyListeners = true;

            break;

        }

    }

    ... // 通知ServiceCache上注册的监听器

}

}

proxy 相关实现

在简易版 Demo RPC 框架中，Proxy 主要是为 Client 端创建一个代理，帮助客户端程序屏蔽底层的网络操作以及与注册中心之间的交互。

简易版 Demo RPC 使用 JDK 动态代理的方式生成代理，这里需要编写一个 InvocationHandler 接口的实现，即下面的 DemoRpcProxy。其中有两个核心方法：一个是 newInstance() 方法，用于生成代理对象；另一个是 invoke() 方法，当调用目标对象的时候，会执行 invoke() 方法中的代理逻辑。

下面是 DemoRpcProxy 的具体实现：

public class DemoRpcProxy implements InvocationHandler {

// 需要代理的服务(接口)名称

private String serviceName;

// 用于与Zookeeper交互，其中自带缓存

private Registry<ServerInfo> registry;

public DemoRpcProxy(String serviceName, Registry<ServerInfo> 

        registry) throws Exception { // 初始化上述两个字段

    this.serviceName = serviceName;

    this.registry = registry;

}

public static <T> T newInstance(Class<T> clazz, 

    Registry<ServerInfo> registry) throws Exception {

    // 创建代理对象

    return (T) Proxy.newProxyInstance(Thread.currentThread()

        .getContextClassLoader(), new Class[]{clazz},

            new DemoRpcProxy(clazz.getName(), registry));

}

@Override

public Object invoke(Object proxy, Method method, Object[] args)

       throws Throwable {

    // 从Zookeeper缓存中获取可用的Server地址,并随机从中选择一个

    List<ServiceInstance<ServerInfo>> serviceInstances = 

          registry.queryForInstances(serviceName);

    ServiceInstance<ServerInfo> serviceInstance = serviceInstances

        .get(ThreadLocalRandom.current()

            .nextInt(serviceInstances.size()));

    // 创建请求消息，然后调用remoteCall()方法请求上面选定的Server端

    String methodName = method.getName();

    Header header =new Header(MAGIC, VERSION_1...);

    Message<Request> message = new Message(header, 

        new Request(serviceName, methodName, args));

    return remoteCall(serviceInstance.getPayload(), message);

}

protected Object remoteCall(ServerInfo serverInfo, 

        Message message) throws Exception {

    if (serverInfo == null) {

        throw new RuntimeException("get available server error");

    }

    // 创建DemoRpcClient连接指定的Server端

    DemoRpcClient demoRpcClient = new DemoRpcClient(

          serverInfo.getHost(), serverInfo.getPort());

    ChannelFuture channelFuture = demoRpcClient.connect()

          .awaitUninterruptibly();

    // 创建对应的Connection对象，并发送请求

    Connection connection = new Connection(channelFuture, true);

    NettyResponseFuture responseFuture =

         connection.request(message, Constants.DEFAULT_TIMEOUT);

    // 等待请求对应的响应

    return responseFuture.getPromise().get(

        Constants.DEFAULT_TIMEOUT, TimeUnit.MILLISECONDS);

}

}

从 DemoRpcProxy 的实现中我们可以看到，它依赖了 ServiceInstanceCache 获取ZooKeeper 中注册的 Server 端地址，同时依赖了 DemoRpcClient 与Server 端进行通信，上层调用方拿到这个代理对象后，就可以像调用本地方法一样进行调用，而不再关心底层网络通信和服务发现的细节。当然，这个简易版 DemoRpcProxy 的实现还有很多可以优化的地方，例如：

缓存 DemoRpcClient 客户端对象以及相应的 Connection 对象，不必每次进行创建。 可以添加失败重试机制，在请求出现超时的时候，进行重试。 可以添加更加复杂和灵活的负载均衡机制，例如，根据 Hash 值散列进行负载均衡、根据节点 load 情况进行负载均衡等。

你若感兴趣的话可以尝试进行扩展，以实现一个更加完善的代理层。

使用方接入

介绍完 Demo RPC 的核心实现之后，下面我们讲解下Demo RPC 框架的使用方式。这里涉及Consumer、DemoServiceImp、Provider三个类以及 DemoService 业务接口。

使用接入的相关类

首先，我们定义DemoService 接口作为业务 Server 接口，具体定义如下：

public interface DemoService {

String sayHello(String param);

}

DemoServiceImpl对 DemoService 接口的实现也非常简单，如下所示，将参数做简单修改后返回：

public class DemoServiceImpl implements DemoService {

public String sayHello(String param) {

    return "hello:" + param;

}

}

了解完相应的业务接口和实现之后，我们再来看Provider的实现，它的角色类似于 Dubbo 中的 Provider，其会创建 DemoServiceImpl 这个业务 Bean 并将自身的地址信息暴露出去，如下所示：

public class Provider {

public static void main(String[] args) throws Exception {

    // 创建DemoServiceImpl，并注册到BeanManager中

    BeanManager.registerBean("demoService", 

            new DemoServiceImpl());

    // 创建ZookeeperRegistry，并将Provider的地址信息封装成ServerInfo

    // 对象注册到Zookeeper

    ZookeeperRegistry<ServerInfo> discovery = 

            new ZookeeperRegistry<>();

    discovery.start();

    ServerInfo serverInfo = new ServerInfo("127.0.0.1", 20880);

    discovery.registerService(

         ServiceInstance.<ServerInfo>builder().name("demoService")

            .payload(serverInfo).build());

    // 启动DemoRpcServer，等待Client的请求

    DemoRpcServer rpcServer = new DemoRpcServer(20880);

    rpcServer.start();

}

}

最后是Consumer，它类似于 Dubbo 中的 Consumer，其会订阅 Provider 地址信息，然后根据这些信息选择一个 Provider 建立连接，发送请求并得到响应，这些过程在 Proxy 中都予以了封装，那Consumer 的实现就很简单了，可参考如下示例代码：

public class Consumer {

public static void main(String[] args) throws Exception {

    // 创建ZookeeperRegistr对象

    ZookeeperRegistry<ServerInfo> discovery = new ZookeeperRegistry<>();

    // 创建代理对象，通过代理调用远端Server

    DemoService demoService = DemoRpcProxy.newInstance(DemoService.class, discovery);

    // 调用sayHello()方法，并输出结果

    String result = demoService.sayHello("hello");

    System.out.println(result);

}

}

总结

本课时我们首先介绍了简易 RPC 框架中的transport 包，它在上一课时介绍的编解码器基础之上，实现了服务端和客户端的通信能力。之后讲解了registry 包如何实现与 ZooKeeper 的交互，完善了简易 RPC 框架的服务注册与服务发现的能力。接下来又分析了proxy 包的实现，其中通过 JDK 动态代理的方式，帮接入方屏蔽了底层网络通信的复杂性。最后，我们编写了一个简单的 DemoService 业务接口，以及相应的 Provider 和 Consumer 接入简易 RPC 框架。

在本课时最后，留给你一个小问题：在 transport 中创建 EventLoopGroup 的时候，为什么针对 Linux 系统使用的 EventLoopGroup会有所不同呢？期待你的留言。

简易版 RPC 框架 Demo 的链接：https://github.com/xxxlxy2008/demo-prc 。