13、架构-流量治理之流量控制

概述

任何一个系统的运算、存储、网络资源都不是无限的，当系统资源不足以支撑外部超过预期的突发流量时，便应该有所取舍，建立面 对超额流量自我保护的机制，这个机制就是微服务中常说的"限 流"。

最大处理能力为80TPS的系统遇到100 TPS的请求时，应该能完成其中的80TPS，也即有20 TPS的请求失败或被拒绝才对，这是最理想的情况，也是我们追求的目标。但事实上，如果不做任何处理，更可能出现的结 果是这100个请求中的每一个都开始了处理，只是大部分请求完成了其 中10次服务调用中的8次或者9次，就会超时退出，导致多数服务调用 被白白浪费掉，没有几个请求能够走完整个业务操作。

为了避免这种状况出现，一个健壮的系统需要做 到恰当的流量控制，更具体地说，它需要妥善解决以下三个问题。

• 依据什么限流：对于要不要控制流量，要控制哪些流量，控制力度有多大等操作，我们无法在系统设计阶段静态地给出确定的结论，必须根据系统此前一段时间的运行状况，甚至未来一段时间的预测情况来动态决定。
• 具体如何限流：要解决系统具体是如何做到允许一部分请求通 行，而另外一部分流量实行受控制的失败降级的问题，就必须了解并 掌握常用的服务限流算法和设计模式。
• 超额流量如何处理：对于超额流量可以有不同的处理策略，例 如可以直接返回失败（如429 Too Many Requests），或者迫使它们进入 降级逻辑，这种策略被称为否决式限流；也可以让请求排队等待，暂时阻塞一段时间后再继续处理，这种被称为阻塞式限流。

流量统计指标

要做流量控制，首先要弄清楚到底哪些指标能反映系统的流量压 力大小。相较而言，容错的统计指标是明确的，容错的触发条件基本 上只取决于请求的故障率，发生失败、拒绝与超时都算作故障。

要进行流量控制，首先要明确哪些指标能够反映系统的流量压力大小。以下是几个经常用于衡量服务流量压力的主要指标：

1. 每秒事务数（Transaction per Second，TPS）：

   • 定义：TPS是衡量信息系统吞吐量的最终标准。"事务"可以理解为一个逻辑上具备原子性的业务操作。例如，在一个在线书店购买一本书并支付，"支付"就是一笔业务操作，无论支付成功还是不成功，这个操作在逻辑上是原子的。
   • 用途：TPS通常用于评估系统的处理能力和性能。它直接反映了系统在单位时间内能够处理的业务操作数量。

2. 每秒请求数（Hit per Second，HPS）：

   • 定义：HPS是指每秒从客户端发向服务端的请求数。它可以简单理解为每秒钟用户向服务器发送的请求数量。
   • 用途：HPS用于衡量系统接收请求的速率。在许多场景下，单个业务操作可能需要多个请求来完成，例如在支付过程中可能包括显示支付二维码、扫码付款、校验支付结果等多个步骤。

3. 每秒查询数（Query per Second，QPS）：

   • 定义：QPS是指一台服务器能够响应的查询次数。如果系统由多个服务节点共同协作处理请求，那么QPS用于衡量单个服务器的处理能力。
   • 用途：QPS常用于评估数据库或后端服务的查询处理能力。例如，一个支付请求可能需要后端多个服务节点的协作，每个服务节点处理不同的查询和操作。

这些指标提供了系统在不同层次上的流量压力评估，可以帮助我们制定合适的限流策略。

限流设计模式

限流是流量控制的重要手段，通过限制单位时间内允许的请求数，防止系统过载。常见的限流设计模式包括流量计数器、滑动时间窗、漏桶算法和令牌桶算法。

1. 流量计数器模式：

   • 原理：设置一个计数器，根据当前时刻的流量计数结果是否超过阈值来决定是否限流。例如，如果系统能承受的最大持续流量是80 TPS，可以通过控制任何一秒内的请求次数不超过80次来限流，超过部分则直接拒绝。
   • 优点：实现简单，易于理解和实现。
   • 缺点：只能针对时间点进行离散统计，容易在边界处出现流量突增。例如，如果系统连续两秒各收到60 TPS的请求，实际在1秒内的请求可能高达120 TPS，导致系统超载 。

