窥探限流器架构：第二部分

发表于： 2025年9月14日 2025年9月14日
分类：架构
标签：限流器

前提回顾

这是一个关于限流器架构的三部分系列文章的第二部分。如果你错过了第一部分，可以 [点击这里](链接) 查看。
在第一部分中，我们讨论了限流器的存在以及它的基本功能，但没有假设关于它的部署方式或分布形式。我们以单一服务的形式参考限流器，它确实可以作为一个单独的服务运行。在这一部分，我们探讨单体限流器与分布式限流器部署的优缺点。

单体限流器设计

单体限流器是一种“全知式”服务，负责处理所有请求。它能够探测和收集所有指标，这意味着它可能需要直接访问所有数据库服务器和操作系统相关指标（比如第一部分中提到的 **load average**）。这种直接访问在某些环境中是可以接受的。单体限流器通常会持有大量的持久连接，这些连接用来读取一组指标。这种方法是简单的、单体式的、同步的。
高可用性问题：这种方法立即引发了一个问题：如果限流器主机宕机怎么办？我们可以假设能够启动新的限流器服务，但它可能需要一些时间来完成启动、建立连接并开始收集数据。在此期间，客户端应如何行为？设计上有两种选择：

开放式失败：客户端可以忽略限流器状态并继续以不受限的速率运行。
闭合式失败：客户端认为限流器未响应并拒绝执行任务。

通常的做法是设置一个超时时间，在指定时间内等待限流器响应，然后从此刻开始无视限流器。
多实例单体限流器：另一种选择是运行多个独立的限流器实例，它们可以部署在不同的可用性区域，相互独立，仍然可以作为单体限流器。有些变种方法包括 **主-备模式**，将流量导向活动状态的主限流器，并将备限流器保持可用。一旦主限流器宕机，备限流器可以立即接管工作。
但这一方法存在**扩展性问题**。单体限流器只能维护有限数量的连接，随着高频探测的运行，这很快会成为瓶颈。

环境限制与 API 接口

在某些受限制的环境中，限流器无法直接访问数据库和操作系统指标。这时可以通过设置 HTTP 服务器或 API 访问点，将限流器改为通过 API 获取主机的指标，指标收集则由运行在本地主机的守护进程或代理完成。
这种设计引入了新的复杂性：

新增组件：我们需要一个持续运行的守护进程负责采集指标，这需要确保其可靠性。
同步问题：限流器通过 API 收集指标，而 API 的采集周期可能与限流器的不同，导致数据存在延迟。例如，代理间隔 1 秒采集数据，限流器每秒调用一次 API，则数据可能最多延迟 2 秒，而单体限流器设计中延迟仅为 1 秒。

通过引入代理组件，即使只是一个简单的脚本来抓取和发布指标，我们实际上已经将单体限流器转换为一个分布式多组件系统。

分布式限流器设计

分布式限流器设计提供了多种方法。限流器可以部署在各自的可用性区域（AZ），每个限流器仅收集区域内的指标，而无需其他区域的数据。
限流器协作：各区域的限流器可以互相交换指标数据。例如，us-east-1 限流器可以向 us-west-1 限流器广播其收集的指标。这种设计类似于代理架构的一种极致化实现，限流器既是采集组件也是协作组件。
功能分区：不同的限流器可以服务不同的功能分区。例如，某些限流器负责监控主机负载，另一些限流器负责复制延迟，这些限流器彼此独立。
颗粒化设计案例研究： Vitess 的 tablet 限流器结合了多种设计方法，实现不同范围的限流：

每个 vttablet 上运行一个限流器，对应一个 MySQL 数据库服务器。
一个分片（shard）内的所有限流器协作，由主库限流器聚合分片数据作为“分片”指标提供。

此设计限制了单个限流器监控的主机数量，保持了扩展性。

限流器影响的优化

限流器自身可能对系统造成负载，我们需要避免以下情况：

过度探测：限流器频繁收集指标导致的系统开销。
过度通信：限流器间频繁交换数据对系统资源的消耗。
繁忙循环：客户端频繁检查限流器状态也可能增加负载。

优化建议：

客户端在被拒绝后应等待一段时间再重新检查限流器状态。
在指标允许的情况下，客户端可以在一段时间内跳过检查，例如当复制延迟为 0.5 秒而阈值为 5 秒时，接下来的 4.5 秒中所有请求都可以直接获得许可。
在后台任务较少时，限流器可以降低指标的采集频率甚至暂停采集（进入休眠状态），以减少无谓的系统开销。

指标生成的动态调节

指标生成本身也可以休眠。例如 MySQL 的复制延迟评估需要通过向主库特定表插入时间戳并在副本读取该值。这种“心跳”技术对于评估延迟非常可靠，但会增加二进制日志的生成频率，占用更多磁盘空间，增加备份存储成本。
在没有大规模任务运行时，这些心跳写操作可以减少甚至完全暂停。等需要时心跳操作才会重新启用，实现指标的动态生成和最小开销化。