feat: add cmpp inbound gateway listener

2026-07-07 16:19:14 +08:00
parent ad3b86ba0a
commit cc628d0214
14 changed files with 631 additions and 17 deletions
@@ -221,17 +221,23 @@

 #### 4.8.4 当前实现缺口标记

-截至当前版本，Go Gateway 已有 HTTP 控制服务、健康检查、连接上游 SMSC 的 `ConnectChannel` 控制入口、gocmpp 协议 spike 和队列消息结构；但仍缺少生产验收所需的完整能力：
+截至当前版本，Go Gateway 已有 HTTP 控制服务、健康检查、连接上游 SMSC 的 `ConnectChannel` 控制入口、gocmpp 协议 spike、队列消息结构，并已补齐第一阶段下游 CMPP 入站能力：

- 未实现 `17890` 入站 CMPP Server 监听。
- 未实现下游客户 connect/login 鉴权、IP 白名单、应用级连接数限制和连接状态回写。
- 未实现下游 CMPP Submit 到平台发送请求的转换。
- 未实现客户侧 SubmitResp、最终 Deliver Receipt 和上行 Deliver 投递。
+- 已实现 `17890` 入站 CMPP Server 监听，生产部署由 `GATEWAY_CMPP_ADDR=0.0.0.0:17890` 启动。
+- 已实现下游客户 connect/login 鉴权：CMPP `Source_Addr` 使用企业应用独立 6 位 `cmppAccount`，密码使用应用 CMPP 参数中的 `passwordCipher`，Gateway 将 CMPP `AuthSource/Timestamp` 交由 NestJS 根据真实数据库校验。
+- 已实现客户端应用 IP 白名单、应用状态、企业状态和企业认证状态校验；校验失败返回 CMPP connect 失败。
+- 已实现下游 CMPP Submit 到平台发送请求的转换：Gateway 解码 CMPP 3.0 submit 内容，调用 NestJS 真实入站接口，NestJS 复用模板/签名/风控/余额/路由/队列优先级发送链路，接受后返回 CMPP submit_resp。
+
+仍缺少生产完整闭环能力：
+
+- 应用级下游连接数限制和连接状态回写尚未完整产品化。
+- 当前下游 CMPP Submit 通过 `sourceType=cmpp` 的系统批次兼容承载，尚未拆成完全独立于批量任务模型的单条发送模型。
+- 未实现客户侧最终 Deliver Receipt 和上行 Deliver 投递。
 - 未实现 Gateway 消费 `SubmitCommand` 并真实 submit 到上游通道的 worker。
 - 未实现上游 deliver receipt 和普通上行 deliver 的生产解析与事件回传闭环。
 - 未实现多连接窗口管理、在途消息恢复、断线重连后的消息状态处理。

-这些缺口未补齐前，不能把 CMPP 对接发送、17890 端口联调、客户账号密码鉴权、客户 IP 白名单或真实网关 submit/receipt/uplink 作为“生产已验收通过”。
+这些缺口未补齐前，只能把 `17890` 端口监听、客户账号密码鉴权、客户 IP 白名单和下游 submit 入平台发送链路作为第一阶段验收通过；不能把客户侧最终回执投递、上游真实运营商 submit/receipt/uplink 或完整多连接窗口恢复作为“生产已验收通过”。

 ### 4.9 回执与上行

@@ -8,7 +8,7 @@
 - PostgreSQL：仅本机 `127.0.0.1:5432`。
 - MinIO：仅本机 `127.0.0.1:9000/9001`，页面上传下载通过 API 转发。
 - Gateway 控制服务：仅本机 `127.0.0.1:8090`。
- CMPP 入站端口：`17890` 已作为部署变量保留；当前 Go Gateway 代码尚未实现完整入站 CMPP Server，不要把 HTTP 控制服务误当作 CMPP 监听。
+- CMPP 入站端口：`17890`，由 Go Gateway 启动真实 CMPP 3.0 Server，接收企业应用下游 connect/login 和 submit。

 ## 首次部署

@@ -978,6 +978,22 @@
  - 第二条记录历史或被幂等处理。
  - 不重复扣费或重复变更最终状态。

