大型系统如何重新思考通信

请提供您想要翻译的正文内容，我会按照要求将其译成简体中文并保留原有的格式。

引言

你是否注意到，曾经运行良好的系统在规模扩大后会突然表现出不同的行为？这并不是因为早期的决策错误——只是规模带来了新的挑战，一些最初看似安全的假设开始被拉伸。在这个过程中，团队首先重新审视的就是系统各部分之间的通信方式。

同步 API

大多数系统从同步 API 开始。为什么不呢？它们易于推理、调试简单，并且能够清晰地展示请求和响应的流程。一个服务调用另一个服务，得到答案后继续进行。长时间来看，这种方式运行得非常好。延迟可预测，依赖少，反馈即时，问题易于发现。团队可以快速推进，系统的行为正如预期。

大规模挑战

但系统随后会增长。突然，流量模式变得不均衡，有些请求激增，而其他请求比预期更耗时。新的消费者加入系统，旧的消费者也在演变，处理能力并不总能跟上涌入的负载。跨服务协调工作何时发生变得更困难，超时、重试和监控随处出现。这并不是失败。系统仍在按设计运行，只是处于新的条件下工作。

在这个阶段，问题会微妙地转变。团队不再问“这个服务现在能响应吗？”，而是开始问“即使需要时间，我们能否确保这项工作可靠地完成？”这时消息传递常常介入。消息传递允许系统的一部分记录意图，另一部分在能够时再执行。临时的积压是预期之内的，较慢的组件不会立刻阻塞较快的组件。

消息补充 API

消息并不是要取代 API——它是对 API 的补充。大多数现代系统最终都会同时使用两者。API 仍然用于需要即时响应的交互，而消息则处理可以容忍灵活时机的工作负载。

Enterprise Messaging vs. Kafka

Enterprise messaging systems like TIBCO EMS have been around for a long time to address these needs. EMS works very well in environments where delivery guarantees matter, consumers are stable, message flows are predictable, and processing happens close to event creation. Many large organisations still rely on EMS for core integrations.

As systems become more distributed and dynamic, additional needs arise — particularly around retaining data longer and allowing multiple consumers to act independently. This is where Kafka comes in. By treating events as a durable, ordered log, Kafka allows consumers to replay data when needed, multiple teams to read the same events independently, and processing to happen without tight coordination. Recovery becomes more predictable, and the system can handle growing complexity without changing the API‑based interactions that already work. Kafka isn’t replacing earlier messaging systems — it’s expanding the architectural toolbox for modern needs, where history matters as much as delivery.

通信选择的成熟度

随着系统的成熟，通信选择变得更加审慎。某些交互需要在时间上达成一致，某些需要在状态上达成一致，亦有两者兼顾的情况。并没有唯一正确的设计方式。最佳架构会识别系统各部分实际需要的保证，并相应选择合适的模式。

Conclusion

当系统重新思考通信方式时，并不是因为出现了错误，而是因为团队现在更好地理解了权衡。同步 API 在早期感觉自然，消息传递有助于在后期减少紧密协作，而持久化事件流使复杂的恢复和重放成为可能。大型系统会演进，因为经验教会团队在不同约束下什么是可行的。这种演进是成熟的标志——而非技术债务。