22、速率限制服务设计：从需求到架构的全面解析

速率限制服务设计：从需求到架构的全面解析

1. 非功能需求

速率限制是几乎所有服务都需要的基本功能，它必须具备可扩展性、高性能、尽可能简单、安全和隐私保护等特性。由于速率限制并非服务可用性的关键因素，因此可以在高可用性和容错性方面进行权衡。准确性和一致性虽然重要，但并非严格要求。具体需求如下：
- 可扩展性 ：服务应能处理数十亿的日请求量，以查询特定请求者是否应受到速率限制。更改速率限制的请求仅由组织内部用户手动发起，因此无需向外部用户开放此功能。假设服务有 10 亿用户，每个用户需存储 100 个请求的时间戳，每个时间戳 64 位，同时考虑约 100 个需进行速率限制的服务，保守估计 10 秒内有 1000 万用户，总体存储需求约为 808GB。使用 Redis 时，每个用户键对应的值大小为 800 字节。实际存储需求取决于服务删除旧数据的速度。
- 性能 ：当其他服务接收到用户请求时，会向速率限制服务发送请求以确定是否对用户请求进行速率限制。速率限制请求是阻塞的，会增加用户请求的响应时间。因此，速率限制服务需要极低的延迟，P99 可能需控制在 100ms 以内。而查看或分析日志则不需要低延迟。
- 复杂性 ：作为共享服务，其设计应简单，以降低出现错误和故障的风险，便于故障排除，专注于速率限制功能，并降低成本。其他服务的开发者应能尽可能简单无缝地集成该速率限制解决方案。
- 安全和隐私 ：用户服务的安全和隐私措施可能不足以防止外部攻击者访问速率限制服务，内部用户服务也可能尝试攻击速率限制器，如伪造其他用户服务的请求进行速率限制，