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