Angular 5与消息总线：能否让前端直接发布事件至微服务消息队列？

这是个很值得探讨的架构设计问题，我来聊聊我的看法：

潜在的优势 #

• 简化部分流程：如果某些前端触发的操作不需要服务端做业务校验或数据持久化，直接发布事件能省去中间的API调用环节，减少服务端的负载。
• 更贴合用户行为链路：有些事件本身就是前端用户交互的直接结果，由前端发布能更直观地对齐业务场景，比如用户完成某个前端操作后直接触发下游的通知流程。

必须警惕的核心问题 #

• 数据一致性风险：这是最关键的问题。比如用户创建场景，前端如果同时调用创建API和发布UserCreated事件，很可能出现API调用失败但事件已被消费的情况，导致下游服务基于不存在的用户数据执行操作，造成脏数据。而微服务内部发布事件是在数据持久化成功后执行的，能天然保证一致性。
• 安全隐患：Pub/Sub队列直接暴露给前端的话，攻击者可以轻易伪造事件（比如伪造敏感操作的事件），前端的权限校验很难做到服务端那样严谨。而且队列的访问凭证放在前端极易泄露，给整个消息系统带来安全风险。
• 业务逻辑泄露：事件的格式、触发条件等属于业务规则的一部分，放在前端会被轻易逆向分析，增加业务逻辑被篡改或滥用的可能。
• 可靠性不足：前端网络环境不稳定，事件发布可能因网络波动失败，且前端缺乏服务端成熟的重试、死信队列等机制来保障事件可靠投递。
• 复杂度上升：前端需要额外处理队列连接、认证、错误处理等逻辑，增加了前端的维护成本，同时跨团队（前端与微服务）的协作复杂度也会提升，比如事件格式变更需要同步更新前端和所有消费服务。

我的建议 #

除非你的场景是完全无状态、无需服务端数据同步且安全要求极低的操作，否则不建议让Angular直接发布事件到微服务的Pub/Sub队列。

更稳妥的方式是保留现有架构：前端通过RESTful API触发业务操作，由服务端在完成数据校验、持久化并确保业务规则合规后，再发布事件到消息队列。

如果想优化现有流程，可以考虑这些方向：

• 在服务端封装统一的事件发布工具类，简化业务服务的事件发布逻辑；
• 引入事件驱动的API网关，统一处理前端请求和事件发布，既保证一致性，又能集中管理事件流转；
• 若前端需要感知下游服务的处理结果，可以通过WebSocket让服务端主动推送事件通知，而非让前端直接发布事件。

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