RPC框架原理及对比

由于各服务部署在不同机器,服务间的调用免不了网络通信过程,服务消费方每调用一个服务都要写一坨网络通信相关的代码,不仅复杂而且极易出错。
RPC能让我们像调用本地服务一样调用远程服务,而让调用者对网络通信这些细节透明,大大提高生产力,在各大互联网公司中被广泛使用,如阿里巴巴的hsf、dubbo(开源)、Facebook的thrift(开源)、Google grpc(开源)、Twitter的finagle(开源)等。
RPC框架原理及对比_第1张图片
要让网络通信细节对使用者透明,需要对通信细节进行封装,一个RPC调用的流程涉及到的通信细节:
1)服务消费方(client)调用以本地调用方式调用服务;
2)client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;
3)client stub找到服务地址,并将消息发送到服务端;
4)server stub收到消息后进行解码;
5)server stub根据解码结果调用本地的服务;
6)本地服务执行并将结果返回给server stub;
7)server stub将返回结果打包成消息并发送至消费方;
8)client stub接收到消息,并进行解码;
9)服务消费方得到最终结果。
RPC的目标就是要2~8这些步骤都封装起来,让用户对这些细节透明。
对消息进行编码和解码:确定消息数据结构。
客户端的请求消息结构一般需要包括以下内容:
1)接口名称
2)方法名
3)参数类型&参数值
4)超时时间
5)requestID,标识唯一请求id。
为什么要有requestID?
1)client线程每次通过socket调用一次远程接口前,生成一个唯一的ID,即requestID(requestID必需保证在一个Socket连接里面是唯一的),一般常常使用AtomicLong从0开始累计数字生成唯一ID;
2)将处理结果的回调对象callback,存放到全局ConcurrentHashMap里面put(requestID, callback);
3)当线程调用channel.writeAndFlush()发送消息后,紧接着执行callback的get()方法试图获取远程返回的结果。在get()内部,则使用synchronized获取回调对象callback的锁,再先检测是否已经获取到结果,如果没有,然后调用callback的wait()方法,释放callback上的锁,让当前线程处于等待状态。
4)服务端接收到请求并处理后,将response结果(此结果中包含了前面的requestID)发送给客户端,客户端socket连接上专门监听消息的线程收到消息,分析结果,取到requestID,再从前面的ConcurrentHashMap里面get(requestID),从而找到callback对象,再用synchronized获取callback上的锁,将方法调用结果设置到callback对象里,再调用callback.notifyAll()唤醒前面处于等待状态的线程。
服务端返回的消息结构一般包括以下内容:
1) 返回值
2) 状态code
3) requestID
序列化
现如今序列化的方案越来越多,每种序列化方案都有优点和缺点,它们在设计之初有自己独特的应用场景,那到底选择哪种呢?
从RPC的角度上看,主要看三点:
1)通用性,比如是否能支持Map等复杂的数据结构;
2)性能,包括时间复杂度和空间复杂度,由于RPC框架将会被公司几乎所有服务使用,如果序列化上能节约一点时间,对整个公司的收益都将非常可观,同理如果序列化上能节约一点内存,网络带宽也能省下不少;
3)可扩展性,对互联网公司而言,业务变化飞快,如果序列化协议具有良好的可扩展性,支持自动增加新的业务字段,而不影响老的服务,这将大大提供系统的灵活度。
目前互联网公司广泛使用Protobuf、Thrift、Avro等成熟的序列化解决方案来搭建RPC框架,这些都是久经考验的解决方案。
通信
消息数据结构被序列化为二进制串后,下一步就要进行网络通信了。目前有两种常用IO通信模型:1)BIO;2)NIO。一般RPC框架需要支持这两种IO模型。
如何实现RPC的IO通信框架呢?
1)使用java nio方式自研,这种方式较为复杂,而且很有可能出现隐藏bug,但也见过一些互联网公司使用这种方式;
2)基于mina,mina在早几年比较火热,不过这些年版本更新缓慢;
3)基于netty,现在很多RPC框架都直接基于netty这一IO通信框架,省力又省心,比如阿里巴巴的HSF、dubbo,Twitter的finagle等。
RPC框架原理及对比_第2张图片
概况来说,远程过程调用包含如下步骤:
1、客户过程以正常的方式调用客户存根;
2、客户存根生成一个消息,然后调用本地操作系统;
3、客户端操作系统将消息发送给远程操作系统;
4、远程操作系统将消息交给服务器存根;
5、服务器存根调将参数提取出来,而后调用服务器;
6、服务器执行要求的操作,操作完成后将结果返回给服务器存根;
7、服务器存根将结果打包成一个消息,而后调用本地操作系统;
8、服务器操作系统将含有结果的消息发送给客户端操作系统;
9、客户端操作系统将消息交给客户存根;
10、客户存根将结果从消息中提取出来,返回给调用它的客户存根。

