架构设计

整体架构分为业务应用、木雷消息服务（Go）、消息服务商与接收人四个区域，连线上的 ①~㉖ 标号描述一次消息投递的完整时序：从 HMAC 签名请求进入，经异步队列与通道选择，到供应商发送、回执处理，最后经 Webhook 与轮询回传业务。图的源文件维护在仓库 docs/archify/zh-CN/（archify 生成，可复现）。

启动链

main.go 将配置、静态资源和应用装配交给 go-web：环境变量 → 配置 → 日志 → 数据库 → Redis → 缓存 → 领域模块；服务阶段依次完成 JWT 检查、goose 迁移、初始管理员引导、Worker/调度器和 HTTP 服务。

消息流

flowchart LR
  API["HMAC API"] --> Validate["鉴权、限流、配额、就绪校验"]
  Validate --> DB[("数据库任务")]
  DB --> Queue["Redis Stream / 定时集合"]
  Queue --> Worker["Worker Pool"]
  Worker --> Selector["优先级 + 平滑加权轮询"]
  Selector --> Sender["服务商 Sender"]
  Sender --> Rule["失败策略"]
  Sender --> Callback["回执与上行短信"]
  Callback --> Webhook["应用 Webhook"]

数据与职责

• 应用域：App ID、加密 App Secret、白名单、配额、限流与 Webhook。
• 模板域：系统模板表达业务变量，供应商模板表达各平台模板代码与变量。
• 通道域：绑定、优先级、权重、激活状态、签名映射和静态就绪校验。
• 投递域：任务、批次、Redis 队列、Worker、调度、重试和死信流。
• 回调域：下行回执、上行短信与应用 Webhook 日志。

高可用选择

通道先按较小的优先级选组，再在组内平滑加权。规则切换可排除当前账号；同一应用、通道和接收者在短窗口内记录上次账号。启用但失活或配置无效的绑定使通道降级；硬依赖缺失时阻塞。

一致性边界

任务先持久化再入 Redis，队列采用 at-least-once 语义，Worker 通过任务状态避免重复处理。业务调用方仍应以任务 ID做幂等关联，并正确处理回调重复、乱序和超时。

相关页面：项目介绍 · 失败策略 · Kubernetes