流控验证太麻烦？不敢上生产？MSE 有办法！

作者：涯客

影响服务稳定性的因素有很多，其中比较常见但又往往容易被忽视的就是面向流量的稳定性，流控是保障服务稳定性的重要手段。但是，我们发现大量客户仅仅在开发环境和预发环境中测试流控，却在生产环境中鲜有使用。根据深入的交流，发现问题主要在二方面：

第一：对于首次发布的服务，由于无法精确预测真实流量的大小，往往无法给出合理的限流条件，这给流控的实施带来了很大的挑战。
第二：对于已经上线的服务，直接对正在运行的业务进行流控可能会导致业务宕机或请求错误，进而影响用户体验。部分拥有能力的客户，会在测试环境中模拟生产环境中流量，从而验证流控的正确性，进而在生产环境中实施。这最大的问题是验证成本较高，验证流程较长，而且测试环境无法完全还原生产环境中流量情况。

我们可以归纳以上的问题为一点：如何在不影响生产业务的情况下，小成本验证流控能力，进而在生产环境中实施流控。

在不验证的情况下，直接在生产环境中生效流控规则，很有可能让解决灾难的办法成为灾难本身，例如流控规则配置错误、流控没有达到预期、流控无故生效导致业务宕机等等，这些问题在生产环境中是完全无法接受的。

那么有什么办法能够在生产环境中小成本、快速地验证流控能力？能够在生产环境中确定配置的流量防护策略是否合理？一个简单的思路就是只对线上一部分的流量进行流控验证，即在可控范围内做流控验证。

基于这一想法，我们使用微服务引擎(MSE)中热点参数防护的功能，提出了一种合理的解决方案：首先在生产环境中进行可控范围内的流控能力验证、确定流控合理配置，进而在生产环境中启用流控。

在这里插入图片描述

MSE微服务治理简介：微服务治理中心无侵入增强主流Spring Cloud、Apache Dubbo和Istio等开源微服务框架，提供丰富的服务治理和流量防护功能，将中间件与业务解耦，拥有如下功能：无损上线、无损下线、全链路灰度、流量控制、离群实例摘除等。

验证思路

我们将会按照以下顺序验证所提出方案的可行性：

搭建基础场景用于模拟生产环境。
配置相应的流控规则，用于能力验证。
流量测试。

在这里插入图片描述

基础场景搭建

我们使用MSE服务治理中热点参数防护功能来实现生产环境可控的流控能力验证。

本文以常见的长链路调用场景为例，介绍生产环境下进行可控范围内的流控能力验证的过程，搭建的具体流程不再介绍，可详见MSE产品help文档 [ 1] 。

模拟场景使用如下后端场景，后端共有3个服务：应用A、应用B、应用C。这3个服务之间通过MSE Nacos注册中心实现服务发现。客户可以通过客户端后者HTML来访问后端服务。客户的请求到达网关后，调用链路为：用户>MSE云原生网关>A>B>C。

说明：我们的要求是对于指定带标签的流量，任何配置相应流控规则的应用都应起到流控作用。对于从网关到应用A的流量，因携带标签，热点参数防护功能可以生效。但是对于应用A至应用B的流量，会丢失流量中的标签，我们需要额外标签透传的功能，才能保证应用B得到携带标签的流量，从而使得热点参数防护功能可以生效。

在这里插入图片描述

名词解释：

MSE云原生网关：MSE云原生网关是兼容K8s Ingress标准的下一代网关产品，支持ACK容器和Nacos等多种服务发现方式，支持多种认证登录方式快速构建安全防线。更多信息，请参见云原生网关概述 [ 2]
带标签请求：请求中的header带指定kv
标签透传请求：正常的RPC请求，即应用A到应用B的请求是不会携带前置请求的header信息。如果是标签透传，前置请求中指定header将会携带后续的请求中

流控配置

我们希望仅仅对线上可控范围内的流量进行流控验证，比如用户等级比较低的请求流量，或者是内部用户的测试流量，从而在不会对线上的服务造成影响的前提下足够地验证流控能力。

我们模拟如上场景，标识特定的流量请求header中加入key为limit，value为true的参数值，特定的流量会被流控规则所控制最大请求范围，并且保证正常的请求流量不会受到任何影响。

