情诗网 >表白情话 > 正文

白话RPC

来源:情诗网    2021-02-02    分类:表白情话

什么是RPC?

目前大型互联网公司的系统都由成千上万大大小小的服务组成,各服务部署在不同的机器上,由不同的团队负责。

这时就会遇到两个问题:

  1. 要搭建一个新服务,免不了需要依赖他人的服务,而现在他人的服务都在远端,怎么调用?
  2. 其它团队要使用我们的新服务,我们的服务该怎么发布以便他人调用?

这时就需要借助RPC,即远程过程调用。

远程过程调用,自然是相对于本地过程调用来说的。

下面做个简单的比喻:

  • “本地过程调用,就好比你现在在家里,你要想洗碗,那你直接把碗放进洗碗机,打开洗碗机开关就可以洗了。这就叫本地过程调用。”
  • “那啥是远程过程调用?”
  • “远程嘛,那就是你现在不在家,跟姐妹们浪去了,突然发现碗还没洗,打了个电话过来,叫我去洗碗,这就是远程过程调用啦”
    简单直接吧!

对计算机来说,普通的本地函数调用,因为在同一个地址空间,或者说在同一块内存,所以通过方法栈和参数栈就可以实现。
远程过程调用,发出调用请求,该请求所执行的计算是在远程服务(机器)上。

说起RPC,就不能不提到分布式,这个促使RPC诞生的领域。
现在,基于高性能和高可靠等因素的考虑,你决定将系统改造为分布式应用,随着微服务的兴起,也会将很多可以共享的“功能单元“都单独拎出来,比如下图Service B的计算器CalculatorImpl,可以单独把它放到一个服务里头,让别的服务去调用它。


image.png

RPC解决了什么?

这下问题来了,服务A里头并没有CalculatorImpl这个类,那它要怎样调用服务B的CalculatorImpl的add方法呢?

由于各服务部署在不同机器,服务间的调用免不了网络通信过程。很多人自然会想到可以模仿B/S架构的调用方式,在B服务暴露一个Restful接口,然后A服务通过调用这个Restful接口来间接调用CalculatorImpl的add方法。

很好,这已经很接近RPC了,不过如果是这样,服务消费方每调用一个服务都要写一坨网络通信相关的代码,不仅复杂而且极易出错。比如httpClient.sendRequest…之类的,能不能像本地调用一样,去发起远程调用,让使用者感知不到远程调用的过程呢?

这时候,有人会说用代理模式呀!这个代理对象的内部,就是通过httpClient来实现RPC远程过程调用的。可能上面这段描述比较抽象,不过这就是很多RPC框架要解决的问题和解决的思路,比如阿里的Dubbo。

总结一下,RPC要解决的两个问题:

  1. 解决分布式系统中,服务之间的调用问题。
  2. 远程调用时,要能够像本地调用一样方便,让调用者感知不到远程调用的逻辑。

为什么需要RPC、而不是Http?

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

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


image.png
  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这些步骤都封装起来,让用户对这些细节透明。

这个过程中最重要的就是序列化和反序列化了,因为数据传输的数据包必须是二进制的,你直接丢一个Java对象过去,人家可不认识,你必须把Java对象序列化为二进制格式,传给Server端,Server端接收到之后,再反序列化为Java对象。

RPC是面向过程,Restful是面向资源,并且使用了Http动词。从这个维度上看,Restful风格的url在表述的精简性、可读性上都要更好。



RPC通信协议选择&性能因素

RPC 可基于 HTTP 或 TCP 协议,Web Service 就是基于 HTTP 协议的 RPC,它具有良好的跨平台性,但其性能却不如基于 TCP 协议的 RPC。会两方面会直接影响 RPC 的性能,一是传输方式,二是序列化。
众所周知,TCP 是传输层协议,HTTP 是应用层协议,而传输层较应用层更加底层,在数据传输方面,越底层越快,因此,在一般情况下,TCP 一定比 HTTP 快。就序列化而言,Java 提供了默认的序列化方式,但在高并发的情况下,这种方式将会带来一些性能上的瓶颈,于是市面上出现了一系列优秀的序列化框架,比如:Protobuf、Kryo、Hessian、Jackson 等,它们可以取代 Java 默认的序列化,从而提供更高效的性能。
为了支持高并发,传统的阻塞式 IO 显然不太合适,因此我们需要异步的 IO,即 NIO。Java 提供了 NIO 的解决方案,Java 7 也提供了更优秀的 NIO.2 支持,用 Java 实现 NIO 并不是遥不可及的事情,只是需要我们熟悉 NIO 的技术细节。



RPC vs RMI

严格来说这两者也不是一个维度的。
RMI是Java提供的一种访问远程对象的协议,是已经实现好了的,可以直接用了。
而RPC呢?人家只是一种编程模型,并没有规定你具体要怎样实现,你甚至都可以在你的RPC框架里面使用RMI来实现数据的传输



RPC没那么简单

要实现一个RPC不算难,难的是实现一个高性能高可靠的RPC框架。

比如,既然是分布式了,那么一个服务可能有多个实例,你在调用时,要如何获取这些实例的地址呢?

这时候就需要一个服务注册中心,比如在Dubbo里头,就可以使用Zookeeper作为注册中心,在调用时,从Zookeeper获取服务的实例列表,再从中选择一个进行调用。

那么选哪个调用好呢?这时候就需要负载均衡了,于是你又得考虑如何实现复杂均衡,比如Dubbo就提供了好几种负载均衡策略。

这还没完,总不能每次调用时都去注册中心查询实例列表吧,这样效率多低呀,于是又有了缓存,有了缓存,就要考虑缓存的更新问题,blablabla……

你以为就这样结束了,没呢,还有这些:

  • 客户端总不能每次调用完都干等着服务端返回数据吧,于是就要支持异步调用;
  • 服务端的接口修改了,老的接口还有人在用,怎么办?总不能让他们都改了吧?这就需要版本控制了;
  • 服务端总不能每次接到请求都马上启动一个线程去处理吧?于是就需要线程池;
  • 服务端关闭时,还没处理完的请求怎么办?是直接结束呢,还是等全部请求处理完再关闭呢?
  • ……

如此种种,都是一个优秀的RPC框架需要考虑的问题。

热门文章