微服务架构之 —— RPC框架

骑猪看日落 2022-08-28 12:55 29阅读 0赞

#### RPC简介 ####

*  RPC是什么
    
    Remote Procedure Call，远程过程调用。
    
    首先来说**本地方法调用**，假设在main方法中调用一个本地的方法multiply（同一个进程内的方法调用）。无非是做了内存寻址和一些堆栈操作。
    
    而假设main方法和multiply方法不在同一个进程中，两者则通过RPC的方式进行调用（通信）。由于是跨网络通信，需要考虑将方法调用和参数，如何变成网络上可传输的二进制流（涉及到参数和结果的序列化，反序列化，socket网络编程等细节）。而这就是RPC框架的意义，它帮助开发人员，屏蔽了网络编程和网络传输的细节，让开发人员像调用本地方法一样，调用远程方法。
    
    需要注意，**RPC并不是一种具体的技术框架**，而是一种**技术思想**。
    
    广义上讲，任何通过网络，远程调用另一个进程中的方法的技术，都可以称为RPC。
    
    RPC并不是一个新的概念，也不是和微服务同一个时代的概念。
    
    在微服务之前，就有很多可以称之为RPC的技术理念。比如RMI，WebService。
    
     *  RMI
        
        Remote Method Invocation。比较古老。是EJB的通信基础，是实现RPC的一套Java Api，依赖JVM，所以仅支持Java应用之间的方法调用，**不能实现跨语言调用**。
        
        ![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oqg6ISa55qE5aSn54Gw54u8_size_20_color_FFFFFF_t_70_g_se_x_16][]
     *  WebService
        
        跨语言，跨平台。因为WebService底层依赖的是HTTP和XML，这两者都是语言无关的。
        
        ![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oqg6ISa55qE5aSn54Gw54u8_size_20_color_FFFFFF_t_70_g_se_x_16 1][]
 *  RPC有哪些具体的例子
    
    随着时代的发展，越来越多优秀的RPC框架进入我们的视野，如
    
     *  gRPC：谷歌开源的高性能RPC框架。基于HTTP2协议，以protobuf作为序列化协议。使得其具有很好的跨平台特性。
     *  dubbo：阿里开源的RPC框架，已捐赠给Apache
     *  Finagle：twitter的RPC框架
     *  Thrift：Facebook的RPC框架
     *  Tars：腾讯的RPC框架
 *  引入RPC后会给项目带来什么
    
    当我们引入RPC框架，并对整体系统进行了微服务化的拆分。会导致：
    
     *  提升系统的扩展性（优点）
     *  提升了系统的可维护性（优点）
     *  系统变得复杂（缺点）
        
        引入新的组件，导致在调试代码，维护系统时会变得更加复杂
     *  跨网络调用可能会增加性能开销（缺点）
    
    所以，引入RPC框架对系统进行微服务化的拆分时，一定要综合扩展性，维护性，复杂度，成本，性能等多方面的考虑。需要慎之又慎。

#### RPC基本原理 ####

RPC主要是为了解决服务的远程调用问题，即客户端和服务器之间的通信问题。当设计一款RPC框架时，主要有如下几个方面需要考虑

*  通信协议
 *  序列化
 *  IO模型

RPC调用的**通信过程**是怎样的？

1.  首先，客户端和服务端需要约定一种**通信协议**，按照此种协议来组织数据
2.  在组装数据时，需要将数据**序列化**为二进制流，以便在网络上进行传输
3.  随后，客户端组织好方法名和参数等数据，将二进制流通过网络进行发送
4.  服务端接收到数据后，按照**通信协议**解析数据，并把二进制流**反序列化**为方法名和参数
5.  服务端执行业务逻辑，得到结果后，将结果以同样的方式，返回给客户端

这样就完成了一次RPC通信

##### 通信协议 #####

需要注意处理TCP粘包的问题。解决方案通常有

