RPC理论

RPC概述:

RPC (Remote Procedure Call Protocol) - 远程过程调用协议， 一种通过网络从远程计算机程序上请求服务， 而不需要了解底层网络技术的协议。 RPC协议假定某些传输协议的存在， 如TCP或UDP， 为通信程序之间携带信息数据， 在OSI网络通信模型中， RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易

过程是什么？

过程就是业务处理， 计算任务， 更直白理解， 就是程序
像调用本地方法一样调用远程的过程

响应要慢几个数量级
不那么可靠

RPC C/S模式

RPC采用客户机/服务器模式
RPC采用Client-Server结构, 通过request-response消息模式实现

RPC的三个过程

1: 通讯协议
2. 寻址(联系地址,互联网ip,/现实/手机号)
3.序列化(数据)

为什么要用RPC?

服务化/微服务
分布式系统架构
服务可重用
系统间交互调用

RPC与其他协议的区别

RMI(remote method invocation)远程方法调用是oop领域中RPC的一种具体实现
我们熟悉的webservice, restfull接口调用是RPC吗?
都是RPC, 只是消息的组织方式, 消息协议不同罢了

RPC特性和使用场景
与MQ做对比

在架构上, RPC和MQ的差异点是, Message Queue有一个中间节点Queue, 可以把消息存储

RPC的特性

同步调用, 对于要等待返回结果的场景, RPC可以非常自然直觉的使用(RPC也可以是异步调用).
由于等待结果, Consumer会有线程消耗, 如果以异步ROC的方式使用, Consumer线程消耗可以去掉, 但不能做到像MQ一样暂存请求,压力会直接传导到服务Provider

消息的特性

1. Message Queue把请求的压力保存一下, 逐渐释放出来, 让处理者按照自己的节奏来处理
2. Message Queue引入一下新的结点, 系统的可靠性会受Message Queue结点的影响
3. Message Queue是异步单向的消息, 发送消息设计成是不需要等待消息处理的完成
   所以对于同步返回需求, 用Message Queue则变的麻烦了

RPC, MQ适用场合差异

1. 希望同步得到结果的场合, RPC合适
2. 希望适用简单, 则RPC; RPC操作基于接口, 使用简单, 使用方法模拟本地调用, 异步的方法编程比较复杂
3. 不希望发送端受限于处理端的速度时, 使用Message Queue
4. 随着业务增长, 有的处理端处理量会成为瓶颈, 会进行同步调用到异步消息的改造

RPC的流程

1. 客户端处理过程中调用Client stub(就像调用本地方法一样), 传入参数
2. Client stub将参数编组为消息, 然后通过系统调用向服务端发送消息;
3. 客户端本地操作系统将消息从客户端机器发送到服务端机器
4. 服务端操作系统将接收到的数据包传递给Server stub;
5. Server stub解组消息为参数
6. Sever stub再调用服务端的过程, 过程执行结果以反方向的相同步骤响应给客户端

stub(存根): 分布式计算中的存根是一段代码, 它转换在远程过程调用(RPC)期间Client和server之间传递的参数

该流程中需要处理哪些问题?

1. Client stub, Server stub的开发
2. 参数如何编组为消息, 以及解组消息;
3. 消息如何发送;
4. 过程结果如何表示, 异常情况如何处理
5. 如何实现安全的访问控制

RPC核心概念术语

Client, Server, calls, replies, serverices, programs, version,marshalling(编组),unmarshalling(解组)
一个网络服务由一个或多个远程程序集构成
一个远程程序实现一个或多个远程过程
过程, 过程的参数, 结果在程序协议说明书中定义说明
为兼容程序协议变更, 一个服务端可能支持多个版本的远程程序

RPC协议是什么?

RPC调用过程中需要将参数编组为消息进行发送, 接收方需要解组消息为参数, 过程处理结果同样需要经编组,解组. 消息由哪些部分构成及消息的表示形式就构成了消息协议

RPC调用过程中采用的消息协议称为RPC协议

RPC要做的事, RPC协议规定请求, 响应消息的格式. 在TCP(网络传输控制协议) 之上我们可以选用或自定义消息协议来完成我们的RPC消息交互

