直接回答：核心设计点：限流维度模型（租户/API/用户/IP 可组合的 rule 配置）、算法选型（令牌桶允许突发、滑动窗口平滑、并发数限制防资源耗尽）、计数存储（单机 Guava 型 vs 分布式 Redis）、以及超限语义（拒绝 429、排队、降级）。分布式下的本质权衡是精度与成本：每个请求同步查 Redis 精确但有延迟与单点压力；本地计数加周期同步省成本但允许超额。
展开解析：架构形态三档：网关内嵌本地限流（性能最好，多实例下总量是配置×实例数，按实例均摊配额）；Redis 集中式（Lua 脚本保证"读-改-写"原子，GEO 式多维度规则易表达，配合本地缓存降级）；配额服务化（定期向配额服务领取批量额度本地消耗，Cell 化容灾，大促电商常用）。工程细节：规则热更新不能重启；Redis 故障时的 fail-open/fail-close 要按业务定（支付 fail-close、资讯 fail-open）；突发与长期的组合策略（1 秒 burst + 1 天 quota）；超限响应带 Retry-After 是 API 素养。可观测性：限流命中率、被限租户分布、规则配置审计——限流系统本身的故障会直接放大成全站故障，它自己的可用性设计（降级为本地规则）常被漏掉。
追问方向：令牌桶在 Redis Lua 里怎么实现原子？quota 预取模式怎么控制超额上限？如何给"大促临时提额"设计审批与生效链路？
（约 470 字）