RPC 的主要好处是双重的。首先,程序员可以使用过程调用语义来调用远程函数并获取响应。其次,简化了编写分布式应用程序的难度,因为 RPC 隐藏了所有的网络代码存根函数。应用程序不必担心一些细节,比如 socket、端口号以及数据的转换和解析。在 OSI 参考模型,RPC 跨越了会话层和表示层。

一个简单 RPC 进行远程计算的例子:
RPC框架原理及对比_第3张图片
通过 RPC 进行远程计算的步骤有:
1、将参数放入消息中,并在消息中添加要调用的过程的名称或者编码。
2、消息到达服务器后,服务器存根对该消息进行分析,以判明需要调用哪个过程,随后执行相应的调用。
3、服务器运行完毕后,服务器存根将服务器得到的结果打包成消息送回客户存根,客户存根将结果从消息中提取出来,把结果值返回给客户端。

各rpc框架简单对比:

  1. srpc:服务端只支持C++,客户端支持C++,Python,PHP,Java;使用ProtoBuf序列化;服务器通信协议:HTTP协议;负载均衡:采用MSEC内部使用的自适应网络负载均衡NLB做负载均衡(CMLB);
  2. Dubbo:仅支持 Java 语言;支持多种序列化格式:hessian2、Java、json;服务器通信协议:Dubbo协议、Rmi协议、Hessian协议、HTTP协议、WebService协议、Dubbo Thrift协议、Memcached协议;负载均衡:Random(随机)、RoundRobin(轮询调度)、ConsistentHash(一致性哈希算法)、LeastActive(最少活跃数);
  3. Motan:仅支持 Java 语言;支持多种序列化格式:hessian2、json;服务器通信协议:Motan协议;负载均衡:ActiveWeight(低并发优先)、Random(随机)、RoundRobin(轮询调度)、LocalFirst(本地优先)、ConsistentHash(一致性哈希算法)、ConfigurableWeight(加权随机);
  4. gRPC:支持多种语言;使用ProtoBuf序列化;HTTP协议;负载均衡:可插拔负载均衡器的机制;
  5. Thrift:支持多种语言;支持多种序列化格式:如 Binary、Compact、JSON、Multiplexed 等;服务器通信协议:Socket、Framed、File、Memory、zlib 等;
    SRPC框架优缺点
    优点
    1、 微线程(协程库,具有同步编码、异步执行、高性能、支持多并发等特点)
    2、 插件化(开发简单,开发者只需要实现几个接口,并提供业务插件(动态库)给框架加载,即可实现业务调用)
    3、 协议简单(采用google的protobuf协议做为标准协议,自动生成代码,使用简单)
    4、 负载均衡采用CMLB插件,自动进行负载均衡处理;
    5、 具有监控系统Monitor,实时监控系统状态;
    6、 uls日志系统,支持染色快速定位;
    缺点
    1、 服务端仅支持C++,支持开发语言单一;
    2、 每写一个服务,都要创建定义proto文件,比较繁琐

你可能感兴趣的:(框架)