如何利用 “集群流控” 保障微服务的稳定性？

作者：宿何

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

流控是保障微服务稳定性最常用也是最直接的一种控制手段。每个系统、服务都有其能承载的容量上限，流控的思路非常简单，当某个接口的请求 QPS 超出一定的上限后，拒绝多余的请求，防止系统被突发的流量打垮。市面上最常见的方案是单机维度的流控，比如通过 PTS 性能测试预估某个接口的容量上限是 100 QPS，服务有 10 个实例，则配置单机流控 10 QPS。但很多时候，由于流量分布的不确定性，单机维度的流量控制存在一些效果不佳的情况。

典型场景 1:精确控制对下游的调用总量

场景： 服务 A 需要频繁调用服务 B 的查询接口，但服务 A 和 B 的容量存在差异，服务 B 约定最多给服务 A 提供总共 600 QPS 的查询能力，通过流控等手段进行控制。

痛点： 若按照单机流控的策略配置，由于调用逻辑、负载均衡策略等原因，A 调用 B 到达每个实例的流量分布可能非常不均，部分流量较大的服务 B 实例触发单机流控，但总体限制量尚未达到，导致 SLA 未达标。这种不均的情况经常会发生在调用某个依赖服务或组件（如数据库访问）的时候，这也是集群流控的一个典型场景：精确控制微服务集群对下游服务（或数据库、缓存）的调用总量。

典型场景 2：业务链路入口进行请求总量控制

场景： 在 Nginx/Ingress 网关、API Gateway (Spring Cloud Gateway, Zuul) 进行入口流量控制，希望精确控制某个或某组 API 的流量来起到提前保护作用，多余流量不会打到后端系统。

痛点： 如果按照单机维度配置，一方面不好感知网关机器数变化，另一方面网关流量不均可能导致限流效果不佳；而且从网关入口角度来讲，配置总体阈值是最自然的手段。

AHAS 集群流控

AHAS 集群流控可以精确地控制某个服务接口在整个集群的实时调用总量，可以解决单机流控因流量不均匀、机器数频繁变动、均摊阈值太小导致限流效果不佳的问题，结合单机流控兜底，更好地发挥流量防护的效果。

对于上面的场景，通过 AHAS 集群流控，无论是 Dubbo 服务调用、Web API 访问，还是自定义的业务逻辑，均支持精确控制调用总量，而无关调用逻辑、流量分布情况、实例分布。既可以支撑数十万 QPS 大流量控制，也支持分钟小时级业务维度小流量精确控制。防护触发后的行为可由用户自定义（如返回自定义的内容、对象）。

AHAS 集群防护具有以下几大优势：

场景丰富： 全面覆盖从网关/Mesh 入口流量精确防护、Web/RPC 服务/SQL 调用精确流控，到分钟小时级业务维度流量控制的场景，支持数十万 QPS 量级；
低使用成本： 无需特殊接入方式，开箱即用，快速配置；
全自动管控与运维： 自动化管控与分配 token server 资源，自动化运维能力保障可用性，用户无需关注服务端资源准备与分配，只需关注规则配置与业务流程；
低性能损耗： 性能模式下对业务链路完全无时延增加，精确模式对业务链路的 RT 损耗控制在 3ms 之内，用户可放心使用；
配套的可观测能力， 实时了解接口稳定性与规则生效情况。

下面我们就来用一个示例来介绍一下，如何快速将应用接入 AHAS 来玩转集群流控能力，保障服务稳定性。