负载敏感管理技术（轻量级限流频控组件-MOAT）
负载敏感管理技术（轻量级限流频控组件-MOAT）对于功能集，目前已实现如下功能：基于以上的背景需求，对 Moat 频控组件做了相关规划，确定其实现目标。整体是对于限流频控，能做到多维度控制、轻量级、可扩展、自闭环。包括配置规则策略、风险发现、加入黑名单、限制请求、释放黑名单五个环节，各环节的交互流程：二、背景业务中对限流的需求主要有以下几个方面：三、目标
一、前言
随着 WOS 用户量的不断增长，系统稳定性对于我们至关重要，特别是在系统流量暴增时，限流频控无疑是一种保证系统正常运转行之有效的方式。
另外，对于非法请求的恶意流量（如刷单），除了安全层面的防护外，业务侧针对业务属性的频控也是非常有必要的。
为满足公司日常业务场景中，对限流方式多样化的需求，我们推出了一款轻量级限流组件 MOAT 。本文将从背景需求与目标、设计方式、具体实现，为大家逐一介绍。
二、背景
业务中对限流的需求主要有以下几个方面：
- 业务维度，即业务需求，如在开放平台 API 多维度限制单位时间访问量；
- 系统稳定性维度，是保护应用的措施，防止过载；
- 异常业务流量，针对特定场景的异常请求做限制，并需要进行自动拉黑处理或自定义后置处理，来实现整体频控闭环。
三、目标
基于以上的背景需求，对 Moat 频控组件做了相关规划，确定其实现目标。整体是对于限流频控，能做到多维度控制、轻量级、可扩展、自闭环。包括配置规则策略、风险发现、加入黑名单、限制请求、释放黑名单五个环节，各环节的交互流程：
- 业务侧按需配置规则策略；
- 通过规则策略驱动对请求进行拦截；
- 若触发拦截，则进行后置处理，如“加入黑名单”（此处可业务侧自行扩展）；
- 若触发拦截，将根据规则对后续相同规则的请求进行拦截，如在指定黑名单时间内拒绝访问；
- 释放后置处理拦截，以便继续接收其流量；
对于功能集，目前已实现如下功能：
四、技术方案
4.1 整体技术方案
4.1.1整体架构
在设计中，我们整体分为四层:
- 接入层: 支持HTTP、Dubbo的自动接入，同时支持 API编程式接入；
- 逻辑层：频控的逻辑实现，包括拦截检查、频控计算、触发处理、拦截释放；
- 数据层：根据业务方集成方式的差异，支持多种存储介质，用来存储计算的中间数据和拦截成功后的结果数据。集群模式下， 使用的是业务方的 Redis 实例，作为存储介质，减少应用间的干扰， 单机版则直接使用本地内存；
- 日志层: 通过Cat 记录过程中的结果数据。用以分析被拦截目标，用户行为等；
4.1.2 整体流转图
业务请求时，Moat SDK 通过实现 HTTP 与 Dubbo 的 Filter 拦截了请求，并对请求的资源判断是否需要拦截。先通过配置，判断请求资源是否是 MOAT 管理端已发布的资源，如果不是已发布资源，将进入图上 “3.2”的步骤， Filter 直接退出；若存在已发布资源，将进入"3.1" MOAT SDK 内部的拦截处理链路。通过资源上配置的规则、规则阈值统计计算结果， 若已达到配置的规则， 则会进行后置的拦截操作后， 响应结果，若未达到，则放行，进入后续的业务逻辑处理后响应结果。
4.2 具体实现
MOAT的具体实现可以分为管理端和客户端两个模块，管理端提供了应用的接入管理、配置、发布与下线等功能；而客户端提供了频控规则的加载、规则同步和频控的逻辑实现。之所以需要管理端，是因为功能越丰富，可配置项越多，配置将越复杂。单纯依赖 Apollo 的公共命名空间来管理配置，其维护和使用成本较高。
4.2.1 管理端
管理端主要是负责应用的接入，频控资源的配置与发布等功能，具体的功能说明和步骤如下：
1、应用入驻接入频控的应用，首先需要在MOAT 后台完成应用入驻，并分配可以对应用配置频控资源的相关人员的权限。APPID 和接入方的业务应用中的保持一致即可。
2、资源管理
资源管理是为更好的管理频控资源生命周期而生的。一条频控资源的完整历程是创建、发布灰度、发布基准、下线 。因为 MOAT 早期版本是基于 Apollo 来配置规则和资源的，潜在的问题是使用上会受 Apollo 配置长度的限制，例如值的字符长度最大2W。这在我们实际业务场景中，当会有规则过多超过这个限制的场景，此时 Apollo 就无法满足我们的配置需求。
早期版本是基于 Apollo 来配置，潜在的问题是使用上有一些配置限制，例如值的字符长度最大2W。
3、多环境发布应用频控资源、规则的管理，通常都需要经过测试、灰度、发布基准的过程，以保证变更的业务安全性。此处与开发者平台存在关联，环境标识对应的是开发者平台中多环境的标识，通过设置与灰度环境相同的环境标识，就可以在对应的灰度 POD 上来验证我们的规则。这里使用了基础架构提供的调用链上下文，来获取当前POD所在的环境标识。资源匹配的时候，优先获取到当前POD所在的环境标资源，来达到资源灰度的目的。在灰度完成验证的规则，即可继续完成资源发布上线。
1、客户端整体交互流程
客户端的交互大致可以分为三个阶段: 启动、调用、规则变更，交互的时序图如下。
- 【应用启动】：接入组件的业务方应用，会在启动时和Moat管理端通信，完成规则的拉取与加载，并初始化到内存， 另后续会每隔 1s 交互一次，以保证客户端的配置的时效性，详见【规则变更】。
- 【业务调用】：当业务调用时，进入SDK处理流程，根据加载的规则资源，判断是否需要处理。
- 【规则变更】：当应用管理员在 MOAT 管理端修改并发布规则时，客户端的定时更新模块，会更新最新发布资源到本地，完成资源变更的热更新。
- 【解析请求】获取请求资源，判断该资源，是否是资源管理端，已发布的需要频控的资源。
- 【解析模型】根据规则定义的拦截维度，获取对应入参\出参模型上的字段，并拼装成规则实例数据。
- 【验证请求】通过解析的规则实例数据，校验实例数据，是否已经被拉黑，是否已经达到请求窗口上限。
- 【请求累计】基于选择的算法(固定窗口、滑动窗口)累计请求数据。
- 【计算日志】处理过的请求，和被拦截的请求，将记录在CAT。
当应用管理员发布规则后，便会触发规则的更新。完整的规则更新过程如下图所示。
Moat 客户端除了基于 Filter(WebFilter/DubboFilter) 的自动调用外， 还提供了编程式接入的方式，通过 Moat 客户端提供的静态类 Moat，业务方可以构建一个 EntriesDTO 的频控请求模型，通过调用 Moat 的 entry 相关方法，即可完成对本次请求的统计及异常拦截处理。若触发异常拦截，则会抛出异常，业务可以通过捕获被频控时的异常，来进行业务后置处理。也可以通过获取执行返回结果中的拦截状态，来判断是否拦截。
try{
// 资源名可使用任意有业务语义的字符串
EntriesDTO entriesDTO = EntriesDTO.builder().resourceName("自定义资源").args(new Object[]{avg}).build();
Moat.entryWithException(entriesDTO);
// 被保护的业务逻辑
// do something...
} catch (MoatBlockException e1) {
// 资源访问阻止
// 进行相应的处理操作，限流或降级
} finally {
// todo yourself code.
}5、结果观测
目前主要是通过公司的监控系统CAT来进行观测，包括处理过的请求，以及被拦截的请求。观测内容中包含触发的拦截类型、拦截的对象、具体的调用链等，业务方能以此来作为分析原因的切入点。
同时，通过CAT数据看盘，可以看出来资源级被拦截的比例，通过这些数据，业务方可以优化资源的频控配置，以便做到有效的频控拦截，保护应用和业务。
五、实践
在接入的交易应用中，对频繁操作的异常流量采取了有效防控。在直播、秒杀场景中，用户在该阶段的抢购行为颇多，高频率的点击，导致在单位时间内的请求激增。通过用户 ID 级别的频控，保证了无效请求不再浪费系统资源。在交易域的实践，我们通过数据分析，被拦截的流量分布如图所示:
拦截详细数据，可以看到每天的处理量级在百万级，拦截率在0.23%上下，在 CAT 上的体现如图所示，处理请求总量 MOAT_PROCESS_TOTAL。
触发拦截总量 MOAT_INTERCEPTED_TOTAL，明细数据是被拦截的资源实例和被拦截次数。
六、未来规划
从各业务实际使用反馈来看，在后续版本中我们会在几方面迭代优化。
1、更轻量：减少依赖，支持单机模式。
2、增强拦截算法：为应对不同的流量特性，支持限流算法的可配置。
3、强化观测能力：支持多种方式的观测数据上报，以便应用可以根据现状选择合适的策略。
4、启动开源计划：建立开源生态，共同维护，进一步丰富场景和能力。
本文主要从业务场景、设计方案、实现细节、以及业务实践这几方面介绍了Moat
其中有些地方还可以有进一步的提升，欢迎感兴趣的同学一起交流。
作者:吴启猛
来源:微盟技术中心
出处:https://mp.weixin.qq.com/s/Rx3V8ZtVBy5YmWwKU6vtYg
