参考
简介
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
-
rpc-server
- rpc服务器(RpcServer)的实现,用来监听rpc请求以及向Zookeeper注册服务地址
- rpc服务本地调用
-
rpc-sample-api
-
rpc-sample-client
-
rpc-sample-server
启动顺序
-
配置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框架
posted on 2017-02-13 21:41
landon 阅读(2663)
评论(0) 编辑 收藏 所属分类:
ServerFramework 、
NetWork