RPC (以dubbo为例讲解)

转自 https://my.oschina.net/zjllovecode/blog/1790024
这篇文章，介绍了
1、rpc
2、rpc和本地过程调用的区别。

1、简单组件介绍：

以Dubbo为例

RPC中可以认为有四个角色，消费者（Consumer），提供者（Provider），注册中心（Registry），监控中心（Monitor），这个还是很好理解的，以前在同一系统的方法的调用者因为网络的存在，变成了消费者，被调的方法成了提供者。

同样注册中心Registry的存在，其实就是为了让消费者实时的去感知提供者的存在，去告诉消费者它对应的提供者的地址。

Monitor顾名思义，监控者，其实在整个过程中，它并不是一定要存在，只是它可以做统计，做一些数据分析，提供整个系统的可用性，健壮性。

好了，我们先简单分析一下Registry / Consumer / Provider / Monitor 这四个角色的定义和每个角色如何各司其职，相互协作完成这整个过程的。

分析时，分成两个方面，一是每个角色在网络的定位，二是每个角色所要完成的职责

1）Registry注册中心

简述：

① 注册中心可以有多个，都是无状态的，每个注册中心之间信息不交互

② 从网络的角度来说，它都是server端，它不需要主动地连接其他的任何实例，只需要像一个地主一样等待别人来连接

③ 消费者随机选择注册中心集群中的任何实例建立长连接，提供者与注册中心中的每一个实例都建立长连接

职责：

① 接收服务提供者的服务注册信息，接收到信息之后，发送ACK信息给服务提供者，否则服务提供者重新发送注册信息

② 接收消费者的订阅信息，并把它订阅的结果返回给消费者

③ 如果注册信息变更，会主动通知订阅变更信息的消费者，注册信息的变更包括服务提供者下线，服务被人工降级，或者服务提供者的地址变更

④ 持久化一些服务信息，例如某些服务管理员审核过了，则该服务重新注册后则不需要再审核，再例如，某个服务负载均衡的策略被管理员设置为轮询，那么下次它在注册的时候，则就是轮询，而不是默认的负载策略

2）Provider提供者

简述：

① 提供者是一个精神分裂的病人，它在网络上（可以更加明确地说是站在Netty的角度上）饰演两个角色：

• 1）一是它是客户端，需要去连接Registry，发送注册信息；它也需要去连接monitor端，发送一些调用的统计信息
• 2）二是它也是服务端，需要作为server端等待Consumer去连接，连接成功后调用服务

职责：

① 将自己的信息，提供的接口信息编织成注册信息发送给registry端

② 能够动态去调自己的方法，可以通过反射，cglib等一些方法去调用自己提供的那些方法

③ 提供服务降级等服务，如果当某些服务调用的失败率高于限定值的时候，可以有一个对应的mock方法，提供降级服务

④ 限流服务，限流的方式有很多种，也有很多实现方式，最简单的就是控制调用次数，比如100w次/s，其实简单的就是控制单位时间的调用次数，防止业务洪流冲垮服务

⑤ 统计活动，将一些调用信息统计好发送给Monitor端

⑥ 补充…

3)Consumer消费者

简述：

① 它也是有两个网络角色，不过并不是精神分裂，它都是作为网络的客户端存在，一它需要去连接registry去获取到订阅信息，二是它需要主动去连接provider端去调用服务

职责：

① 去向Registry端订阅服务，拿到registry端返回的结果，这个结果也就是provider的网络地址，先建立TCP的长连接，可能是多个地址，因为提供某个服务的可能有多个提供者

② 当开始系统主动调用该服务的时候，拿到刚才建立的连接的集合，根据某个方法，是随意还是轮询，获取到其中的一个连接，发送方法入参，等待响应

③ 当注册中心发送某个服务的调用的负载策略发生变化过，发送信息给consumer，consumer需要做相应的变更

4）Monitor监控者

简述

① 这个与整个系统是没有任何直接的关系的，实现方式也是多样的，可以与上面一样建立TCP长连接，接收每个角色统计的信息，然后展示给用户，可以使用MQ，使用消息队列，每个角色把自己统计的信息放到队列中，Monitor去消费这些信息，这样做的好处就是解耦，如果monitor宕了，不影响服务

2、简单RPC实现：

直接看原文吧，不搬了~

3、本地过程调用和远程过程调用的区别

本地过程调用

RPC就是要像调用本地的函数一样去调远程函数。在研究RPC前，我们先看看本地调用是怎么调的。假设我们要调用函数Multiply来计算lvalue * rvalue的结果:

 int Multiply(int l, int r) {
    int y = l * r;
    return y;
 }

 int lvalue = 10;
 int rvalue = 20;
 int l_times_r = Multiply(lvalue, rvalue);

那么在第8行时，我们实际上执行了以下操作：

1、将 lvalue 和 rvalue 的值压栈
2、进入Multiply函数，取出栈中的值10 和 20，将其赋予 l 和 r
3、执行第2行代码，计算 l * r ，并将结果存在 y
4、将 y 的值压栈，然后从Multiply返回
5、第8行，从栈中取出返回值 200 ，并赋值给 l_times_r

以上5步就是执行本地调用的过程。

---

远程过程调用带来的新问题

在远程调用时，我们需要执行的函数体是在远程的机器上的，也就是说，Multiply是在另一个进程中执行的。这就带来了几个新问题：

Call ID映射。我们怎么告诉远程机器我们要调用Multiply，而不是Add或者FooBar呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用Multiply，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以，在RPC中，所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个 {函数 <–> Call ID} 的对应表。两者的表不一定需要完全相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，它就查一下这个表，找出相应的Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。

序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。

网络传输。远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

所以，要实现一个RPC框架，其实只需要把以上三点实现了就基本完成了。

Call ID 映射可以直接使用函数字符串，也可以使用整数ID。映射表一般就是一个哈希表。

序列化反序列化 可以自己写，也可以使用Protobuf或者FlatBuffers之类的。

网络传输库 可以自己写socket，或者用asio，ZeroMQ，Netty之类。