我们可以选用通用的标准协议, 如: http, https
也可根据自身的需要定义自己的消息协议!

RPC框架是什么?

封装好了参数编组, 消息解组, 底层网络通信的RPC程序开发框架, 让我们可以直接在其基础上只需要专注于我们的过程代码编写

常用的RPC框架

java领域:传统的webservice框架: Apache CXF, Apache Axis2, java自带的JAX_WS等等.
webService框架大多基于标准的SOAP协议

新兴的微服务框架: DUbbo, spring cloud, Apache Thrift, ICE, GRPC等等

RPC框架的服务暴露

远程提供者需要以某种形式提供服务调用相关的信息, 包括但不限于服务接口定义, 数据结构, 或者中间态的服务定义文件. 例如Facebook的Thrift的IDL文件, Web service的WSDL文件; 服务的调用者需要通过一定的途径获取远程服务调用相关的信息

暴露服务方式

暴露服务方式	描述
根据IDL生成	跨语言平台RPC框架,根据IDL(接口描述语音)定义在编译器用代码生成器生成stub代码, 这是跨语言平台RPC框架的必然选择,比如protocol buffer
共享接口	同一语言平台可以通过共享接口定义实现

RPC框架的远程代理对象

代理处理技术
服务调用者用的服务实际上远程服务的本地代理, 说白了就是通过动态代理来实现
java里至少提供了两种技术来提供动态代码生成,一种是jdk动态代理, 另外一种是字节码生成
动态代理相比字节码生成使用起来更方便, 但动态代理方式在性能上是要逊色于直接的字节码生成的,而字节码生成在代码可读性上要差很多
两者权衡起来, 牺牲一些性能来获得代码可读性和维护性显得更重要

RPC框架的通信

RPC框架通信与具体的协议无关, RPC可基于http或TCP协议, Web Service就是基于HTTP协议的RPC, 它具有良好的跨平台性, 但其性能却不如基于TCP协议的RPC

名称	描述
协议	TCP是传输层协议, HTTP是应用层协议, 传输层比应用层更加底层, 越底层数据传输越快, 一般情况下, TCP比HTTP快
消息ID	RPC的应用场景实质是一种可靠的请求/应答消息流, 选择昌连接方法的TCP协议会更搞笑, 为更容易的复用连接, 定义了每个消息的唯一id
IO方式	为支持高并发, NIO比BIO更合适. Java提供了NIO接口和Netty通信框架
多连接	client和server之间到底需要多少个连接? 单连接和多连接在使用上没有区别, 对于数据传输,量较小的应用类型, 单连接基本足够, 单连接和多连接最大的区别在于, 每个连接都有自己私有的发送和接收缓冲区, 因此大数据量传输时分散在不同的连接缓存区会得到更好的吞吐效率. 如果数据传输量不足让单连接的缓存区一直处于饱和状态的话, 使用多连接的效率不会明显提升,反而会增加连接管理的开箱
心跳	连接是由client端发起建立并维持.如果client和server之间是直连的, 那么连接一般不会中断(物理链路故障除外). 如果client和server连接经过一些负载中转设备, 有可能连接一段时间不活跃时会被这些中间设备中断, 为了保持连接有必要定时为每个连接发送心跳数据以维持连接不中断.

RPC框架的序列化
两方面会直接影响RPC的性能, 一是传输方式, 而是序列化

名称	描述
序列化方式	远程通信,需要将对象转化成二进制流进行传输, 不同的RPC框架应用的场景不同, 在序列化上也会采取不同的技术. 比如: Protobuf, kryo, Hessian, Jackson等, 它们可以取代Java默认的序列化,从而提供更高效的性能
元信息	元信息以方便程序编解码以及未来可能的扩展, 这样我们的编码消息里面就分成了两部分, 一部分就是元信息,另一部分是调用的必要信息, 如果设计一种RPC协议消息的话,元信息我们把他放在协议消息头中, 而必要信息放在协议消息体中
编码内容	编码的信息越少网络上传输数据越少,编码的规则越简单执行效率越高