架构设计总览
DaxPay 主应用采用基础层聚合 + 业务模块 + 启动入口的分层范式,通道对接下沉到独立子应用,各子应用保持相同模式以便维护时对照同步。
主应用分层 (dax-pay-open)
dax-pay-open/
├── daxpay-platform/ # 基础层
│ ├── daxpay-platform-core # 通用契约: DTO / 枚举 / 异常 / 结果封装
│ ├── daxpay-platform-common # 通用技术设施 (聚合)
│ │ ├── common-i18n # 后端国际化资源 + JsonMessageSource
│ │ ├── common-mybatis-plus # ORM 配置
│ │ ├── common-redis # Redis 配置
│ │ ├── common-artemis # 消息队列
│ │ ├── common-json # JSON 序列化
│ │ ├── common-swagger # API 文档
│ │ ├── common-config # 加密 / 平台配置 / 部署模式强制
│ │ ├── common-request-context # 请求上下文
│ │ ├── common-translate # 翻译
│ │ └── common-spring # Spring 扩展
│ ├── daxpay-platform-capability # 平台能力 (聚合)
│ │ ├── capability-auth # 认证
│ │ ├── capability-audit-log # 审计日志
│ │ ├── capability-file # 文件
│ │ ├── capability-cache # 缓存
│ │ ├── capability-nonce # 防重放
│ │ ├── capability-social # 社交登录
│ │ ├── capability-wechat # 微信开放平台
│ │ ├── capability-alipay # 支付宝开放平台
│ │ ├── capability-douyin # 抖音开放平台
│ │ └── capability-sensitive-word # 敏感词
│ └── daxpay-platform-service # 平台业务服务 (聚合)
│ ├── service-iam # 用户/角色/菜单/权限码
│ ├── service-system # 字典/配置/日志
│ ├── service-baseapi # 基础 API
│ └── service-notify # 站内通知/公告/SSE
├── daxpay-payment/ # 支付业务
│ ├── daxpay-payment-core # 支付域内核: 领域模型/交易引擎/开放 API 契约
│ ├── daxpay-payment-admin # 运营管理端控制器与服务
│ ├── daxpay-payment-merchant # 商户自助端控制器与服务
│ ├── daxpay-payment-unipay # 统一收单 /unipay/**、网关产品、公开 H5
│ └── daxpay-payment-app-admin # 运营移动端 APP/小程序支付接口
├── daxpay-channel/ # 通道业务 (编排层)
│ ├── daxpay-channel-alipay # 支付宝通道 (HTTP 声明 + 配置 CRUD)
│ ├── daxpay-channel-wechat # 微信通道
│ ├── daxpay-channel-douyin # 抖音通道
│ ├── daxpay-channel-ums # 银联商务通道
│ └── ... # 共 13 个通道模块,均为编排层,不含 SDK
├── daxpay-plugin/ # 支付插件
│ ├── daxpay-plugin-easypay # 易支付协议插件
│ └── daxpay-plugin-risk # 支付风控插件 (黑名单 + 命中记录)
├── daxpay-demo/ # 功能演示模块
└── daxpay-start/ # 启动入口 (端口 9999)通道编排与对接的职责边界
DaxPay 的通道体系严格区分编排层 (主应用) 与对接层 (子应用),这是 SDK 隔离的核心设计:
| 职责 | 主应用 daxpay-channel/* | 子应用 channel-one / channel-two |
|---|---|---|
| 第三方 SDK 调用 | 无任何 SDK import | 直接调用 alipay-sdk / wxjava / 等 |
| 通道配置数据 CRUD | Entity / DAO / Controller | 无持久化 |
| 支付策略编排 | strategy → service | 无业务编排 |
| HTTP 声明式接口 | @HttpExchange client | @RestController 接收 |
| 签名 / 验签 | 业务签名 (RSA) | 通道签名 (SDK 内部) |
| 回调组装 | 转发至子应用验签解析 | 原始报文验签解析 |
调用机制 — 主应用通过 ChannelRestClientSupport 工厂为每个通道创建 @HttpExchange 代理,绑定到对应子应用 baseUrl;请求经过 ChannelTransportEncryptInterceptor 做 AES-GCM 传输加密;子应用响应统一 {code, msg, data} (DaxResult),主应用按 code == 0 判断成败。
通道路由分配 — 每个通道的 XxxClientConfig 在编译期绑定到 channelProperties.getOne() (端口 20100) 或 getTwo() (端口 20200):
| 绑定 channel-one (20100) | 绑定 channel-two (20200) |
|---|---|
| 支付宝、微信、抖音、银联商务 | 拉卡拉、海科融通、斗拱、乐刷、随行付、河马付、Adapay、富友、易宝 |
子服务拆分原则
主应用通过 HTTP 调用各独立子服务,拆分目的:
- 通道 SDK 依赖隔离 — 第三方 SDK 不污染主应用,避免 alipay-sdk / wxjava 等传递依赖冲突
- 独立升级 — 子服务可按通道单独发版,高频通道升级不影响低频通道
- 弹性伸缩 — 高频通道 (支付宝、微信) 可多实例独立扩缩容
通道子服务清单
| 子服务 | 语言 / 框架 | 对外能力 | 端口 | 通道数 |
|---|---|---|---|---|
dax-pay-channel-one | Java / Spring Boot 4.1 | 直连通道对接 | 20100 | 4 (支付宝/微信/抖音/银联商务) |
dax-pay-channel-one-go | Go / Gin 1.10 | 与 Java 版对等的实验副本 | 20100 | 同上 4 通道 |
dax-pay-channel-two | Java / Spring Boot 4.1 | 聚合通道对接 | 20200 | 8+ (拉卡拉/海科融通/乐刷/富友等) |
Java + Go 双实现 —
channel-one与channel-one-go端口、路由与响应契约完全对等,按团队技术栈与性能诉求按需选用;同端口的 Java 版与 Go 版切勿同时启动。
主应用与各子服务的调用关系:
子应用是主项目结构的轻量子集:platform 仅保留 core + common (i18n/json 等),不含 capability/service。通用契约 (DTO/接口/异常) 放入 platform-core,便于后续通道子应用复用。各子应用独立 git、独立版本,无 maven 依赖,仅结构对标。