多传输通知服务API架构推荐及自定义客户端传输设计咨询

云原生阿岚

2026-7-9

多传输通知服务API推荐架构及Client传输方案

一、通用多传输通知服务架构设计

API网关层：保留现有配置创建接口，作为统一的Notify请求入口，负责请求校验、权限验证、根据传输配置路由到对应传输服务，同时可集成限流、熔断等流量控制能力。
配置中心：集中存储所有传输配置（邮件SMTP参数、Client端Broker连接信息、订阅规则等），所有服务均从配置中心拉取最新配置，避免硬编码和重复配置。
传输服务集群：每种传输方式对应独立的微服务（邮件服务、Client推送服务等），完全解耦不同传输逻辑，可根据各自负载独立扩容，也便于单独迭代维护。
消息中间件层：用于异步化通知请求处理，尤其是Client推送这类可能涉及离线重试、批量广播的场景，有效削峰填谷，提升系统稳定性。
监控与日志层：收集各服务的通知发送成功率、延迟、失败原因等指标，配置告警规则；同时记录全链路通知日志，便于问题排查和追溯。

定义统一的传输服务接口（如INotificationSender），所有传输服务实现该接口并注册到网关的路由映射中。新增传输方式时，只需开发对应服务并更新配置中心的路由规则，无需修改网关核心代码，实现热扩展。

根据客户端类型和需求选择：

Redis Pub/Sub + WebSocket：适合Web应用，Client推送服务通过Redis订阅消息，再通过WebSocket推送给在线Web客户端；Avalonia桌面应用可直接连接Redis订阅指定频道，实现轻量实时推送。
MQTT Broker（如EMQX）：跨平台场景首选，支持持久化订阅、QoS等级设置，客户端离线后上线可自动接收未读消息，特别适配broadcast类型通知的全局推送需求。
RabbitMQ：如果需要复杂路由逻辑（如按用户分组、按客户端类型推送），其Topic/Direct Exchange能满足精细化的消息路由需求，适合业务复杂度较高的场景。

当Notify方法收到传输配置为client的请求时：

网关校验DTO中的消费者标识（用户ID+设备ID）、Broker配置参数、消息类型及内容，校验通过后将消息发送到消息中间件的指定队列/频道，并记录通知元数据（用于重试和监控）。
Client推送服务从Broker消费消息，根据消息类型处理：
- Simple类型：根据消费者标识匹配配置中心中对应的订阅频道，精准推送消息；桌面客户端可通过持久化订阅确保离线消息不丢失。
- Broadcast类型：直接推送至全局广播频道，所有订阅该频道的客户端均可接收。
客户端收到消息后，根据自身框架特性展示通知（Web端用浏览器系统通知、Avalonia用桌面弹窗通知等）。

客户端身份绑定：每个客户端需注册唯一标识（用户ID+设备ID），并在配置中心关联对应的订阅频道，确保消息能精准送达目标客户端。
离线消息处理：MQTT设置QoS=1/2或RabbitMQ启用持久化队列，保证客户端上线后能拉取离线期间的消息；Web端可结合localStorage记录已接收消息ID，避免重复展示。
重试与死信机制：推送失败时（如客户端离线、网络异常），设置固定次数的重试逻辑；多次重试失败的消息存入死信队列，后续可通过定时任务重新推送或人工介入处理。

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