设计高吞吐系统，别跑偏

高吞吐从来不是一条需求，而是一组彼此牵制的约束：到达速率、突发形状、响应时间目标、数据一致性、故障恢复，以及成本。如果把它们压缩成一个漂亮的数字，架构通常会优化错的东西。

先描述负载的形状#

在讨论 Kafka、缓存或分区之前，先写下四件事：

1. 稳态流量与峰值流量。 常年 2 万 QPS、偶尔十秒冲到 30 万，和全天稳定 30 万，是两个完全不同的设计问题。
2. 延迟分布。 中位数适合演示，P99 才适合生产。要问清楚是哪些依赖在拉长尾部。
3. 正确性的单位。 哪些操作可以最终一致？哪些必须幂等、保序，或者落在一个事务边界内？
4. 恢复目标。 能重放事件日志的服务，和无法重建状态的服务，故障时的选择完全不同。

这一步把「我们需要扛住量」变成一个可以被验证的模型。

保护同步路径#

最可靠的性能优化，往往是把工作从请求路径上拿掉。同步链路里只保留返回一个正确响应所必需的决策；在产品允许的前提下，把富化、分析、通知和昂贵的二次写入放到可靠事件之后。

这并不意味着一切都要异步化，而是意味着一致性边界要被刻意划出来。

同步路径上应该只保留「给出一个诚实的响应」所必需的最小工作量。

边界清晰之后，队列和流才会成为运维工具，而不是架构装饰。它们能吸收突发、隔离消费方、支持重放——但同时也会带来延迟、重复、乱序，以及一个必须被观测的新积压。

按压力设计，而不是按平均值#

背压是产品行为的一部分。当下游变慢时，系统需要一个明确的策略：

• 丢弃低价值的工作；
• 降级非关键功能；
• 限制队列长度与并发度；
• 在超时级联之前返回明确的失败；
• 保留足够上下文以便安全重试。

无界的队列和无限的重试，只是把故障推迟到未来。稳定的系统一定有边界，并且团队清楚每个边界被触碰时会发生什么。

让瓶颈可见#

吞吐相关的工作应当留下证据链：服务级延迟直方图、队列深度与积压时长、饱和度、错误预算，以及跨越关键边界的链路采样。没有这些，每次故障复盘都会变成直觉之争。

一个有用的看板按顺序回答三个问题：

1. 流量是否异常？
2. 哪个资源或依赖被打满了？
3. 干预之后系统是否在恢复？

架构就是运维模型#

正确的设计不是分布式组件最多的那个，而是团队能在真实负载下运维、能放心修改、能在故障中讲清楚的那个。

容量模型、幂等、有界并发和可观测性不是收尾工作，它们本身就是架构。