“这是我参与8月更文挑战的第14天，活动详情查看：8月更文挑战”

一、 基本概念

RPC, 远程过程调用（Remote Procedure Call，RPC）是一个计算机通信协议，该协议允许运行于一台计算机的程序程调用另一台计算机的上的程序。通俗讲，RPC通过把网络通讯抽象为远程的过程调用，调用远程的过程就像调用本地的子程序一样方便，从而屏蔽了通讯复杂性，使开发人员可以无需关注网络编程的细节，将更多的时间和精力放在业务逻辑本身的实现上，提高工作效率。

RPC本质上是一种 Inter-process communication（IPC）——进程间通信的形式。常见的进程间通信方式如管道、共享内存是同一台物理机上的两个进程间的通信，而RPC就是两个在不同物理机上的进程之间的通信。概括的说，RPC就是在一台机器上调用另一台机器上的方法，这种调用在远程机器上对代码的执行就像在本机上对代码的执行一样，只是迁移了一个执行环境而已。

二、RPC的通信流程

（一）、RPC的通信模式

RPC采用客户端/服务端的模式，通过request-response消息模式实现

1、通讯协议： 比如：你需要找人在国外干活，那么你可以直接飞过去或者打电话或者通过互联网的形式，去找人，这个找人的过程就是通讯协议

2、寻址 ：既然要找人干活，肯定要知道地址在哪，飞过去需要找到详细地址，打电话需要知道电话号码，互联网需要知道IP是多少

3、数据序列化： 就是说，语言需要互通，才能够让别人干活，之间需要一个大家都懂的语言去交流

（二）、RPC的通信流程 通信流程图1

通信流程图2

以上两个图所表示内容相同，上述两个图片都较为常见

首先客户端需要告诉服务器，需要调用的函数，这里函数和进程ID存在一个映射，客户端远程调用时，需要查一下函数，找到对应的ID，然后执行函数的代码。

客户端需要把本地参数传给远程函数，本地调用的过程中，直接压栈即可，但是在远程调用过程中不再同一个内存里，无法直接传递函数的参数，因此需要客户端把参数转换成字节流，传给服务端，然后服务端将字节流转换成自身能读取的格式，是一个序列化和反序列化的过程。

数据准备好了之后，如何进行传输？网络传输层需要把调用的ID和序列化后的参数传给服务端，然后把计算好的结果序列化传给客户端，因此TCP层即可完成上述过程，gRPC中采用的是HTTP2协议。

总结一下上述过程：

（1）、Client和Server两者的视角进行分析

// Client端 
//    Student student = Call(ServerAddr, addAge, student)
1. 将这个调用映射为Call ID。
2. 将Call ID，student（params）序列化，以二进制形式打包
3. 把2中得到的数据包发送给ServerAddr，这需要使用网络传输层
4. 等待服务器返回结果
5. 如果服务器调用成功，那么就将结果反序列化，并赋给student，年龄更新

// Server端
1. 在本地维护一个Call ID到函数指针的映射call_id_map，可以用Map<String, Method> callIdMap
2. 等待客户端请求
3. 得到一个请求后，将其数据包反序列化，得到Call ID
4. 通过在callIdMap中查找，得到相应的函数指针
5. 将student（params）反序列化后，在本地调用addAge()函数，得到结果
6. 将student结果序列化后通过网络返回给Client

（2）、一次完成的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这些步骤都封装起来，让用户对这些细节透明。

三、RPC的角色 在RPC框架中主要有三个角色：Provider、Consumer和Registry。如下图所示：

节点角色说明：

Server: 暴露服务的服务提供方。

Client: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

四、为什么需要注册中心

首先需要思考一个问题：如何让别人使用我们的服务呢？

有同学说很简单嘛，告诉使用者服务的IP以及端口就可以了啊。确实是这样，这里问题的关键在于是自动告知还是人肉告知。

有没有一种方法能实现自动告知，即机器的增添、剔除对调用方透明，调用者不再需要写死服务提供方地址？

当然可以，通过注册中心实现服务自动注册与发现功能！

服务注册：

​ 服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。 ​ 通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。

五、使用到的技术

1、远程代理对象（动态代理）

远程提供者需要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构或者中间态的服务定义文件，web service的WSDL文件；服务调用者需要通过一定的途径获取远程服务调用相关的信息

生成 client stub和server stub需要用到 Java 动态代理技术 ，我们可以使用JDK原生的动态代理机制，可以使用一些开源字节码工具框架 如：CgLib、Javassist等。

2、序列化

传输方式和序列化会直接影响RPC的性能

为了能在网络上传输和接收 Java对象，我们需要对它进行 序列化和反序列化操作。

序列化：将Java对象转换成byte[]的过程，也就是编码的过程； 反序列化：将byte[]转换成Java对象的过程； 可以使用Java原生的序列化机制，但是效率非常低，推荐使用一些开源的、成熟的序列化技术，例如：protobuf、Thrift、hessian、Kryo、Msgpack

关于序列化工具性能比较可以参考：jvm-serializers

3、通信（NIO）

当前很多RPC框架都直接基于netty这一IO通信框架，比如阿里巴巴的HSF、dubbo，Hadoop Avro，推荐使用Netty 作为底层通信框架。

4、服务注册中心

可选技术：

Redis Zookeeper Consul Etcd

六、注销/注销服务；服务订阅/取消

（一）、注册/注销服务

服务的注册与注销，是对服务提供方角色而言，那么注册服务与注销服务的时序图，如图所示：

（二）、服务订阅/取消

为了满足应用系统的需求，服务消费方的可能需要从服务注册中心订阅指定的有服务提供方发布的服务，在得到通知可以使用服务时，就可以直接调用服务。反过来，如果不需要某一个服务了，可以取消该服务。下面看一下对应的时序图，如图所示：

七、RPC框架

传统的webservice框架：apache CXF、apache Axis2

新兴的微服务框架：Dubbo、springcloud、apache Thrift、ICE、GRPC等

常见的分布式RPC框架：

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝内部，dubbo由于跟淘宝另一个类似的框架HSF（非开源）有竞争关系，导致dubbo团队已经解散（参见www.oschina.net/news/55059/… 中的评论），反到是当当网的扩展版本仍在持续发展，墙内开花墙外香。其它的一些知名电商如当当、京东、国美维护了自己的分支或者在dubbo的基础开发，但是官方的库缺乏维护，相关的依赖类比如Spring，Netty还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了升级Spring和Netty的插件。

Motan是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。

rpcx是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。

gRPC是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

thrift是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。