如何利用 AHAS 保障 Web 服务稳如磐石？

简介：应用高可用服务 AHAS (Application High Availability Service) 是经阿里巴巴内部多年高可用体系沉淀下来的云产品，基于阿里开源流控降级组件 Sentinel，以流量与容错为切入点，从流量控制、不稳定调用隔离、熔断降级、热点流量防护、系统自适应过载保护、集群流控、服务防抖动等多个维度来帮助保障服务和网关的稳定性，同时提供秒级的流量监控分析功能。

作者：宿何

微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。应用高可用服务 AHAS (Application High Availability Service) 是经阿里巴巴内部多年高可用体系沉淀下来的云产品，基于阿里开源流控降级组件 Sentinel，以流量与容错为切入点，从流量控制、不稳定调用隔离、熔断降级、热点流量防护、系统自适应过载保护、集群流控、服务防抖动等多个维度来帮助保障服务和网关的稳定性，同时提供秒级的流量监控分析功能。AHAS 不仅在阿里内部淘宝、天猫等电商领域有着广泛的应用，在互联网金融、在线教育、游戏、直播行业和其他大型政央企行业也有着大量的实践。

在分布式系统架构中，每个请求都会经过很多层处理，比如从入口网关再到 Web Server 再到服务之间的调用，再到服务访问缓存或 DB 等存储。在高可用流量防护体系中，我们建议在流量链路的每一层都进行针对性的流量防护与容错手段，来保障服务的稳定性。上一期我们介绍了如何在 Nginx/Ingress 网关层接入 AHAS Sentinel 来进行前置流量防护，本篇文章我们来介绍一下在 Web 应用层进行细粒度的高可用流量防护。

Web Server 场景

AHAS 应用防护支持 Java/Go 等多语言原生接入，支持主流的 Web 框架与组件：

Java 支持 Spring Web/Spring WebFlux/Spring Boot/Spring Cloud/Tomcat/Jetty/Undertow 等主流 Web 框架
Go 支持 Gin, echo 等框架

每个服务都有一个能承载的最大请求容量，这个容量通常压测进行评估。在突发激增流量的场景下，我们需要针对核心 Web API 配置流控规则，来保障系统流量处于有效的处理能力之内，避免被打垮。同时，Web 流量通常具有非常多的业务属性与参数，如 IP、用户 ID、商品 ID 等，许多请求都具有一定的热点特性，比如一大波请求针对某个热点商品。由于流量具有不确定性、不可预测的特性，我们无法准确预知流量的量级、分布、热点访问情况，很难针对性地针对某个突发业务提前预判并配置防护，因此自动识别热点请求能力也是非常重要的。

AHAS Web 场景流控[1]不仅支持 URL path 维度的流控，还支持针对 client IP、host、header、请求参数等进行细粒度热点流量控制。我们只需要在配置 Web 流控规则时，指定针对哪个请求属性进行热点流控（如 key 为 UserId 的 header），那么 AHAS 就会自动分析请求中对应请求属性的值（如 header 的 value），自动统计出 top N 热点访问的参数并分别进行请求量控制。通过这种维度的控制，我们可以在 Web 服务端实现 IP 防刷、热点商品防刷等一系列的细粒度高可用防护策略，甚至可以实现每个用户每个 API 每分钟限制访问 N 次这种具有业务含义的流量管控策略。

Web Client 场景

除了 Web 服务端入口流量控制之外，AHAS Sentinel 还提供常用 Web Client 的适配，如 OkHttp、Apache HttpClient 以及 Spring RestTemplate。基于 Web Client 适配模块，我们可以针对 HTTP 客户端调用其他接口的时机进行防护，来保障调用端不会被慢接口或异常接口拖垮：

当 Web 调用端调用某个接口非常慢，且请求量很大时，若不加以控制，那么慢调用会挤占整个连接池，导致其他正常服务的调用也被阻塞，自身处理请求的能力也被拖垮。此时可以利用并发控制规则[2]通过控制 API path 的并发线程数（即同时发起调用的数目），来保证调用端的可靠性，防止连接池被占满。
当 Web client 调用的某个接口持续出现慢调用或异常，也可以利用 AHAS 熔断规则[3]进行进一步的保护。熔断规则提供熔断器的能力，在某个 API path 出现慢调用或持续异常达到一定比例后，在一段时间内，自动熔断针对该接口的调用，并直接返回预设的降级信息。通过熔断机制，一方面可以防止调用端被不稳定第三方接口拖垮，另一方面也给不稳定接口一些恢复的时间，避免持续调用导致服务进一步劣化。
当 Web Client 调用接口时出现偶现的超时等非致命性错误时，可以通过自动重试规则[4]来保障业务成功率，避免业务产生抖动。

熔断规则与并发控制规则是保障调用端稳定性的有效手段，无论在 Web client 场景还是慢 SQL 场景都非常适用。

快速玩转 AHAS Web 场景防护

第一步，我们将 Web 服务接入 AHAS 流量防护。AHAS 提供多种快速便捷的无侵入接入手段：

以普通 Spring Boot Web 服务为例，接入 AHAS 成功后，只要触发服务调用/接口访问，即可在 AHAS 控制台[5]看到自己的服务，并可以在 Web 场景页面看到自己的 Web 接口。默认 Spring Boot 应用接入会提取 controller 中的 URL path 作为资源名称：

我们可以在监控页面非常直观地观测各个接口的实时流量与响应时间情况，以便于我们评估系统的稳定性。

第二步，我们给其中一个接口配置 Web 流控规则[6]。在我们的示例中，我们针对 /hello 这个 API，配置热点参数流控。流控的请求属性为 name 这个请求参数（URL params），流控策略为每个热点参数分别限制每秒访问量最多 1 次。AHAS 会自动提取每个 /hello 请求中的 name 参数对应的值，自动分析出其中 top K 频次的热点值，然后分别对每个热点值进行控制，不超过规则中的访问次数。

效果示例：假设请求中有许多针对 /hello 接口的访问，其中 /hello?name=A 和/hello?name=B 两个 name 参数的访问频次非常高，被 AHAS 统计统计为热点值。那么上面的流控规则会针对 name=A 和 name=B 这两个参数值的请求，分别限制每秒访问量不超过 1 次。

第三步，我们给上面的 Web 流控规则绑定一个 fallback 行为[7]，即指定触发该规则后，Web 接口的返回内容。我们可以在页面中自定义 Web 返回行为。以下是一个返回 429 状态码的 JSON 返回配置示例：

配置完成后，我们可以在流程页面选择我们创建的 fallback 行为，然后保存，这样我们的规则就会实时生效了。

第四步，我们发起针对 /hello 接口的流量，并给 name 参数带上不同的值，可以从控制台的监控上面看到请求触发了流控：

同时被流控的热点请求返回值也与我们在控制台定义的 fallback 返回相对应：

在生产环境，我们这些参数的值可能非常多，比如商品 ID 可能有上千万个。在热点请求被流控后，我们通常希望能够知道有哪些 top 参数被限制，方便我们了解业务的请求情况。AHAS 近期新上线热点监控功能，提供热点参数可观测的能力，结合 top 参数热力图，可以非常直观地在控制台了解实时业务情况：

以上就是一个简单的 Spring Boot Web 场景流控的示例，欢迎大家在 AHAS 控制台体验，有关 Web 场景防护的更多信息可以点击此处，查看参考文档。