2. 滑动时间窗模式：

   • 原理：将时间划分为多个小窗口，滑动统计每个小窗口内的请求数。例如，将每分钟划分为六个10秒的小窗口，通过滑动窗口统计60秒内的请求数。滑动窗口算法可以平滑流量，防止突发流量对系统造成冲击，因为它能在时间片段内均匀分布流量，避免了固定窗口计数器在边界处的突发流量问题。
   • 优点：平滑流量，防止突发流量对系统造成冲击。滑动窗口使得系统能够更加均匀地处理请求。
   • 缺点：实现复杂度较高，适用于需要精细控制流量的场景 。

3. 漏桶算法（Leaky Bucket）：

   • 原理：将请求视为水滴，通过一个漏桶进行流量控制。漏桶以恒定速度滴漏，请求进入漏桶的速度可以不恒定。如果请求速率超过漏桶的滴漏速率，多余请求会被丢弃。通过这种方式可以平滑流量，即使有大量突发请求，漏桶也会以恒定速度处理请求，防止系统过载。
   • 优点：可以平滑流量，防止突发流量对系统造成冲击。漏桶算法在流量整形和网络控制中应用广泛。
   • 缺点：实现复杂度较高，可能会丢弃重要请求，适用于需要严格控制流量的场景 。

4. 令牌桶算法（Token Bucket）：

   • 原理：系统维护一个令牌桶，按照固定速率向桶中添加令牌。每个请求需要消耗一个令牌，当桶中没有令牌时，新的请求会被拒绝或排队等待。令牌桶算法允许在短时间内处理大于固定速率的突发请求，因为令牌可以积累和消耗。
   • 优点：可以处理突发流量，灵活性较高。令牌可以积累，因此短时间内大量请求可以通过之前积累的令牌来处理。
   • 缺点：实现复杂度较高，适用于需要灵活控制流量的场景 。

分布式限流

在分布式系统中，限流不仅需要在单个节点上实现，还需要在多个节点之间进行协调，以确保全局流量控制的一致性。以下是几种分布式限流实现方式：

1. 集中式限流：

   • 原理：通过一个集中式的限流服务统一管理和协调各个节点的流量。所有节点的请求都需要经过该服务进行限流判断。
   • 实现方式：在系统中部署一个限流服务，所有节点的请求都需要经过该服务进行限流判断。
   • 优点：全局视角，易于统一管理和控制。集中式限流服务可以根据整体流量情况动态调整限流策略。
   • 缺点：限流服务本身可能成为单点瓶颈和故障点，适用于流量较小的系统。如果限流服务故障，整个系统的流量控制都会失效 。

2. 分布式令牌桶：

   • 原理：在各个节点上分布式地实现令牌桶算法，通过协调机制保证全局一致性。每个节点都有一个本地的令牌桶，这些令牌桶通过分布式一致性算法（如Raft、Paxos）进行协调和同步，确保整体流量控制的一致性。
   • 实现方式：在每个节点上设置令牌桶，通过分布式一致性算法进行协调和同步，确保全局一致性。
   • 优点：高可用性和扩展性，适用于大规模分布式系统。即使某个节点故障，其他节点仍能继续工作。
   • 缺点：实现复杂度较高，需要处理分布式一致性问题。分布式一致性算法的开销较大，可能影响系统性能 。

3. 一致性哈希：

   • 原理：通过一致性哈希算法将请求分散到不同的节点上，避免单个节点过载。每个节点只处理属于自己的请求，从而实现负载均衡。
   • 实现方式：在系统中设置一致性哈希环，根据请求的特征值计算哈希值，并分配到对应的节点进行处理。每个节点只处理分配给自己的请求。
   • 优点：负载均衡效果好，适用于分布式缓存、分布式数据库等场景。一致性哈希可以动态调整节点数，适应系统的扩展和收缩。
   • 缺点：需要处理节点新增和移除时的一致性问题。一致性哈希环的重新分布可能导致部分请求暂时失效 。

