RPC（Remote Procedure Call）是一种进程间通信方式。简单地说就是能使应用像调用本地方法一样的调用远程的过程或服务，可以应用在分布式服务、分布式计算、远程服务调用等许多场景。说起 RPC 大家并不陌生，业界有很多开源的优秀 RPC 框架，例如 Dubbo、Thrift、gRPC、Hprose 等等。下面先简单介绍一下 RPC 与常用远程调用方式的特点，以及一些优秀的开源 RPC 框架。
RPC与其他远程调用的比较
- RPC 与 HTTP、RMI、Web Service 都能完成远程调用，但是实现方式和侧重点各有不同。
- HTTP
- HTTP（HyperText Transfer Protocol）是应用层通信协议，使用标准语义访问指定资源（图片、接口等），网络中的中转服务器能识别协议内容。HTTP 协议是一种资源访问协议，通过 HTTP 协议可以完成远程请求并返回请求结果。
- HTTP 的优点是简单、易用、可理解性强且语言无关 ，在远程服务调用中包括微博有着广泛应用。HTTP 的缺点是协议头较重，一般请求到具体服务器的链路较长，可能会有 DNS 解析、Nginx 代理等。
- RPC
- RPC是一种协议规范，可以把HTTP看作是一种RPC的实现，也可以把HTTP作为RPC的传输协议来应用。RPC服务的自动化程度较高，能够实现强大的服务治理功能，和语言结合更友好，性能也十分优秀。与HTTP相比，RPC的缺点就是相对复杂，学习成本稍高
- RMI
- RMI（Remote Method Invocation）是指java语言中的远程方法调用，RMI中的每个方法都具有方法签名，RMI客户端和服务端通过方法签名进行远程方法调用。RMI只能在Java语言中使用，可以把RMI看作面向对象的java RPC
- Web Service
- Web Service是一种基于Web进行服务发布、查询、调用的架构方式，重点在于服务的管理与使用。Web Service一般通过WSDL(基于XML的网络服务描述语言)描述服务，使用SOAP（简单对象访问协议）通过HTTP调用服务
- RPC是一种远程访问协议，而Web Service是一种体系结构，Web Service也可以通过RPC来进行服务调用，因此Web Service更适合同一个RPC框架进行比较。当RPC框架提供了服务的发现与管理，并使用HTTP作为传输协议时，其实就是Web Service
RPC框架介绍
- RPC 协议只规定了 Client 与 Server 之间的点对点调用流程，包括 stub、通信协议、RPC 消息解析等部分，在实际应用中，还需要考虑服务的高可用、负载均衡等问题，所以这里的 RPC 框架指的是能够完成 RPC 调用的解决方案，除了点对点的 RPC 协议的具体实现外，还可以包括服务的发现与注销、提供服务的多台 Server 的负载均衡、服务的高可用等更多的功能。 目前的 RPC 框架大致有两种不同的侧重方向，一种偏重于服务治理，另一种偏重于跨语言调用 。
- 偏重于服务治理–服务治理型 RPC 框架
- 服务治理型的RPC框架有Dubbo、DubboX等，Dubbo是阿里开源的分布式服务框架，能够实现高性能RPC调用，并且提供了丰富的管理功能，是十分优秀的RPC框架。DubboX是基于Dubbo框架开发的RPC框架，支持REST风格远程调用，并增加了一些新的feature
- 这类RPC框架的特点是功能丰富，提供高性能的远程调用以及服务发现及治理功能，适用于大型服务的微服务化拆分以及管理，对于特定语言如java的项目可以十分友好的透明化接入，但缺点是语言耦合度较高，跨语言支持难度较大
- 偏重于跨语言调用-跨语言调用型
- 跨语言调用型的RPC框架有Thrift、gRPC、Hessian、Hprose等，这一类的RPC框架重点关注于服务的跨语言调用，能够支持大部分的语言进行语言无关的调用，非常适合于为不同语言提供通用远程服务的场景。但这类框架没有服务发现相关机制，实际使用时一般需要代理层进行请求转发和负载均衡策略控制
背景
- 一旦踏入公司尤其是大型互联网公司就会发现，公司的系统都由成千上万大大小小的服务组成，各服务部署在不同的机器上，由不同的团队负责。这时就会遇到两个问题：1）要搭建一个新服务，免不了需要依赖他人的服务，而现在他人的服务都在远端，怎么调用？2）其它团队要使用我们的新服务，我们的服务该怎么发布以便他人调用？下文将对这两个问题展开探讨。
如何调用他人的远程服务
- 由于各服务部署在不同机器，服务间的调用免不了网络通信过程，服务消费方每调用一个服务都要写一坨网络通信相关的代码，不仅复杂而且极易出错。
- 如果有一种方式能让我们像调用本地服务一样调用远程服务，而让调用者对网络通信这些细节透明，那么将大大提高生产力，比如服务消费方在执行helloWorldService.sayHello(“test”)时，实质上调用的是远端的服务。这种方式其实就是RPC（Remote Procedure Call Protocol），在各大互联网公司中被广泛使用，如阿里巴巴的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这些步骤都封装起来，让用户对这些细节透明。
怎样做到透明化远程服务调用
- 怎么封装通信细节才能让用户像以本地调用方式调用远程服务呢？对java来说就是使用代理，java代理有两种方式：1）jdk动态代理；2）字节码生成。尽管字节码生成方式实现的代理更为强大和高效，但代码维护不易，大部分公司实现RPC框架时还是选择动态代理方式。
- 下面给出一个实现
public class RPCProxyClient implements java.lang.reflect.InvocationHandler{
private Object obj;
public RPCProxyClient(Object obj){
this.obj=obj;
}
/**
* 得到被代理对象;
*/
public static Object getProxy(Object obj){
return java.lang.reflect.Proxy.newProxyInstance(obj.getClass().getClassLoader(),
obj.getClass().getInterfaces(), new RPCProxyClient(obj));
}
/**
* 调用此方法执行
*/
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
//结果参数;
Object result = new Object();
// ...执行通信相关逻辑
// ...
return result;
}
}
public class Test {
public static void main(String[] args) {
HelloWorldService helloWorldService = (HelloWorldService)RPCProxyClient.getProxy(HelloWorldService.class);
helloWorldService.sayHello("test");
}
}怎么对消息进行编码和解码呢？
确定消息数据结构
- 上面讲了invoke里需要封装通信细节，而通信的第一步就是要确定客户端和服务端相互通信的消息结构。客户端的请求消息结构一般需要以下内容：
- 1）接口名称 在我们的例子里接口名是“HelloWorldService”，如果不传，服务端就不知道调用哪个接口了；
- 2）方法名 一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法；
- 3）参数类型&参数值 参数类型有很多，比如有bool、int、long、double、string、map、list，甚至如struct（class）；以及相应的参数值；
- 4）超时时间
- 5）requestID，标识唯一请求id，在下面一节会详细描述requestID的用处。
- 同样服务端返回的消息结构一般包括以下内容
- 1）返回值
- 2）状态code
- 3）requestID
序列化
- 一旦确定了消息的数据结构之后，下一步就是要考虑序列化与反序列化了
- 什么是序列化？序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程
- 什么是反序列化？将在序列化过程中所生成的二进制串转换成数据结构或对象的过程
- 为什么需要序列化？转换为二进制串才好进行网络传输嘛
- 为什么需要反序列化？将二进制串转换成对象才好进行后续处理嘛
- 现如今序列化的方案越来越多，每种序列化方案都有优点和缺点，它们在设计之初有自己独特的应用场景，那到底选择哪种呢？从RPC的角度上看，主要有三点：1）通用性，比如是否能支持Map等复杂的数据结构；2）性能，包括时间复杂度和空间复杂度，由于RPC框架将会被公司几乎所有服务使用，如果序列化上能节约一点时间，对整个公司的收益都将非常可观，同理如果序列化上能节约一点内存，网络带宽也能省下不少；3）可扩展性，对互联网公司而言，业务变化飞快，如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提高系统的灵活性
- 目前互联网公司广泛使用Protobuf、Thrift、Avro等成熟的序列化解决方案来搭建RPC框架，这些都是久经考验的解决方案。
通信
- 消息数据结构被序列化为二进制串后，下一步就要进行网络通信了。目前有两种常用IO通信模型：1）BIO；2）NIO。一般RPC框架需要支持这两种IO模型
- 假设某银行只有10个职员。该银行的业务流程分为以下4个步骤：
- 1） 顾客填申请表（5分钟）；
- 2） 职员审核（1分钟）；
- 3） 职员叫保安去金库取钱（3分钟）；
- 4） 职员打印票据，并将钱和票据返回给顾客（1分钟）。
- 我们看看银行不同的工作方式对其工作效率到底有何影响。
BIO
- 每来一个顾客，马上由一位职员来接待处理，并且这个职员需要负责以上4个完整流程。当超过10个顾客时，剩余的顾客需要排队等候。
- 我们算算这个银行一个小时到底能处理多少顾客？一个职员处理一个顾客需要10分钟（5+1+3+1）时间，一个小时（60分钟）能处理6个顾客，一共10个职员，那就是只能处理60个顾客。
- 可以看到银行职员的工作状态并不饱和，比如在第1步，其实是处于等待中。
- 这种工作其实就是BIO，每次来一个请求（顾客），就分配到线程池中由一个线程（职员）处理，如果超出了线程池的最大上限（10个），就扔到队列等待 。
NIO
- 如何提高银行的吞吐量呢？
- 思路：分而治之，将任务拆分开来，由专门的人负责专门的任务。
- 具体来讲，银行专门指派一名职员A，A的工作就是每当有顾客到银行，他就递上表格让顾客填写，每当有顾客填好表后，A就将其随机指派给剩余的9名职员完成后续步骤。
- 我们计算下这种工作方式下银行一个小时到底能处理多少顾客？
- 假设顾客非常多，职员A的工作处于饱和中，他不断的将填好表的顾客带到柜台处理，柜台一个职员5分钟能处理完一个顾客，一个小时9名职员能处理：9*（60/5）=108。
- 可见工作方式的转变能带来效率的极大提升。
- 这种工作方式其实就NIO的思路。下图是非常经典的NIO说明图，mainReactor线程负责监听server socket，accept新连接，并将建立的socket分派给subReactor；subReactor可以是一个线程，也可以是线程池（一般可以设置为CPU核数），负责多路分离已连接的socket，读写网络数据，这里的读写网络数据可类比顾客填表这一耗时动作，对具体的业务处理功能，其扔给worker线程池完成。
- 可以看到典型NIO有三类线程，分别是mainReactor线程、subReactor线程、work线程。不同的线程干专业的事情，最终每个线程都没空着，系统的吞吐量自然就上去了。
异步方式
- 第二种工作方式有没有什么可以提高的地方呢？
- 仔细查看可发现第3步骤这3分钟柜台职员是在等待中度过的，那怎么能让柜台职员保持满负荷呢？
- 还是分而治之的思路，指派1个职员B来专门负责第3步骤。每当柜台员工完成第2步时，就通知职员B来负责与保安沟通取钱。这时候柜台员工可以继续处理下一个顾客。当职员B拿到钱之后，他会怎么办呢？他会通知顾客钱已经到柜台了，让顾客重新排队处理，当柜台职员再次服务该顾客时，发现该顾客前3步已经完成，直接执行第4步即可。
- 我们可以算算通过这种方法，银行的吞吐量能提高到多少。
- 假设职员B的工作非常饱和，柜台一个职员现在2分钟能处理完一个顾客，一个小时8名职员能处理：8*（60/2）=240。
- 在当今web服务中，经常需要通过RPC或者Http等方式调用第三方服务，这里对应的就是第3步，如果这步耗时较长，通过异步方式将能极大降低资源使用率。
- jetty Continuations就实现了上述异步方式，有兴趣的同学可以去尝试下（http://wiki.eclipse.org/Jetty/Feature/Continuations）。
- NIO+异步的方式能让少量的线程（资源）做大量的事情，这适用于很多应用场景，比如代理服务、api服务、长连接服务等等，这些应用如果用同步方式将耗费大量机器资源。尽管NIO+异步能提高系统吞吐量，但其并不能让一个请求的等待时间下降，相反可能会增加等待时间。
- 如何实现RPC的IO通信呢？
- 使用java nio方式自研，这种方式较为复杂，而且很有可能出现隐藏bug，但也见过一些互联网公司使用这种方式
- 基于mina，mina在2012年左右比较火，不过之后版本更新缓慢
- 基于netty（netty介绍），现在很多RPC框架都直接基于netty这一IO通信框架，省力又省心，比如阿里的HSF、dubbo，twitter的finagle等
消息里为什么要有requestID
- 如果使用netty的话，一般会用channel.writeAndFlush()方法来发送消息二进制串，这个方法调用后对于整个远程调用（从发出请求到接收到结果）来说是一个异步的，即对于当前线程来说，将请求发送出来后，线程就可以往后执行了，至于服务端的结果，是服务端处理完成后，再以消息的形式发送给客户端的。于是这里出现了两个问题：
- 怎么让当前线程“暂停”，等结果回来后，再向后执行？
- 如果有多个线程同时进行远程方法调用，这时建立在client server之间的socket连接上会有很多双方发送的消息传递，前后顺序也可能是随机的，server处理完结果后，将结果消息发送给client，client收到很多消息，怎么知道哪个消息结果是原先哪个线程调用的？
- 如何解决呢？
- client线程每次通过socket调用一次远程接口前，生成一个唯一的ID，即requestID（requestID必需保证在一个Socket连接里面是唯一的），一般常常使用AtomicLong从0开始累计数字生成唯一ID；
- 当处理结果的回调对象callback，存放到全局ConcurrentHashMap里面put(requestID,callback)；
- 当线程调用channel.writeAndFlush()发送消息后，紧接着执行callback的get()方法试图获取远程返回的结果。在get()内部，则使用synchronized获取回调对象callback的锁，再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态
- 服务端接收到请求并处理后，将response结果(此结果中包含了前面的requestID)发送给客户端，客户端socket连接上专门监听消息的线程收到消息，分析结果，取到requestID，再从前面的ConcurrentHashMap里面get(requestID)，从而找到callback对象，再用synchronized获取callback上的锁，将方法调用结果设置到callback对象里，再调用callback.notifyAll()唤醒前面处于等待状态的线程
public Object get() {
synchronized (this) { // 旋锁
while (!isDone) { // 是否有结果了
wait(); //没结果是释放锁，让当前线程处于等待状态
}
}
}private void setDone(Response res) {
this.res = res;
isDone = true;
synchronized (this) { //获取锁，因为前面wait()已经释放了callback的锁了
notifyAll(); // 唤醒处于等待的线程
}
}如何发布自己的服务？
- 如何让别人使用我们的服务呢？有同学说很简单嘛，告诉使用者服务的IP以及端口就可以了啊。确实是这样，这里问题的关键在于是自动告知还是人肉告知。
- 人肉告知的方式：如果你发现你的服务一台机器不够，要再添加一台，这个时候就要告诉调用者我现在有两个ip了，你们要轮询调用来实现负载均衡；调用者咬咬牙改了，结果某天一台机器挂了，调用者发现服务有一半不可用，他又只能手动修改代码来删除挂掉那台机器的ip。现实生产环境当然不会使用人肉方式。
- 有没有一种方法能实现自动告知，即机器的增添、剔除对调用方透明，调用者不再需要写死服务提供方地址？当然可以，现如今zookeeper被广泛用于实现服务自动注册与发现功能！
- 简单来就，zookeeper可以充当一个服务注册表(Service Registry)，让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址(ip+端口)去访问具体的服务提供者
- 具体来说，zookeeper就是个分布式文件系统，每当一个服务提供者部署后都要就将自己的服务注册到zookeeper的某一路径上: /{service}/{version}/{ip:port},比如我们的HelloWorldService部署到两台机器，那么zookeeper上就会创建两条目录：分别为/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。
- zookeeper提供了心跳检测功能，它会定时向各个服务提供者发送一个请求(实际上建立的是一个Socket长连接)，如果长期没有响应，服务中心就认为该服务提供者已经挂了，并将其剔除，比如100.19.20.02这台机器如果宕机了，那么zookeeper上的路径就会只剩/HelloWorldService/1.0.0/100.19.20.01:16888。
- 服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方服务提供者地址列表已经发生改变，从而进行更新。
- 更为重要的是zookeeper与生俱来的容错容灾能力（比如leader选举），可以确保服务注册表的高可用性。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
