Kafka：在Kafka驱动架构中使用请求/响应模式相关咨询

关于Kafka请求-响应模式的生产应用情况 #

业界基本不会把改造后的Kafka请求-响应模式作为核心同步交互方案。Kafka的原生设计就是面向高吞吐的异步事件流场景，硬套请求-响应逻辑需要自行处理请求ID与响应的绑定、超时重试、响应Topic的消费者隔离、消息积压导致的请求延迟飙升等一堆额外问题，运维成本会大幅上涨，完全没必要。
少数团队只会在内部跨服务的异步回调场景下用请求+响应Topic的方案，绝对不会承接前端直接发起的同步查询需求，你觉得是「硬适配」的观感完全正确，这种方案本身就是为了兼容极特殊的场景，不是通用解法。

Kafka+RESTful API是非常成熟的通用综合解决方案 #

这是中小团队甚至大厂都会用的标准混合架构，分工非常清晰：

• 所有实时数据采集、跨服务异步事件通知、批量数据分发的场景全走Kafka，刚好适配你们替换原有嵌套套接字通信、改造IPC架构的需求，最大化发挥Kafka的事件流优势
• 同步查询类需求统一走RESTful API接口，数据来源根据业务场景拆分：
  • 类似脚本配置这类状态型数据，直接存在关系型数据库/Redis缓存中，接口直接读存储返回即可
  • 需要基于实时流计算得到的查询数据，先通过Kafka流处理完成计算后写入查询专用存储（比如Redis、ClickHouse），再给REST接口提供查询能力
• 如果有服务间的同步调用需求，直接用成熟的RPC框架（比如gRPC、Dubbo）即可，比改造Kafka的性价比高得多

小团队落地的注意事项 #

• 不要为了强行统一技术栈，让Kafka承担所有通信场景，不同组件有明确的适用边界，硬凑只会给自己埋后期运维的大坑
• 初期不用搞太复杂的架构，Kafka负责异步流、REST接口负责同步查询的模式完全能覆盖绝大多数业务需求，运维成本也低
• 如果确实有少量内部异步回调需要回执，再用请求+响应Topic的方案，但是必须做好超时、重试、幂等逻辑的处理，禁止透传给前端使用

内容的提问来源于stack exchange，提问作者Bill Brown