RPC框架

参考文献：

如何给老婆解释RPC？

如何实现一个简单的RPC？

 

什么是RPC，所属什么体系？

RPC（Remote Procedure Call）远程过程调用

属于IPC（进程间通信）的内容

IPC可分为：多任务操作系统 & 联网的计算机之间

也可分为：

• LPC（本地过程调用）实现BY 共享内存
• RPC（远程过程调用）实现BY 网上

 

RPC的诞生

LPC

由于高性能高可靠性等因素，决定将系统改造为分布式应用（将共享的功能拎出来）

RPC

到这里很容易想到一个，模仿B/S架构的调用方式，通过restful的接口来间接的调用CalculatorImpl的add方法

这已经很接近RPC了，但是你不能每次都发一个HTTP请求，我们想像本地调用一样，去发起远程调用，让使用者感知不到远程调用的过程

 

SO RPC要解决的两个问题：

1. 解决分布式系统中，服务之间的调用问题

2. 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。(屏蔽底层传输方式)

 

如何实现RPC？

实际情况下，RPC很少用到http协议来进行数据传输，毕竟我只是想传输一下数据而已，何必动用到一个文本传输的应用层协议呢，我为什么不直接使用二进制传输？比如直接用Java的Socket协议进行传输？

不管你用何种协议进行数据传输，一个完整的RPC过程，都可以用下面这张图来描述：

Client Application 就是调用方

Client Stub 看起来是Caculator的实现类，其实内部是通过RPC（这样就能做到像本地调用一样方便，让调用者感知不到远程调用的逻辑）

Client Run-Time Library 是实现远程调用的工具包 e.g. java 的 socket

（其实这里涉及一个序列化和反序列化的过程）

 

一些比较，方便于更好的理解RPC

RPC VS Restful

其实这两者并不是一个维度的概念，总的来说RPC涉及的维度更广

我们硬要比较，那么可以从RPC风格的url和Restful风格的url上进行比较

e.g.RPC ：/queryOrder?orderId=123

Restful ：GET /order?orderId=123

RPC是面向过程，Restful是面向资源的

• 资源粒度。RPC 就像本地方法调用，RESTful API 每一次添加接口都可能需要额外地组织开放接口的数据，这相当于在应用视图中再写了一次方法调用，而且它还需要维护开发接口的资源粒度、权限等。
• 流量消耗。RESTful API 在应用层使用 HTTP 协议，哪怕使用轻型、高效、传输效率高的 JSON 也会消耗较大的流量，而 RPC 传输既可以使用 TCP 也可以使用 UDP，而且协议一般使用二制度编码，大大降低了数据的大小，减少流量消耗。

RPC VS RMI

RMI是Java提供的一种访问远程对象的协议，是已经实现好了的，可以直接用了。

而RPC呢？人家只是一种编程模型，并没有规定你具体要怎样实现，你甚至都可以在你的RPC框架里面使用RMI来实现数据的传输，比如Dubbo：Dubbo - rmi协议

 

RPC在应用中要注意些什么？

1. 服务的注册中心
2. 负载均衡
3. 缓存（存实例列表，不能每次都去服务注册中心查吧）
4. 异步调用
5. 老接口 新接口 版本控制
6. 服务端每收一个请求开个线程？线程池
7. 服务端关闭时，还没处理完的请求 偶都剋？

 

Rest和RPC接口区别

接口调用通常包含两个部分，序列化和通信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等；通信比较流行的是http、soap、websockect，RPC通常基于TCP实现，常用框架例如dubbo，netty、mina、thrift

首先解释下两种接口调用：

Rest：严格意义上说接口很规范，操作对象即为资源，对资源的四种操作（post、get、put、delete），并且参数都放在URL上,但是不严格的说Http+json、Http+xml，常见的http api都可以称为Rest接口。

Rpc:我们常说的远程方法调用，就是像调用本地方法一样调用远程方法，通信协议大多采用二进制方式

http vs 高性能二进制协议
http相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，相应的，如果采用http，无疑在你实现SDK之前，支持了所有语言，所以，现在开源中间件，基本最先支持的几个协议都包含RESTful。
RPC协议性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能达到http的二倍。响应时间也更为出色。千万不要小看这点性能损耗，公认的，微服务做的比较好的，例如，netflix、阿里，曾经都传出过为了提升性能而合并服务。如果是交付型的项目，性能更为重要，因为你卖给客户往往靠的就是性能上微弱的优势。RESTful

你可以看看，无论是Google、Amazon、netflix（据说很可能转向grpc），还是阿里，实际上内部都是采用性能更高的RPC方式。而对外开放的才是RESTful。

 

Rest 调用及测试都很方便，Rpc就显得有点麻烦，但是Rpc的效率是毋庸置疑的，所以建议在多系统之间采用Rpc，对外提供服务，Rest是很适合的
duboo在生产者和消费者两个微服务之间的通信采用的就是Rpc,无疑在服务之间的调用Rpc更变现的优秀

 

Rpc在微服务中的利用

1、 RPC 框架是架构微服务化的首要基础组件 ，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节
2、 RPC 框架的 职责 是： 让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务

RPC的好处：

 

RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。 为实现该目标，RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用。
服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦。 
如果没有统一的服务框架，RPC框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。所以，统一RPC框架把上述“业务之外”的技术劳动统一处理，是服务化首要解决的问题
 

几种协议

Socket使用时可以指定协议Tcp,Udp等；

RIM使用Jrmp协议，Jrmp又是基于TCP/IP；

RPC底层使用Socket接口，定义了一套远程调用方法；

HTTP是建立在TCP上，不是使用Socket接口，需要连接方主动发数据给服务器，服务器无法主动发数据个客户端；

Web Service提供的服务是基于web容器的，底层使用http协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。就是通过一个servlet，提供服务出去。
 hessian是一套用于建立web service的简单的二进制协议，用于替代基于XML的web service，是建立在rpc上的，hessian有一套自己的序列化格式将数据序列化成流，然后通过http协议发送给服务器