4. 服务网格（Service Mesh）：

   • 原理：通过服务网格架构，在服务之间添加一个中间层，用于管理和控制流量。服务网格通过Sidecar代理实现流量控制、限流、熔断等功能，提供统一的流量管理。
   • 实现方式：在每个服务实例前部署一个Sidecar代理，通过代理实现限流、熔断等流量控制功能。Sidecar代理可以独立于服务本身进行部署和管理。
   • 优点：与业务逻辑解耦，管理和控制灵活。服务网格提供了统一的流量管理和控制功能，不需要修改服务代码。
   • 缺点：引入额外的网络开销和复杂度，适用于大规模微服务架构。Sidecar代理的性能和可靠性需要特别关注 。

实际应用中的考虑

1. 流量监控与分析：

   • 概述：实时监控系统流量，并通过分析流量数据，为限流策略的调整提供依据。流量监控可以帮助运维人员及时发现和处理流量异常，确保系统稳定运行。
   • 实现方式：使用Prometheus、Grafana等工具进行流量监控，通过可视化界面展示流量数据，并设置报警机制。例如，可以设置请求数、响应时间、错误率等指标的报警阈值，当某个指标超过阈值时触发报警。
   • 使用场景：适用于所有需要流量控制的系统，通过实时监控和分析，及时发现和处理流量异常。

2. 弹性扩展：

   • 概述：根据系统流量动态调整资源配置，以应对流量高峰。弹性扩展可以在流量高峰时自动增加服务实例，流量下降时自动减少服务实例，从而高效利用资源。
   • 实现方式：使用Kubernetes等容器编排工具，根据流量情况自动调整服务实例的数量，实现弹性扩展。例如，可以设置CPU、内存使用率等指标，当某个指标超过设定值时自动增加服务实例。
   • 使用场景：适用于流量波动较大的系统，如电商网站、直播平台等。弹性扩展可以提高系统的可靠性和资源利用率。

3. 流量优先级管理：

   • 概述：根据业务需求对流量进行优先级划分，确保重要请求优先处理。流量优先级管理可以保证关键业务在高负载情况下仍能正常运行。
   • 实现方式：在系统中设置流量优先级策略，对不同优先级的请求进行不同的限流处理。例如，可以设置VIP用户的请求优先处理，普通用户的请求在高负载情况下被限流。
   • 使用场景：适用于需要区分请求优先级的系统，如金融交易系统、紧急报警系统等。流量优先级管理可以提高用户体验和业务连续性。

4. 灰度发布：

   • 概述：通过灰度发布策略，在新功能上线时控制流量，逐步引入新功能，减少风险。灰度发布可以在新功能上线时逐步增加流量，监控新功能的表现，及时发现和解决问题。
   • 实现方式：使用灰度发布工具（如Istio、Flagger），根据流量情况逐步将流量引导到新版本服务。例如，可以先将10%的流量引导到新版本服务，观察一段时间后逐步增加流量。
   • 使用场景：适用于需要频繁更新和发布新功能的系统，如互联网应用、移动应用等。灰度发布可以提高新功能上线的安全性和稳定性。

结论

流量控制是确保分布式系统稳定性和可靠性的关键手段。通过合理的流量统计、限流设计模式和分布式限流策略，可以有效管理和控制系统的流量，防止系统过载，提高服务质量。在实际应用中，通过流量监控与分析、弹性扩展、流量优先级管理和灰度发布等措施，确保系统在高负载下仍能稳定运行。

流量控制不仅是技术上的挑战，更是系统设计和运营中的重要环节。通过前面详述的各种策略和模式，我们可以看到，流量控制不仅仅是为了应对流量波动，更是为了构建一个具有高弹性和高可用性的系统。这种系统能够在面对各种不确定因素时，仍能保持稳定和可靠，最终为用户提供持续的优质服务。