Hyperswitch项目中ProdIntent的架构优化与数据迁移

背景与问题分析

在Hyperswitch支付网关项目中，ProdIntent(产品意图)模块作为核心业务逻辑处理单元，当前面临着两个主要架构问题：

1. 作用域不清晰：当前的ProdIntent实现将产品类型(product_type)与用户(user scope)而非商户(merchant scope)绑定，这与实际业务逻辑不符。在支付场景中，产品类型应当归属于商户配置范畴，而非用户属性。

2. 数据存储分散：商户账户表(Merchant account)和仪表盘元数据(dashboard metadata)分散在不同schema中，导致系统维护复杂、查询效率低下，且存在数据一致性问题。

解决方案设计

架构重组方案

针对上述问题，我们设计了以下架构优化方案：

1. 商户账户表迁移：

   • 将商户账户表从原有schema迁移至公共账户schema(common accounts schema)
   • 建立统一的商户ID标识体系
   • 重构相关查询接口，确保所有服务都能通过公共schema访问商户数据

2. 仪表盘元数据整合：

   • 方案A：将v1部署指向v2的仪表盘元数据表
   • 方案B：将仪表盘元数据迁移至公共schema中的独立表
   • 执行历史数据迁移，确保业务连续性
   • 建立数据同步机制，处理过渡期间的增量数据

3. API层重构：

   • 废弃v1版本的仪表盘元数据路由
   • 统一使用v2版本的仪表盘元数据接口
   • 实现版本兼容层，平滑过渡现有调用

技术实现细节

数据迁移策略

1. 分阶段迁移：

   • 第一阶段：建立公共schema并初始化表结构
   • 第二阶段：实现双写机制，新旧系统同时写入
   • 第三阶段：批量迁移历史数据
   • 第四阶段：验证数据一致性后切换读操作

2. 数据一致性保障：

   • 采用事务性迁移确保数据完整
   • 实现数据校验脚本，对比源和目标数据
   • 建立回滚机制，应对迁移失败情况

3. 性能优化：

   • 对大表采用分批迁移策略
   • 在业务低峰期执行迁移
   • 建立索引优化查询性能

代码重构要点

1. 作用域转换：

   • 重构产品类型(product_type)的归属逻辑
   • 修改相关业务规则引擎
   • 更新权限校验逻辑，确保商户只能访问自有产品配置

2. API兼容处理：

   • 实现版本路由转发
   • 维护请求参数映射
   • 提供详细的变更日志和文档

实施影响评估

业务影响

1. 商户体验：

   • 产品配置将统一在商户层面管理
   • 简化多产品线管理流程
   • 提升配置的一致性和可维护性

2. 系统性能：

   • 减少跨schema查询提升性能
   • 统一缓存策略提高命中率
   • 优化后的数据结构降低IO压力

技术债务清理

本次重构将解决以下技术债务：

• 消除数据存储冗余
• 统一数据访问路径
• 明确业务实体的作用域边界
• 简化后续功能扩展的复杂度

最佳实践建议

对于类似支付系统的架构优化，建议：

1. 领域驱动设计：明确区分用户域和商户域的边界，避免业务逻辑混淆。

2. 渐进式重构：采用分阶段迁移策略，降低对生产环境的影响。

3. 数据双写过渡：在迁移期间实现新旧系统双写，确保无缝切换。

4. 全面监控：对迁移过程实施全方位监控，及时发现问题。

5. 文档同步更新：确保架构变更与系统文档保持同步，方便团队协作。

通过本次ProdIntent模块的优化，Hyperswitch项目将获得更清晰的架构、更高的性能以及更好的可维护性，为后续业务扩展奠定坚实基础。