REST API与message broker消费者拆分的架构利弊及选型方向咨询

方案1：消费者与REST API同模块部署（不拆分） #

优势 #

• 运维成本低：不需要额外维护独立的消费者服务实例、配置、监控项，部署包仅需一套，上线流程更简单
• 资源利用率更高：如果REST API和消费者的流量峰谷刚好错配，同进程部署可以最大化利用服务器CPU、内存资源，避免独立部署时其中一个模块资源闲置
• 开发调试更简单：本地启动一个服务就能完成日志写入、消费落库、查询全链路调试，不需要额外启动消费者进程，排查问题不需要跨服务查日志
• 无需处理额外分布式问题：同模块下共享配置、公共类无需重复封装，也不用考虑消费者服务和REST API服务之间的配置一致性问题

劣势 #

• 资源抢占风险：消费者消费高峰期（比如批量审计日志上报导致MQ积压）会占用大量CPU、IO资源写库，直接影响REST API接口的响应性能，甚至会导致查询审计日志的接口超时
• 扩缩容不灵活：如果只是MQ消费能力不足需要扩容，只能连带REST API一起扩容，反之如果只是REST API查询流量上涨，扩容的实例里附带的消费者进程完全是冗余的，浪费资源
• 故障影响范围大：消费者逻辑出问题（比如消费异常导致进程崩溃、OOM）会直接带垮整个REST API服务，导致日志上报、查询能力同时不可用
• 版本发布互相影响：消费者逻辑迭代或者修复bug需要发版时，必须重启整个REST API服务，会影响正常的查询、上报接口可用性，尤其是需要灰度发布的时候难度更高

方案2：消费者与REST API拆分为独立组件 #

优势 #

• 故障隔离彻底：消费者服务出问题不会影响REST API的正常运行，哪怕消费者完全挂掉，REST API依然可以正常接收上报请求（消息存在MQ里）、正常响应查询请求，不会出现全链路不可用的情况
• 扩缩容完全独立：可以根据实际负载分别调整实例数，比如消费积压就只扩消费者实例，查询流量上涨就只扩REST API实例，资源利用率最高
• 迭代发布互不影响：消费者和REST API的发版完全解耦，各自的功能迭代、bug修复都不会影响对方的可用性，发布风险更低
• 权限管控更灵活：审计日志写库的权限只需要开放给消费者服务即可，REST API只需要开放读库权限，符合最小权限的安全要求，降低数据被篡改的风险
• 技术选型灵活：两者可以按需选择不同的技术栈，比如REST API用更擅长web开发的Spring Boot，消费者用启动更快、资源消耗更低的Quarkus，不需要强制统一技术栈

劣势 #

• 运维成本更高：需要多维护一套服务的部署、配置、监控、告警规则，运维工作量至少提升30%以上
• 部署资源消耗更高：两个独立服务至少需要2个进程运行，相比同模块部署会多消耗一部分基础内存、CPU资源，小流量场景下会有资源浪费
• 调试排查问题更复杂：全链路问题需要分别查REST API、MQ、消费者三个节点的日志，跨服务排查成本更高
• 需要处理额外的分布式一致性问题：比如公共依赖包、配置项需要两边同步更新，避免出现序列化不兼容、配置不一致的问题

符合以下任意场景优先选择不拆分：

• 整体流量规模小，单实例REST API就可以同时扛住上报、查询、消费的所有压力
• 团队运维资源不足，没有多余的精力维护多套服务
• 需求迭代频率极低，后续基本不会对消费者或者REST API做单独的功能迭代

符合以下任意场景优先选择拆分：

• 对审计服务的可用性要求高，不允许出现查询、上报能力不可用的情况
• 流量规模大，或者未来有明确的流量上涨预期，需要灵活扩缩容
• 消费者和REST API的迭代频率差异大，比如消费者逻辑经常需要调整，但是REST API逻辑基本稳定
• 对数据安全要求高，需要严格管控数据库读写权限

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