4. 直连架构总体设计
Host-to-Host（H2H）银行直连架构不是简单的“接口对接”，而是一套需要长期演进的企业级集成基础设施。它同时承载资金指令、对账文件、状态回执与安全凭证，任何一处设计缺陷都可能在日终批量时被放大为资金风险。本节围绕分层架构、模块划分、高可用、安全边界、可扩展性与技术选型原则六个维度，给出可落地的总体设计方法。
一、核心原理：五层分离与职责边界
直连架构的第一原则是“分层解耦”。将系统按职责切分为五层，每层只依赖下一层的抽象接口，避免业务逻辑与通信协议、报文格式相互渗透。
- 接入层：负责与企业客户系统、银行前置的物理与逻辑连接，处理连接池、限流、IP 白名单与 TLS 卸载。
- 协议适配层：将 SFTP、MQ、HTTPS、WebService 等异构通道统一为内部消息模型，屏蔽协议差异。
- 报文处理层：完成报文解析、字段校验、格式转换（如 XML↔JSON↔定长）、签名验签与加解密。
- 业务编排层：实现指令路由、幂等控制、状态机流转、重试与补偿，是直连架构的“大脑”。
- 数据与监控层：持久化交易流水、文件索引与审计日志，并提供指标采集与告警。
分层的价值在于变更隔离：当银行将通道从 SFTP 升级为 API 时，只需替换协议适配层实现，业务编排与报文处理保持稳定。
二、模块划分与高可用设计
在分层基础上，按“可独立部署、可独立扩容”原则划分模块。典型模块清单如下：
| 模块 | 核心职责 | 高可用策略 |
|---|---|---|
| 连接网关 | 通道接入与协议转换 | 多实例 + 负载均衡，会话粘性 |
| 报文引擎 | 解析、校验、转换 | 无状态水平扩展 |
| 编排服务 | 路由、幂等、状态机 | 集群选主 + 分布式锁 |
| 文件服务 | 对账文件收发与索引 | 共享存储 + 双活节点 |
| 调度中心 | 日终批量与重试触发 | Quartz 集群或分布式调度 |
高可用设计需覆盖三个层面：无状态服务通过多副本与健康检查实现故障秒级切换；有状态组件（数据库、MQ）采用主备或集群模式，并明确 RPO/RTO 目标；通道层对同一银行配置主备两条链路，主链路连续失败 N 次后自动降级切换。需注意，重试必须与幂等键配合，否则会造成重复扣款。
三、安全边界与可扩展性
安全边界应遵循“最小暴露面”原则。接入层部署于 DMZ，仅开放必要端口；报文处理与业务编排位于内网，禁止直接访问外网。关键控制点包括：双向 TLS 认证、报文级签名验签、敏感字段加密存储、密钥定期轮换，以及全链路审计日志。任何跨边界的调用都必须经过网关，禁止内网服务直连银行前置。
可扩展性体现在两个方向：横向扩展要求服务无状态、配置外置、会话不落地；纵向扩展要求新增银行或新报文类型时，只需增加适配器与配置，而非修改核心编排逻辑。推荐采用插件化设计，将银行差异封装为独立适配包。
# 新增一家银行直连的配置示例（适配器插件）
bank:
code: ICBC
channel: SFTP
host: 10.20.30.40
port: 22
auth: key
keyPath: /etc/h2h/keys/icbc_id_rsa
inboundDir: /recv/icbc
outboundDir: /send/icbc
retry: { max: 3, interval: 60s }
idempotentKey: msgId + bankCode四、技术选型原则与复盘
技术选型应服务于稳定性与可维护性，而非追求新技术。建议遵循以下原则：
- 成熟优先：通道与报文组件优先选择经过生产验证的框架，降低未知风险。
- 协议中立：内部消息模型不绑定具体银行协议，便于替换。
- 可观测性内建：选型时必须评估日志、指标、链路追踪的接入成本。
- 运维友好：配置热更新、灰度发布、一键回滚应作为硬性要求。
总体设计完成后，应输出架构决策记录（ADR），明确每层边界、模块接口、高可用指标与安全基线，作为后续开发与验收的依据。只有边界清晰、职责单一，直连架构才能在多银行、多协议、多批次的长期演进中保持稳定。