*  发送和接收定长的数据（会浪费网络带宽）
 *  在数据包中额外携带长度信息（需要一个固定的空间来传输长度信息）
 *  使用特定的magic number作为数据的分界（无法判断某个数据包是否传输完）

通常使用第2种方式，或者第2和第3种结合的方式，来设计通信协议。

##### 序列化 #####

序列化，是将**数据**和**二进制流**进行相互转换的方式。

每次RPC调用，都会涉及到2次序列化和2次反序列化的过程（共4次）。

所以，选择**序列化方式**时需要注意，要避免让序列化成为整个RPC通信的性能瓶颈。在选择序列化方式时，需要关注：

*  **性能**
    
    （反）序列化执行的耗时
 *  序列化后的包的大小
    
    因为网络带宽是一定的，选择**压缩比**较高的序列化方式，可以减少高并发下RPC通信对带宽的占用
 *  可读性
    
    类似json，xml，是可读性较强的序列化方式，它们序列化后的结果都是**文本**。良好的可读性，主要是便于调试和问题排查。

需要在这3者之间做取舍和权衡。

**常见的序列化方式**

*  java serializable（不能跨语言）
 *  json，xml（可读性较好，通用性高，但体积较大）
 *  hessian，protobuf，thrift（二进制的序列化，性能高，序列化后的包体积小）

##### IO模型 #####

常见的IO模型，如下

*  阻塞IO
 *  非阻塞IO
 *  多路复用IO（对应Java的NIO）
 *  信号驱动IO
 *  异步IO（Java的AIO）

通常使用较多的是多路复用IO。异步IO还不够成熟

#### 服务治理 ####

目前业界开源的RPC框架中，更多的都是属于**服务框架**，而不是单纯的RPC框架。

服务框架和RPC框架的区别在于：**RPC框架**只是简单的解决通信问题，而**服务框架**，除了解决通信问题，还需要解决服务管理的问题。

所以我们需要了解，**服务治理**需要解决什么问题，以及它是如何解决的。

服务治理有哪些方面？

*  服务注册与发现
 *  服务追踪（分布式追踪）
 *  配置管理
 *  服务熔断，降级，分流
 *  服务负载均衡
 *  服务监控

##### 注册中心 #####

过程

*  服务启动时向注册中心注册服务节点地址
 *  客户端从注册中心获取服务的地址列表
 *  有新的服务注册上来后，客户端可以得到通知
 *  有服务出现故障或者关闭时，客户端也可以得到通知
 *  服务节点间隔固定时间向注册中心发送心跳，表明健康状况

优点

*  客户端无需重启就能感知服务节点的动态变化
 *  可以通过为服务节点增加权重，来辅助负载均衡

选型

*  分布式一致性协调系统
    
    zookeeper，etcd，consul
    
    可以当作注册中心使用，但可能功能不是很齐全，比如无法对服务做健康检测
 *  开源的，专门的注册中心
    
    nacos（阿里开源），eureka（springCloud），vintage（微博使用）
    
    功能比较完善

##### 服务追踪 #####

分布式追踪系统，主要是用于解决分布式环境下的问题排查的问题。

当我们把一个系统，拆成多个微服务之后，一次来自客户端的请求，可能会引发微服务之间的十几次，甚至几十次请求，才能得到最终的结果。

比如系统的响应时间变慢了，或者系统出了一些问题，那么我们需要知道是具体哪个微服务导致的，这就需要对整个调用链进行追踪。

分布式追踪的基本原理是：

*  一次来自客户端的调用，对应一个唯一的traceId，用这个traceId来标识整个完整的调用链路
 *  用另外一个spanId来标识一次微服务的调用。通过spanId来标识微服务之间的层级关系。
    
    比如微服务A被调用，产生一个spanId为2，A又调用了另外2个微服务B和C，产生的spanId分别为2.1和2.2。这样就能清晰的知道微服务之间调用的层级关系
 *  对这些调用日志进行收集，进行简单的聚合操作后， 写入到NoSQL数据库中
 *  使用traceId就可以从NoSQL数据库中跟踪整个请求的链路，并得到各个链路的耗时

