一个入门rpc框架的学习

一个入门rpc框架的学习

参考

• huangyong-rpc
• 轻量级分布式RPC框架
• 该程序是一个短连接的rpc实现

简介

RPC，即 Remote Procedure Call（远程过程调用），说得通俗一点就是：调用远程计算机上的服务，就像调用本地服务一样。
RPC 可基于 HTTP 或 TCP 协议，Web Service 就是基于 HTTP 协议的 RPC，
它具有良好的跨平台性，但其性能却不如基于 TCP 协议的 RPC。会两方面会直接影响 RPC 的性能，一是传输方式，二是序列化。
众所周知，TCP 是传输层协议，HTTP 是应用层协议，而传输层较应用层更加底层，
在数据传输方面，越底层越快，因此，在一般情况下，TCP 一定比 HTTP 快。
就序列化而言，Java 提供了默认的序列化方式，但在高并发的情况下，
这种方式将会带来一些性能上的瓶颈，于是市面上出现了一系列优秀的序列化框架，比如：Protobuf、Kryo、Hessian、Jackson 等，
它们可以取代 Java 默认的序列化，
从而提供更高效的性能。
为了支持高并发，传统的阻塞式 IO 显然不太合适，因此我们需要异步的 IO，即 NIO。
Java 提供了 NIO 的解决方案，Java 7 也提供了更优秀的 NIO.2 支持，用 Java 实现 NIO 并不是遥不可及的事情，只是需要我们熟悉 NIO 的技术细节。
我们需要将服务部署在分布式环境下的不同节点上，通过服务注册的方式，
让客户端来自动发现当前可用的服务，并调用这些服务。
这需要一种服务注册表（Service Registry）的组件，让它来注册分布式环境下所有的服务地址（包括：主机名与端口号）。

---

应用、服务、服务注册表之间的关系见下图：

---

---

每台 Server 上可发布多个 Service，这些 Service 共用一个 host 与 port，
在分布式环境下会提供 Server 共同对外提供 Service。此外，为防止 Service Registry 出现单点故障，因此需要将其搭建为集群环境。
本文将为您揭晓开发轻量级分布式 RPC 框架的具体过程，
该框架基于 TCP 协议，提供了 NIO 特性，提供高效的序列化方式，同时也具备服务注册与发现的能力。
根据以上技术需求，我们可使用如下技术选型：
Spring：它是最强大的依赖注入框架，也是业界的权威标准。
Netty：它使 NIO 编程更加容易，屏蔽了 Java 底层的 NIO 细节。
Protostuff：它基于 Protobuf 序列化框架，面向 POJO，无需编写 .proto 文件。
ZooKeeper：提供服务注册与发现功能，开发分布式系统的必备选择，同时它也具备天生的集群能力。

源代码目录结构

• rpc-client
  • 实现了rpc的服务动态代理(RpcProxy)以及基于Netty封装的一个客户端网络层(RpcClient)
• rpc-common
  • 封装了RpcRequest和RpcResponse，即rpc请求和响应的数据结构
  • 基于Netty提供了编解码器
  • 提供了序列化反序列化等工具
• rpc-registry
  • 提供了服务发现和注册接口
• rpc-registry-zookeeper
  • 基于zookeeper的服务发现和注册接口
• rpc-server
  • rpc服务器(RpcServer)的实现，用来监听rpc请求以及向Zookeeper注册服务地址
  • rpc服务本地调用
• rpc-sample-api
  • rpc测试公共api服务接口
• rpc-sample-client
  • rpc测试客户端
• rpc-sample-server
  • rpc测试服务启动程序和服务实现

启动顺序

• 配置Zookeeper
  • 解压zookeeper-3.4.9
  • 进入conf目录，重命名zoo_sample.cfg为zoo.cfg（或者复制一份重命名）并修改一些配置选项如dataDir.另外可以看到默认的clientPort是2181
  • 将bin目录加入环境变量PATH，这样则可直接使用zkServer命令直接启动
