微服务基础----RPC协议简单介绍

RPC（Remote Procedure Call）

1、协议简介

        ———远程过程调用，它是一个计算机通信协议。它允许像调用本地服务一样调用远程服务。它可以有不同的实现方式。如RMI(远程方法调用)、Hessian、Http invoker等。另外，RPC与语言无关的。

Hessian是一个轻量级的RPC框架，它基于HTTP协议传输，使用Hessian二进制序列化，对于数据包比较大的情况比较友好。但是它的参数和返回值都需要实现Serializable接口。

2、RPC框架架构

RPC架构分为三部分：

1）服务提供者，运行在服务器端，提供服务接口定义与服务实现类。

2）服务中心，运行在服务器端，负责将本地服务发布成远程服务，管理远程服务，提供给服务消费者使用。

3）服务消费者，运行在客户端，通过远程代理对象调用远程服务。

为了方便RPC调用者和服务者的开发，开发者们开发了很多RPC框架。比较有名的RPC框架有Google的 gRPC、Facebook的Thrift 和 阿里的 Dubbo 等。这些框架在具体实现上虽然各不相同，但其工作原理基本上是一致的。

RPC（RemoteProcedureCall），是进程间通信（IPC，Inter-Process Communication）的一种技术，指不同机器上的进程间通信。

完整的RPC调用的流程如图：

什么是Stub？

Stub是一段代码，用来转换RPC过程中传递的参数。Client端一般叫Stub，Server端一般叫Skeleton。

实现 RPC 的程序包括 5 个部分：

• User
• User-stub
• RPCRuntime
• Server-stub(Skeleton)
• Server

user 就是 client 端，当 user 想发起一个远程调用时，它实际是通过本地调用 user-stub。 user-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPCRuntime 实例传输到远端的实例。 远端 RPCRuntime 实例收到请求后交给 server-stub 进行解码后发起本地端调用，调用结果再返回给 user 端。

3、RPC框架解释

      两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法。

1. 首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
2. 第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称，名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
3. 第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。
4. 第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。
5. 第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用

当RPC框架应用于大型分布式系统时，不可能将服务的地址人为地告知到每个调用方，应该自动化地完成这个“告知”工作。这个工作的流程如图所示：

注册中心可以采用redis或者zookeeper等方式进行实现。

从服务提供者的角度看：当提供者服务启动时，需要自动向注册中心注册服务。

当提供者服务停止时，需要向注册中心注销服务；提供者需要定时向注册中心发送心跳，一段时间未收到来自提供者的心跳后，认为提供者已经停止服务，从注册中心上摘取掉对应的服务。

从调用者的角度看：调用者启动时订阅注册中心的消息并从注册中心获取提供者的地址；当有提供者上线或者下线时，注册中心会告知到调用者；调用者下线时，取消订阅。

4、RPC如何发布服务

如何让别人使用我们的服务呢？是否可以这样？告诉使用者服务的IP以及端口就可以了啊。确实是这样，这里问题的关键在于是自动告知还是人口头告知。

口头告知的方式：如果你发现你的服务一台机器不够，要再添加一台，这个时候就要告诉调用者我现在有两个IP了，你们要轮询调用来实现负载均衡；

调用者然后手动更改代码，在代码中加入新添加机器的IP和端口。结果某天一台机器挂了，调用者发现服务有一半不可用，他又只能手动修改代码来删除挂掉那台机器的IP和端口。

现实生产环境当然不会使用这种方式。

有没有一种方法能实现自动告知，即机器的增添、剔除对调用方透明，调用者不再需要写死服务提供方地址？当然可以，zookeeper被用于实现服务自动注册与发现功能！

简单来讲，zookeeper可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者。如下图所示：

zookeeper如何工作：

具体来说，zookeeper就是个分布式文件系统，每当一个服务提供者部署后都要将自己的服务注册到zookeeper的某一路径上: 

/{service}/{version}/{ip:port}

比如我们的HelloWorldService部署到两台机器，那么zookeeper上就会创建两条目录：分别为

/HelloWorldService/1.0.0/100.19.20.01:16888

/HelloWorldService/1.0.0/100.19.20.02:16888。

同时zookeeper提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除，比如100.19.20.02这台机器如果宕机了，那么zookeeper上的路径就会只剩：

/HelloWorldService/1.0.0/100.19.20.01:16888。

服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方服务提供者地址列表已经发生改变，从而进行更新。