+### TC-GW-006 下游客户 CMPP 17890 入站 bind/submit
+
+- 优先级：P0
+- 前置条件：企业已认证通过；短信应用 active 且存在独立 6 位 `cmppAccount`；应用 IP 白名单包含测试客户端 IP；应用已有审核和报备通过的签名/模板；通道组、余额和 Gateway 均可用。
+- 步骤：
+  1. 启动 Go Gateway，确认 `GATEWAY_CMPP_ADDR=0.0.0.0:17890`。
+  2. 使用 gocmpp 或真实 CMPP 客户端连接 `17890`，`Source_Addr` 填应用 `cmppAccount`，密码填应用 CMPP 参数 `passwordCipher`。
+  3. 发送 CMPP 3.0 SubmitReq，手机号和内容匹配已审核模板。
+  4. 查询 NestJS 数据库和运营端短信记录。
+- 预期结果：
+  - 17890 是真实 CMPP Server 监听，不是 HTTP 端口。
+  - bind 阶段调用真实 NestJS API 校验账号、密码、企业状态、认证状态、应用状态和 IP 白名单。
+  - 密码错误、应用停用、企业停用、IP 不在白名单时 connect/login 被拒绝。
+  - submit 被接受后返回 CMPP SubmitResp 成功，并在真实数据库创建 `sourceType=cmpp` 的发送记录，进入真实发送链路。
+  - submit 内容不匹配审核模板、余额不足、无可用通道时返回明确失败，不得伪造成功。
+
 ### TC-SEND-021 优先队列插队发送

 - 优先级：P0
@@ -583,6 +583,29 @@ npm run verify:phase8
 - `verify:phase8` 当前失败点是独立 BullMQ 性能阈值，不是本轮通道组、计费、报备、回执业务逻辑测试失败。
 - 浏览器端完整手工回归仍建议补跑企业应用创建、通道组配置、短信记录详情弹窗中的历史回执展示。

+## 2026-07-07 Gateway 下游 CMPP 入站第一阶段补齐
+
+### 本轮修复
+
+- Go Gateway 启动时同时监听 `GATEWAY_CMPP_ADDR`，默认生产端口 `0.0.0.0:17890`，不再只是 HTTP `/health` 控制服务。
+- 新增企业应用独立 6 位 `cmppAccount`，Prisma 迁移 `20260707162000_add_application_cmpp_account` 会为存量应用生成账号；客户端/运营端 CMPP 参数接口返回该应用独立账号。
+- Gateway 下游 CMPP bind 使用真实 gocmpp 协议解析 `Source_Addr/AuthSource/Timestamp`，调用 NestJS `/api/gateway/events/inbound/authenticate`，由真实数据库校验应用账号、应用 CMPP 密码、企业状态、企业认证状态、应用状态和 IP 白名单。
+- Gateway 下游 CMPP submit 解码 CMPP 3.0 `SubmitReq`，调用 NestJS `/api/gateway/events/inbound/submit`；NestJS 按 `sourceType=cmpp` 创建发送记录并复用模板/签名/风控/余额/运营商识别/通道组路由/队列优先级链路。
+- Go Gateway 新增入站集成测试，覆盖本地 CMPP 客户端 connect/login、UCS2 submit 和 API 回调。
+
+### 验证状态
+
+- `npm --prefix api run prisma:generate`：通过。
+- `npm --prefix api test -- sms-config.service.spec.ts send-chain.service.spec.ts --runInBand`：通过。
+- `npm --prefix api run build`：通过。
+- `go test ./...`（Gateway）：通过。
+
+### 剩余缺口
+
+- 下游连接状态回写、连接数上限、断开/心跳历史日志仍需继续产品化。
+- 下游 submit 当前通过 `sourceType=cmpp` 的系统批次兼容承载，尚未完全拆成独立单条发送模型。
+- 客户侧最终 Deliver Receipt 投递、客户侧上行 Deliver 推送、上游真实 SMSC submit worker、上游 receipt/uplink 生产解析仍未完成。
+
 ## 2026-07-03 阶段 9：运营端报备回执导入真实上传/解析

 ### 本轮修复