然后我们对应用A、应用B加入热点参数防护，用于后续方案可行性验证。该操作对header含有limit:true的请求进行流控，为了效果明显，设定流控生效的qps阈值为20（即qps超过20时，请求将会被拒绝）。

在MSE服务治理中，为应用配置热点参数防护的具体过程如下。

3.1 应用A流控规则配置

我们只需在mse服务治理页面配置如下热点参数防护能力，就能实现针对特定流量的流控配置。

在应用a中依次选择 选择流量 > 流量防护 > 热点参数防护(HTTP请求) > 新增热点参数防护。

在这里插入图片描述

2.为接口/a加入如下配置防护规则。

在这里插入图片描述

针对指定的请求配置流控规则，比如下图所示header值为limit且value为true的流量会被当前配置的流控规则控制最大的QPS阈值20。

在这里插入图片描述

3.2 应用B流控规则配置

应用B按照应用A一样配置。

在应用b中依次选择 选择流量 > 流量防护 > 热点参数防护(HTTP请求) > 新增热点参数防护。
为接口/b加入如下配置防护规则。

在这里插入图片描述

针对指定的请求配置流控规则，比如下图所示header值为limit且value为true的流量会被当前配置的流控规则控制最大的QPS阈值20。

在这里插入图片描述

流量测试

在配置完成后，为了模拟生产环境，我们将会依次发送正常请求、被标记请求，检验流控对正常请求和被标记请求是否生效。

我们首先根据如下步骤，获取入口地址：

登录MSE网关管理控制台，并在顶部菜单栏选择地域。
在左侧导航栏，选择云原生网关 > 网关列表，单击目标网关名称。
在左侧导航栏，单击基本概览。
在网关入口页签，查看SLB的入口地址（ip）。

在获取入口地址之后，我们将会对/a接口依次进行如下流量测试。

4.1 正常请求无流控

向/a接口持续发送无标签的请求。
可在输出中发现请求没有任何限制，均是正常返回，返回如下。

A[192.168.0.98] -> B[192.168.0.57] -> C[192.168.0.56]

4.2 被标记请求应用A流控生效

向/a接口持续发送含标签请求(header含有limit:true)。
当qps超过20时，请求出现限流信息，限流信息如下。

Blocked by Sentinel (flow limiting)

4.3 被标记请求应用B无流控

关闭A服务的流控限制。
向/a接口持续发送含标签请求(header含有limit:true)。
可在输出中发现请求没有任何限制，均是正常返回，返回如下。

A[192.168.0.98] -> B[192.168.0.57] -> C[192.168.0.56]

说明：如果没有开启标签透传，应用A调应用B的请求无法将header透传。从而无法满足对于指定带标签的流量，任何配置相应流控规则的应用都应起到流控作用的效果。

4.4 配置透传，被标记请求应用B流控生效

为应用A配置header透传。在k8s集群中寻找到spring-cloud-a服务，在环境变量中加入变量名称:alicloud.service.header ，变量引用：limit。

说明：MSE服务治理使用agent技术，可以使得流量中的header透传

在这里插入图片描述

向/a接口发送含标签请求(header含有limit:true)。
当qps超过20时，请求出现限流信息，限流信息如下。(报错是因为A没有拿到B的正常信息)。

{"timestamp":"2023-04-24T06:35:46.835+0000","status":500,"error":"Internal Server Error","message":"429 null","path":"/a"}

说明：在配置标签透传情况下，可满足对于指定带标签的流量，任何配置相应流控规则的应用都应起到流控作用的效果。

总结

到目前为止，我们通过MSE的热点参数防护与自定义header透传能力的组合，实现了仅针对有特定标识流量的流控能力。这使得我们可以在不影响业务的情况下，在生产环境中做可控范围内的流控能力验证。相较于另外搭建整套预生产环境来验证流控能力来说，该方案的成本更低，且更能直接验证到生产环境中流控规则以及流控后的 Fallback 行为的表现，做到真正的心中有数。

在本文中我们仅仅使用了MSE服务治理中的流量控制功能。然而对于微服务架构来说，生产场景中的每一个组件、每一个环节都至关重要。MSE微服务治理提供微服务各个环节的治理解决方案，旨在帮助企业快速落地完整且健壮的微服务体系。MSE服务治理可以在不修改任何代码和配置的情况下，降低微服务治理的成本，实现以下多种功能：