基于消息队列与REST的微服务通信方案选型咨询

背景梳理 #

我有两个基于Express+TypeScript的微服务A和B：

• B创建关联A中对象a的对象b时，必须先验证a是否存在
• 计划用Kafka做缓存同步：A增/删对象a时发消息，订阅者同步更新本地缓存
• 既要支持微服务间异步通信（比如创建耗时资源的场景），又得保留REST API用于对外暴露或同步通信需求

下面针对构思的三个方案逐个分析，给出选型参考：

方案1：部署两个同域服务（REST API 独立 + Kafka消费者独立） #

优点 #

• 职责绝对清晰：API服务只处理HTTP请求，消费者只管消息消费和缓存更新，代码拆分彻底，排查问题时不用在一堆混合逻辑里找
• 资源按需扩容：比如Kafka消息堆积时，单独加消费者实例就行，不会拖慢API的响应速度；API流量突增时，单独扩容API服务即可
• 故障隔离：消费者挂了不会影响API对外提供服务，反之亦然

缺点 #

• 运维成本翻倍：要维护两个服务的部署、监控、日志，额外多一套运维流程
• 同域配置麻烦：得用Nginx之类的做反向代理，区分两个服务的访问路径，或者配置服务发现来让内部调用能找到对应的服务

方案2：API服务后台异步跑Kafka消费者 #

优点 #

• 运维简单：只需要部署维护一个服务，不用管两套实例
• 资源复用：消费者和API共享进程资源，不用额外分配独立的服务器/容器资源
• 缓存访问更高效：消费者更新本地缓存后，API层直接读本地缓存就行，不用跨服务调用

缺点 #

• 耦合风险高：如果消费者处理消息时卡住（比如消息堆积、处理逻辑耗时久），会直接拖慢API的响应速度，甚至导致整个服务挂掉
• 扩容不灵活：扩容时必须同时给API和消费者加资源，没办法单独针对某一部分调整

方案3：微服务仅做消息消费，独立REST API转消息+等响应 #

优点 #

• 彻底异步解耦：业务逻辑全靠消息驱动，REST API只负责把HTTP请求转成Kafka消息，然后等响应消息回来再返回给客户端，业务服务完全不用碰HTTP相关逻辑
• 扩展性强：后续加新业务，只需要加对应的消息消费者就行，API层基本不用改

缺点 #

• 逻辑复杂度飙升：得自己实现请求和响应的关联（比如用requestId追踪）、超时处理、重试机制，代码会变得很绕
• 同步场景性能差：REST API要等消息队列的响应，比直接处理请求多了好几步延迟，不适合对响应时间敏感的同步调用场景

选型建议 #

• 如果团队运维能力够，且希望逻辑彻底解耦、能独立扩容，直接选方案1
• 如果运维资源有限，而且缓存更新逻辑很轻、不会出现阻塞情况，方案2性价比最高
• 如果你的业务大部分是异步场景，同步需求很少，且想彻底搞消息驱动架构，可以试试方案3

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