运维体系建设(稳定性保障体系20)

运维体系建设(稳定性保障体系20)

（本字共2344字，大约需要阅读6分钟）

负载管理——流量管理

流量管理方法大致可以分为服务开关管理、请求质量管理、处理后端错误三部分。

图 88 服务开关

服务开关是关于业务和功能层面上的控制，是针对单个功能的启用和停止控制，或者将功能状态在不同版本之间进行切换的控制，一般通过降级、限流、旁路、熔断4种方法来实现。

限流和降级是基于业务功能层面的，指预计系统容量会到达极限、防止过载，设计的流量限流功能，以及可以关闭掉非核心功能，只保留核心链路的核心功能的功能降级机制。也称为业务开关。这是一个动态调测和完善的过程，对于动态变化的资源是无法一劳永逸的。一方面我们要依赖人的经验；另一方面，当调用次数和日志达到一定体量时，可以借助机器学习算法的手段，来分析什么样的设置是最合理的。

限流降级不可能通过人工控制，需要开发对应的限流降级的控制台，将各种配置和策略通过界面的方式进行管理，同时在配置完成之后，能够同步到对应的服务实例上。

旁路和熔断是基于功能模块层面的、被动配置的故障应对手段。

降级也称为服务降级或主动降级，熔断也称为被动降级。与业务开关对应的，旁路也称为功能开关。今天我们就先聊一下限流的内容。

限流

图 89 限流

对于超出某个应用或基础部件的某些核心指标（CPU使用量、队列长度、QPS、内存使用量、连接数等等）来决定是否将后续的请求进行拦截并进行流量抛弃，直接针对新请求返回服务不可用（如HTTP503）的方法，称为限流。

流量抛弃（load shedding）：指软件服务器临近过载时，主动抛弃超出系统承诺容量的负载，避免该软件服务器出现内存超限、健康检查失败、延迟大幅升高，或者其他过载造成的现象，保证系统的核心功能能够正常运行。

限流解决方案分为接入层限流、中间件限流、基础服务限流。

1、接入层限流

接入层限流分为网络层限流、Nginx限流、API 路由网关限流等形式，是一种服务器在实际处理用户流量之前进行的最粗颗粒度控制，也就是传统意义上的网络限流。

当系统需要与第三方发生交互，既需要暴露给外部系统调用的公开API，同时也需要调用外部的API实现自身的业务需求，则处理服务之间访问的授权和认证，安全和性能的监控，缓存和日志的处理，超时的Retry，负载和熔断的处理，查询请求的聚合等等一系列的问题的中间层或间接层(Gateway)称为API网关。没有配置API网关，会出现客户端与服务器端耦合、多次请求、安全问题、横切关注点等问题。

横切关注点问题：每个公开发布的服务都必须处理诸如授权、SSL等问题。对于客户端模式的接入，使用API 路由网关模式，一方面可以更方面地管理客户端与服务端的链接，另一方面也可以通过配置的方式管理服务接口。

网络层限流一般只能使用一些网络协议层的静态属性，如Qos等。Nginx限流可以设置 QPS、并发数、CPU 的 Idle 作为限流指标。Nginx 有对应的函数接口，可以获取到以上指标信息，然后通过 Lua 脚本实现限流的逻辑。

2、基础服务限流

基础服务限流主要针对数据库、缓存以及消息等基础服务组件的限流而设定。限流逻辑会配套分布式数据库中间件，缓存或消息的框架来实现。

基础服务限流的参数如配置不全，会造成频繁触发限流，影响正常业务运行。具体参数包括资源、策略、时间精度、指标计数、限流方式等。

资源：是我们要进行限流的对象，可能是一个应用，或者一个方法，也可能是一个接口或者 URL。

策略：就是限流的规则，如 QPS 和并发数限流。

时间精度：指对于 QPS、并发数或 CPU 的阈值判断。如对于QPS设定一个 QPS 时间精度(N秒)，如果低于阈值则不启用策略，如果超过阈值就启动限流策略。

指标计数：对于并发限制请求，会统计当前的并发数。对于 QPS 限流，需要考虑突发流量问题，统计 QPS 不能按照秒统计，因为第1s，系统可能就已经超负载了，所以 QPS 得按照毫秒级别去统计，统计的级别越小，性能损耗越大，定在 10ms~100ms 的级别去统计会更平滑一些。计算当前的 QPS，只需要将当前时间所在份的计数和前面 9 份的计数相加，内存里面需要维护当前秒和前面 2 秒的数据。

限流方式：对于 Nginx 就针对总的请求进行限流即可，但是粒度会比较粗。对于应用层，因为配置中心的灵活性，其限流就可以做得更细化。比如可以针对不同来源限流，也可以针对去向限流，粒度上可以针对类级别限流，也可以针对不同的方法限流，同时还可以针对总的请求情况限流，这些灵活策略都可以在微服务的配置中心实现。

3、中间件限流

Spring AOP：对于 Java 应用Spring 框架。Spirng 框架中的关键技术点，就是 IoC 和 AOP，通过配置需要限流的方法作为 AOP 的切入点，设定Advice 拦截器，在请求调用某个方法，或请求结束退出某个方法时，进行上述的各种计数处理，同时决定是否要进行限流，如果限流就返回约定好的返回码，如果不限流就正常执行业务逻辑。基于 AOP的技术原理，可以开发出与业务逻辑无关的限流组件，通常会在对外的服务调用、数据库调用、缓存调用、消息调用这些接口方法上设置默认的切面，并在业务代码运行时注入，这样就可以做到对业务透明，无侵入性。

Web 类型的限流：对于 Web 类型 URL 接口限流，利用 Servlet 的 Filter 机制进行控制即可。

限流的优化思路：

队列模型：将先入先出（FIFO）队列模式改为后入先出（LIFO）堆栈模式。用户刚访问就返回拒绝服务比让用户等待一会儿再拒绝服务，不管从服务器成本上还是用户体验上都是利大于弊的。可控延迟算法（CodDel）：避免处理那些不值得处理的请求。如果某个用户的请求已经等待了很久，那么很有可能该用户已经放弃回复并进行了重试，这时回复该请求已经没有任何意义。