Angular中RxStomp服务架构：实时通知WebSocket订阅时机选型疑问

基于RxStomp的WebSocket使用规范，没有绝对正确的选择，核心取决于你对通知实时性、资源占用的要求，两种原生实现方案单独用都有明确的坑，先把各自的实际优劣拆清楚：

两种原生方案的优劣势对比 #

方案一：根组件全局统一初始化订阅 #

核心优势

• 连接全程复用，不会出现同主题重复订阅导致的服务端双倍推送开销
• 不存在路由切换时的订阅空窗，不会出现组件切换瞬间的通知漏发
• 所有通知处理逻辑集中，不用每个组件重复写连接重试、断连重订阅的通用逻辑
  核心劣势
• 只要应用启动，无论用户是否停留在需要展示通知的页面，这个主题的订阅都会一直占用WebSocket连接和服务端资源
• 如果后续需要根据用户权限、当前路由做通知过滤，逻辑会逐步堆在根组件里，耦合度越来越高，后期维护成本涨得很快
• 根组件会逐渐变成“全局逻辑垃圾桶”，各种零散的监听全往这里塞，代码可读性和可测试性都会变差

方案二：各组件独立初始化、销毁时退订 #

核心优势

• 订阅生命周期和组件完全绑定，组件离开页面就彻底释放对应订阅，资源利用率更高
• 每个组件可以自定义适配当前页面的通知处理逻辑，比如通知列表页收消息就刷新列表，角标组件收消息就更新计数，互相不干扰
• 权限粒度更细，只有用户进入对应页面、通过权限校验后才会建立订阅，不会提前在全局开无意义的订阅
  核心劣势
• 最常见的踩坑点：两个组件同时订阅同一主题时，很容易在同一个WebSocket连接上生成两个独立的服务端订阅条目，导致同一条消息被推送两次
• 路由切换时如果退订和重新订阅的时序没处理好，很容易出现几秒的订阅空窗期，漏掉刚好在这个时间段推送的通知
• 每个组件都要独立处理RxStomp的连接状态、重连、订阅失败重试逻辑，代码重复度极高

生产环境推荐的折中实现 #

直接把订阅逻辑从组件里抽离到全局单例的Angular服务里，把两种方案的优势合并，避开各自的坑：

• 写一个专属的通知服务（比如GlobalNotificationService），由Angular依赖注入保证全局只有一个实例，所有RxStomp连接的状态管理全在这个服务内部处理
• 服务内部维护一个私有Subject，作为统一的通知消息出口，所有需要收通知的组件直接注入服务拿这个可观察对象就行
• 服务内部维护订阅引用计数：
  • 第一次有组件注册订阅通知流时，才真正调用RxStomp的接口和STOMP服务端建立主题订阅，收到的消息统一转发给内部的Subject
  • 每当有组件在ngOnDestroy里退订自己的通知流，就把引用计数减1
  • 当引用计数降到0时，才真正和服务端取消这个主题的订阅，释放连接上的资源
• 由这个服务统一处理WebSocket重连后的订阅自动恢复，组件完全感知不到底层连接变化

几个必须避开的实操坑 #

• 绝对不要在多个组件里直接调用rxStomp.subscribe('/topic/your-notification')，哪怕是同一个主题。很多人误以为同连接上的重复订阅会被自动去重，实际上STOMP协议会给每一个SUBSCRIBE请求生成独立的订阅ID，服务端会给每个订阅ID推一遍消息，平白增加推送流量
• 不要把全局订阅逻辑直接堆在根组件里，根组件的职责是做应用级的初始化入口，不应该承载具体的业务订阅逻辑
• 一定要做消息的多播隔离，不要把服务内部的Subject直接暴露给外部修改，组件拿到通知流后要自己管理退订

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