**注意**：由于一次客户端调用会导致很多次的微服务之间的调用，所以调用日志的量是巨大的。我们可以在收集调用日志后，进行一些简单的**聚合**操作，来减少日志量，或者通过**采样**的方式，只采样1%的调用日志。

##### 配置管理 #####

项目所使用的一些配置文件的管理。

将配置做成文件，这样是静态的配置。将配置放到一个服务上，这样可以实现动态的配置管理和更新。

配置主要分为两种：

*  静态配置：比较固定的，不会经常发生变动的配置。比如数据库地址
 *  动态配置之：可能会经常发生变动的配置。比如超时时间。

静态配置通常放在项目的配置文件中即可，而动态的配置则通常放到配置服务中。

**选型**

1.  zookeeper，etcd，consul
2.  apollo（携程），diamond（淘宝），disconf（百度），都是以mysql为存储
3.  vintage（微博），以redis为存储

##### 服务容错 #####

一个系统拆成了多个服务。原本只有1个可能出现问题的点，现在变成了多个。

当系统出现未知问题，或者系统流量超出极限时，要如何应对？常见方式如下

*  熔断：当下游服务不可用时，暂时屏蔽下游服务，以保障整体服务可用的方法
 *  降级：当流量激增时，对于某些页面或者服务，暂时屏蔽，以减轻服务器压力的方法
 *  限流：限制瞬时大流量以保护整体服务的方法

**选型**

*  hystrix
 *  sentinel（阿里）
 *  dubbo

##### 负载均衡 #####

为了应对大流量，通常对于一个服务会部署多台节点。那么此时就需要将流量分配到多个服务节点。

常见负载均衡算法

*  一致性哈希
 *  随机
 *  轮询（加权轮询）
 *  最少连接（选择当前连接数最少的节点）

##### 服务监控 #####

从运维上对服务进行监控。

通常关注2个方面：需要监控什么？怎么监控？

**服务监控的指标**：

*  请求量：接口请求量，缓存请求量，数据库请求量
 *  响应时间：接口响应时间，缓存响应时间
 *  错误率：调用第三方服务错误率

**监控系统构成**

*  数据采集：flume，filebeat
 *  数据处理：storm，spark
 *  数据存储：mysql，hbase，influxDB
 *  数据展示：grafana

#### RPC实例分析 ####

以dubbo为例，进行分析

*  dubbo的微内核架构是如何设计的
 *  dubbo是如何调用服务的
 *  dubbo内嵌的服务治理策略是怎样的

##### dubbo介绍 #####

*  dubbot是一款高性能的**服务框架**
 *  在2021年由阿里开源
 *  2018年，阿里将dubbo捐赠给Apache
 *  借鉴dubbo的RPC框架还有dubbox（当当），motan（微博）

##### dubbo架构特点 #####

*  微内核+扩展点架构
 *  微内核负责组装扩展点，实现整体逻辑
 *  扩展点可以让功能点被用户自定义实现

dubbo的扩展点是通过SPI（Service Provider Interface）机制实现的（借鉴了JDK的SPI机制）。dubbo会从以下目录加载实现类

*  `META-INF/services/*`
 *  `META-INF/dubbo/*`
 *  `META-INF/dubbo/internal/*`

格式：`key=实现类的全限定名`

在代码中即可通过这个`key`来加载某个接口的某个特定的实现类

##### dubbo的服务调用 #####

略

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oqg6ISa55qE5aSn54Gw54u8_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/4f44ff8fae9e4269a5aabc6237b22044.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oqg6ISa55qE5aSn54Gw54u8_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/94d1c1df7679445ab31eabd2aa773fa6.png