- RPC思想
- 组成部分
- RPC框架
- 完整的RPC框架
- RPC调用关键点
- RPC框架分类对比
- RPC和REST
- REST主要原则
- 对比
上一篇笔记：远程过程调用RPC 1：举例理解通过一个例子理解了什么是RPC，本文继续学习RPC的一些理论内容。
这个例子帮助我们理解了，RPC这个概念重要的两大块：传输协议和序列化协议。
- 传输协议：在分布式系统中，各个服务是以网络来连接对方。网络传输即解决如何将服务和序列化后的数据传给对方。这里传输协议没有限制，只需完成数据携带功能即可。
- 序列化协议：解决服务消费者怎么把参数值传给远程服务提供者的问题。C语言在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。同理，从服务端返回的值也需要序列化反序列化的过程。
在例子中，传输协议采用的是TCP/IP协议，采用了Socket进行通信，采用了jdk自带的序列化功能。但是这些实现方式对于企业级的应用太简易了，可以采用一些适合自己业务场景的传输协议（如HTTP1.1/2.0、TCP 同步/异步 阻塞/非阻塞/、自定义协议等等）以及序列化协议（文本协议、二进制协议、压缩二进制协议等等）。至于选择什么协议，主要是看业务场景。
组成部分
图源JavaGuide
整个RPC的核心功能看作是5个部分实现的：
- 客户端/服务消费端 ：调用远程方法的一端
- 客户端Stub（桩）： 代理类。把你调用方法、类、方法参数等信息传递到服务端。
- 网络传输 ： 将调用信息传输到服务端，然后服务端执行完之后再把返回结果通过网络传输回来。
- 服务端Stub（桩）：这个桩就不是代理类。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后，去指定对应的方法然后返回结果给客户端的类。
- 服务端（服务提供端）：提供远程方法的一端。
上面介绍了RPC思想的一个例子。RPC框架是一个包括的东西更多的概念。
但是，这仅仅能够称为一个PRC服务的demo，远不能称为一个RPC框架。
一个典型的远程调用时序图如下图所示：（图源：JavaGuide）
RPC框架的目标就是把2-10步封装起来，把调用、编码/解码的过程封装起来，让用户像调用本地服务一样的调用远程服务。
在一个典型RPC的使用场景中，包含了：
- 服务发现（注册中心）
- 服务发布和消费
- 服务治理
- 流量控制：动态、静态流控制
- 服务降级
- 超时控制
- 优先级调度
- 流量迁移
- 调用链跟踪和分析
- 服务路由
- SLA策略控制
- 服务监控
- 网络传输
- 序列化
- 等等
其中**“RPC 协议”就指明了程序如何进行网络传输和序列化**。
除了上面提到的网络传输和序列化和反序列化之外，RPC框架作为一个框架而不仅仅是思想还有一个重要的关键点：寻址问题。也就是，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。
解决这个问题，需要引入服务ID对服务进行区分。该ID唯一标示了某个服务，解决去哪里调用的问题。就如C语言本地调用，该id就是函数指针，Java语言就是接口和对象；在分布式系统中，该ID可以由多种组合来唯一标示某个服务，如服务提供方的应用名和服务接口名组成服务的唯一ID。
这就需要引入服务注册中心。要调用服务，首先你需要一个服务注册中心去查询对方服务都有哪些实例。例如Dubbo的服务注册中心是可以配置的，官方推荐使用Zookeeper。
分为服务治理型以及多语言型
服务治理型如：
- dubbo
- dubbox
- motan
多语言型如：
- grpc
- thrift
- avro
- Protocol Buffers (google)
图源：RPC框架比较
经常会RPC和REST一起进行比较。
REST（Representational State Transfer）是一种软件架构风格，也可以称作是一种设计API的模式，REST通过HTTP协议定义的通用动词方法GET、POST、PUT、DELETE，以URI对网络资源进行唯一标识，响应端根据请求端的不同需求，通过无状态通信，对其请求的资源进行表述，符合REST设计规范的架构就称为RESTful架构。
- 网络上的所有事物都被抽象为资源
- 每个资源都有一个唯一的资源标识符
- 对资源的各种操作不会改变资源标识符
- 所有的操作都是无状态的
- 同一个资源具有多种表现形式如xml、json等
企业开发的模式一直定性为HTTP接口开发，也就是我们常说的RESTful风格的服务接口。的确，对于在接口不多、系统与系统交互较少的情况下常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的HTTP协议进行传输。接口可能返回一个JSON字符串或者是XML文档。然后客户端再去处理这个返回的信息，从而可以比较快速地进行开发。但是对于大型企业来说，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
和RPC相比：
| 对比 | RPC | RESTful API |
|---|---|---|
| 面对对象不同 | 侧重于动作 | 主体是资源 |
| 传输效率不同 | 效率更高，使用自定义的 TCP 协议，可以让请求报文体积更小 | Http接口只关注服务提供方，对于客户端怎么调用，调用方式怎样并不关心，通常情况下，我们使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用与业务方面的开发 |
| 复杂度 | 更复杂 | 更简单 |
| 灵活性 | 不如REST灵活 | 灵活性高 |
| 使用 | RPC服务则需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效 | Http接口只关注服务提供方，对于客户端怎么调用，调用方式怎样并不关心，通常情况下，我们使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用与业务方面的开发 |
所以：
- RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，实现复杂
- RESTful主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等
此外，大型的网站，内部子系统比较多，接口非常多的情况下适合使用RPC。RPC不需要和HTTP一样三次握手，减少网络开销；安全性高，没有暴露资源操作；对微服务的支持也非常好。
