1. 项目背景与核心价值去年在开发一个电商平台时最让我头疼的就是支付对接。每个支付渠道的文档像天书一样微信支付要搞证书支付宝接口版本混乱银联的测试环境更是玄学。前后折腾了两个月才勉强跑通基础功能期间还因为签名错误被财务部门投诉了三次。这段经历让我萌生了开发通用支付中间件的想法——把各渠道的差异封装成统一接口让开发者只需关注业务逻辑。这个开源项目就是基于这样的痛点诞生的。它本质上是一个支付网关的万能适配器目前已整合微信支付V2/V3、支付宝当面付/APP支付、云闪付、PayPal等15主流支付渠道以及工商银行、建设银行等8家银行的快捷支付。最实用的地方在于所有渠道的交易、退款、分账等操作都采用完全一致的API设计用一套代码就能处理所有支付场景。2. 系统架构设计解析2.1 分层架构设计整个系统采用经典的三层架构[客户端] → [API网关] → [业务逻辑层] → [渠道适配层] → [各支付渠道]其中最具技术含量的是渠道适配层我们抽象出四个核心模型路由决策器根据金额、银行卡类型等自动选择最优支付渠道协议转换器将内部标准报文转换成各渠道特定格式签名验签引擎支持RSA/RSA2/HMAC-SHA256等多种算法结果处理器统一处理同步/异步通知解决各渠道回调差异2.2 关键数据结构支付订单的核心字段设计值得重点说明public class PaymentOrder { private String orderId; // 系统唯一订单号 private Integer amount; // 单位分避免小数精度问题 private String channelCode; // 支付渠道编码 private String subject; // 商品描述需符合各渠道规范 private String extraParams; // 渠道特定参数JSON格式 private Integer expireTime; // 订单有效期秒 // 状态机设计 private enum Status { INIT, PAYING, SUCCESS, REFUNDED, CLOSED } }这个设计解决了三个关键问题金额统一用整数分存储规避浮点运算精度问题通过extraParams字段灵活支持各渠道特殊需求严格的状态机控制避免重复支付等异常3. 核心功能实现细节3.1 统一支付接口所有渠道的支付请求最终都会收敛到这个核心方法public PaymentResponse unifiedPay(PaymentRequest request) { // 1. 参数校验金额0、subject非空等 validateParams(request); // 2. 创建系统订单含防重校验 PaymentOrder order createOrder(request); // 3. 选择支付渠道智能路由 PaymentChannel channel router.select(request); // 4. 执行渠道适配 PaymentStrategy strategy strategyFactory.getStrategy(channel.getCode()); return strategy.execute(order); }这里用到了策略模式工厂模式新增支付渠道只需实现PaymentStrategy接口即可。实测某农商行渠道从对接上线仅用了3小时。3.2 分账功能实现分账是最复杂的功能模块我们设计了两级分账体系graph TD A[主订单] -- B(平台分账) B -- C[商户A 70%] B -- D[服务商B 20%] B -- E[推广方C 10%] C -- F((自动提现))关键实现要点采用延时分账机制交易成功T1天执行分账比例支持动态计算如根据商品类目提供分账回查和争议处理接口具体到代码层面分账执行器的主要逻辑public void executeSplit(Long orderId) { // 获取分账规则可能来自商品/商户/活动配置 SplitRule rule ruleService.getRule(orderId); // 锁定账户余额防并发操作 accountService.lockAmount(rule); // 执行渠道分账支付宝/微信等实现不同 channelService.split(rule); // 生成分账凭证含电子签章 certificateService.generate(rule); }4. 生产环境踩坑实录4.1 微信证书热更新问题微信支付V3版本要求每30天更换API证书。最初我们采用停机更新的方式导致每月总有几次支付故障。后来设计出证书热加载方案使用WatchService监控证书目录变化采用双证书缓冲机制新旧证书并行1小时动态更新HttpClient的SSLContext核心代码片段public void watchCertificate() { WatchService watcher FileSystems.getDefault().newWatchService(); Paths.get(/certs).register(watcher, ENTRY_MODIFY); while (true) { WatchKey key watcher.take(); for (WatchEvent? event : key.pollEvents()) { if (event.context().toString().endsWith(.p12)) { reloadCertificate(); } } key.reset(); } }4.2 支付宝异步通知验签支付宝的通知验签有个巨坑文档里写的验签参数顺序必须和通知参数完全一致。我们花了2天时间排查才发现这个隐藏要求。最终解决方案是使用TreeMap自动排序所有参数过滤掉sign/sign_type等特殊字段拼接成URL查询字符串格式验签工具类关键实现public boolean checkAlipaySign(MapString,String params, String publicKey) { // 参数排序 SortedMapString,String sortedParams new TreeMap(params); // 拼接待签名字符串 StringBuilder sb new StringBuilder(); for (Map.EntryString,String entry : sortedParams.entrySet()) { String key entry.getKey(); if (sign.equals(key) || sign_type.equals(key)) continue; sb.append(key).append().append(entry.getValue()).append(); } String signContent sb.substring(0, sb.length()-1); // 实际验签操作 return RSA.verify(signContent, params.get(sign), publicKey); }5. 性能优化实践5.1 支付路由缓存支付渠道选择是个CPU密集型操作需要计算费率、检查限额等。我们开发了三级缓存策略L1缓存商户常用渠道ConcurrentHashMapL2缓存渠道健康状态Redis5秒过期L3缓存全量渠道数据本地Caffeine30秒刷新实测使路由决策耗时从平均23ms降低到1.2ms。缓存更新采用推拉结合模式定时任务每30秒全量拉取渠道数据渠道异常时主动推送失效事件5.2 异步化改造将支付流程中的非关键路径异步化日志记录改用Disruptor队列短信/邮件通知使用Spring Async数据统计用Flink实时处理改造前后对比指标同步方式异步方式平均响应时间320ms85ms99线1.2s210ms吞吐量800TPS4500TPS6. 安全防护方案6.1 防重放攻击支付系统最怕的就是重复支付。我们实现了一套基于Redis的防重体系请求唯一ID客户端生成UUID服务端校验订单幂等控制数据库唯一索引乐观锁签名时效性每个请求带时间戳超过5分钟失效关键防御代码public void checkReplayAttack(String requestId, long timestamp) { // 检查时间戳 if (System.currentTimeMillis() - timestamp 300000) { throw new SecurityException(请求已过期); } // Redis原子性设置 String key anti_replay: requestId; Boolean result redisTemplate.opsForValue() .setIfAbsent(key, 1, 5, TimeUnit.MINUTES); if (Boolean.FALSE.equals(result)) { throw new SecurityException(重复请求); } }6.2 敏感数据加密所有敏感信息都经过加密处理银行卡号采用AES-GCM加密后存储身份证号使用国密SM4算法通信加密全链路HTTPS双向证书认证这里特别提醒千万不要自己实现加密算法我们早期版本曾尝试优化AES实现结果导致安全审计不过关。后来全部改用BouncyCastle库的标准实现。7. 监控体系建设7.1 埋点设计在以下关键节点植入监控渠道接口调用成功率/耗时异常错误码统计资金操作流水系统资源使用率使用PrometheusGrafana构建的监控看板包含支付成功率热力图按渠道/时间段异常交易关联图谱资金对账差异预警7.2 智能预警规则我们配置了三层预警机制即时告警电话通知单渠道失败率30%持续5分钟余额不足预警日常预警企业微信对账差异100元证书7天内过期统计预警邮件报表周环比交易量下跌20%渠道费率异常波动8. 部署架构建议8.1 生产环境配置推荐的最低部署规格组件配置数量说明应用服务器4C8G2需开启AES-NI指令集加速Redis哨兵模式 6G内存3持久化必须开启MySQL主从集群 8C16G2需配置金融级事务隔离级别监控节点PrometheusAlertmanager1500GB SSD存储8.2 高可用方案我们采用的异地多活设计数据库阿里云PolarDB多可用区部署缓存Redis Cluster跨机房同步应用层Kubernetes集群HPA自动扩缩容流量调度DNS轮询Nginx灰度发布在去年双十一期间这套架构成功支撑了峰值12万笔/分钟的支付请求资金处理零差错。9. 扩展开发指南9.1 如何新增支付渠道以对接某某钱包为例实现PaymentStrategy接口public class SomeWalletStrategy implements PaymentStrategy { Override public PaymentResponse execute(PaymentOrder order) { // 组装渠道特定参数 SomeWalletRequest request convertOrder(order); // 调用渠道SDK SomeWalletClient client new SomeWalletClient(config); SomeWalletResponse response client.pay(request); // 转换统一响应格式 return convertResponse(response); } }在payment-strategy.xml中注册实现类配置渠道参数商户号、密钥等9.2 插件开发规范系统支持通过SPI机制扩展定义接口public interface PaymentPlugin { String getName(); void process(PaymentContext context); }创建META-INF/services/xxx.PaymentPlugin文件实现插件逻辑如风控插件、数据加密插件等10. 项目演进路线当前版本已稳定运行2年多后续计划智能风控引擎基于交易行为画像跨境支付支持正在对接SWIFT区块链支付网关实验性功能低代码配置平台可视化路由配置对于想参与贡献的开发者建议从这些方向入手补充单元测试覆盖率当前85%优化文档中的示例代码开发更多语言版本的SDK