RPC框架原理及对比

由于各服务部署在不同机器，服务间的调用免不了网络通信过程，服务消费方每调用一个服务都要写一坨网络通信相关的代码，不仅复杂而且极易出错。
RPC能让我们像调用本地服务一样调用远程服务，而让调用者对网络通信这些细节透明，大大提高生产力，在各大互联网公司中被广泛使用，如阿里巴巴的hsf、dubbo（开源）、Facebook的thrift（开源）、Google grpc（开源）、Twitter的finagle（开源）等。

要让网络通信细节对使用者透明，需要对通信细节进行封装，一个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等。

概况来说，远程过程调用包含如下步骤：
1、客户过程以正常的方式调用客户存根；
2、客户存根生成一个消息，然后调用本地操作系统；
3、客户端操作系统将消息发送给远程操作系统；
4、远程操作系统将消息交给服务器存根；
5、服务器存根调将参数提取出来，而后调用服务器；
6、服务器执行要求的操作，操作完成后将结果返回给服务器存根；
7、服务器存根将结果打包成一个消息，而后调用本地操作系统；
8、服务器操作系统将含有结果的消息发送给客户端操作系统；
9、客户端操作系统将消息交给客户存根；
10、客户存根将结果从消息中提取出来，返回给调用它的客户存根。

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

一个简单 RPC 进行远程计算的例子：

通过 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文件，比较繁琐