• 启动rpc-sample-server工程的下RpcBootstrap
• 启动rpc-sample-client工程下的测试程序HelloClient等

关键实现和核心模块分析

• RpcBootstrap
  • 加载spring.xml实例化RpcServer
    • 两个参数分别是rpc服务地址(127.0.0.1:8000)和基于ZooKeeper的服务注册接口实现(使用ZkClient连接Zookeeper的2181端口)
  • 加载过程中，会首先调用setApplicationContext方法
    • 扫描com.xxx.rpc.sample.server下带有@RpcService注解的类,本例是HelloServiceImpl和HelloServiceImpl2,即有两个rpc服务类，其中HelloServiceImpl2加了一个版本号用来区分第一个服务类，扫描后放入handlerMap，即服务名和服务对象之间的映射map
  • 加载后，调用afterPropertiesSet方法
    • 启动Netty服务端，监听8000端口;channelpipeline增加编解码器(RpcDecoder、RpcEncoder)和逻辑处理类(RpcServerHandler)
      • RpcEncoder,编码器，消息格式为4个字节的消息长度和消息体;直接使用Protostuff进行序列化,编码对象为RpcResponse
      • RpcDecoder,解码器;已解决粘包问题;使用Objenesis和Protostuff继续反序列化
      • RpcServerHandler,收到RpcRequest后直接从handlerMap找到对应的服务类反射进行方法调用(使用了CGLib);最后向客户端写入rpc响应，完毕则主动关闭连接（所以从这里看是短连接）
        • ctx.writeAndFlush(response).addListener(ChannelFutureListener.CLOSE)
          • 这行代码相当于在rpc响应发送的这个操作完成之后关闭连接
        • 注意Netty强烈建议直接通过添加监听器的方式获取I/O操作结果;当I/O操作完成之后，I/O线程会回调ChannelFuture中GenericFutureListener#operationComplete方法
    • 绑定端口成功后，向Zookeeper注册上面的两个rpc服务

---

ChannelFutureListener CLOSE = new ChannelFutureListener() {
                @Override
                public void operationComplete(ChannelFuture future) {
                    future.channel().close();
                }
};

---

• RpcProxy
  • 初始化亦通过加载spring.xml，指定了基于zookeeper的服务发现类ZooKeeperServiceDiscovery
  • create方法，主要使用了jdk的动态代理;当代理方法执行的时候，首先根据请求的服务名利用Zookeeper的服务发现接口获取服务的address;然后封装rpc请求调用Netty客户端连接服务地址并发送
    • 关于RpcClient，同Netty服务端，需要设置channelpipeline的编解码器和逻辑处理handler
    • Channel channel = future.channel();
      channel.writeAndFlush(request).sync();
      channel.closeFuture().sync();
      return response;
    • 注意上部分代码，发送rpc请求后等待发送完毕；发送完毕后等待连接关闭，此时线程阻塞直到服务端发送完回复消息并主动关闭连接，线程继续；所以这个例子并没有会有request对不上reponse的问题，因为每次rpc调用都是短连接且当前执行线程挂起；另外服务端收到request的时候，也会用requestId作为response的requestId

可改进地方

• 本人觉得spring相对较厚重，所以将spring去掉，对象实例化和依赖注入用比较简单的方式去处理；不过比较麻烦的是对于扫描@RpcService注解这部分需要手动处理
• 目前该示例提供的两个服务均是在同一个端口8000下的服务；如何测试不同的两个服务在不同的端口？按照该例子的设计，一个RpcServer即一个rpc发布服务器，该监听的端口下可以注册不同很多服务（当然一个Netty server本身可以bind多个端口,这个暂时不考虑实现）；如果需要增加不同的服务，则需要单独启动RpcServer并向Zookeeper注册

其他待调研rpc框架

• 阿里dubbo
• 微博motan
• 当当dubbox
• 谷歌grpc
• 脸书thrift

 

转自：http://www.blogjava.net/landon/archive/2017/02/13/432304.html