Baizer

中台上线方案 ​

中台化 ​

中台化上线概述：https://xf12607haf.feishu.cn/wiki/J6gLw0EJniEYHMkRRi4cnKFenBc

目的 ​

  • 项目中台化（统一使用平台组提供的最新框架Java Framework、项目结构）

  • 合并多个项目（ERP采购平台、质检平台 、供应商平台、采购员平台、交易平台APP端）

    • 采购PC端和交易平台APP端（采购移动端）有大部分重合的业务及功能，可进行融合重构，整合为采购中台
      • 数据迁移、合并
      • 业务合并、重构

价值 ​

  • 缩减业务服务（下线10+个服务）

  • 缩减业务表（移除30+张表）

  • 优化用户体验、降低系统复杂度

  • 降低维护成本、增强系统扩展性

  • 符合集团规划（大力发展ToB业务）

上线步骤 ​

为分散风险，分三阶段上线

阶段一：初始化阶段 ​
  • 上线老系统：兼容新系统的防腐层、迁移开关等（支持读写）
  • 数据迁移：历史数据全量迁移，实时数据增量迁移
阶段二：灰度阶段 ​
  • 上线新系统：验证所有新功能（只读）
阶段三：全量阶段 ​
  • 老系统切换开关：
    • 老系统流量全部转移至新系统
    • 关闭老系统写的功能，只允许读数据，确保老系统不会产生新数据
  • 新系统正式全面使用（支持读写）
后续阶段 ​
  • 老系统移除防腐层：配合上下游系统对接新中台的接口
  • 下线老系统

数据迁移步骤 ​

https://xf12607haf.feishu.cn/wiki/wikcnxcItpLDGSHFERGsi73D6Vb

全量+增量同步

首先将数据分为两类，历史数据和新数据，分别采用全量同步和增量同步。

  • 历史数据：整理新旧表映射关系，通过手动编写SQL进行全量迁移（数仓同事处理）
  • 新数据 ：
    • 方案一：通过代码同步，写旧库的同时，对调用新系统的接口同步新增（对业务代码侵入大）
    • 方案二：业务人员手动在新系统中同步新增
    • 方案三：通过SQL增量同步

新系统切换后，回收老系统写入权限，确保没有数据新增。

全面使用新系统。

中台化遇到的问题 ​

在新系统中，如何兼容中间状态的单据走后续的流程（在全量阶段下） ​

比如一张订单，上游流程装车发货是在旧系统跑，而下游流程到货入库却要在新系统跑，在新旧系统流程有差异的情况下，如何保证单据正常走完流程？

  • 为什么新旧系统会有差异？

    • 重构和中台化的过程中，产品也会一些流程进行优化。相当于变相迭代版本，保证有中台化期间研发能有产出。

  • 解决：在新系统中增加特殊处理，在不一样的流程中（如自动销售流程）增加判断，判断单据是否为迁移数据，是的话则为其做兼容处理

    • 如果区分迁移数据：
      • 通过企业ID（EntId）区分。
      • 通过单据ID长度区分（新系统统一使用雪花算法生成分布式ID，长度为18）。
    • 迁移数据兼容新自动销售流程

兼容新中台单据回传老系统的问题（在全量阶段下） ​

例如库存回调，在新系统中为订单创建流水，发送MQ给库存系统，库存回调时可能会回调到旧系统，旧系统处理时是查询不到新系统的数据的，就会处理失败。

  • 为什么库存回调时可能会回调到旧系统？
    • 新系统接入库存系统的方式是和旧系统一样，通过监听同一个Topic来处理。 那就是两个消费者中随机消费。
  • 库存系统增加一个Topic或者更换一种对接方式HTTP不可以吗？
    • 此处重构是针对我们自己的系统，其它上下游系统应该是无感的，不能影响它们。
  • 解决：旧系统增加兼容处理，回调处理时如果查询为空则转发至新系统处理。
    • 后期旧系统下线后就没有这个问题了，相当于移除了旧系统的订阅。

上下游系统兼容的问题 ​

此处重构是针对我们自己的系统，其它上下游系统应该是无感的，不能影响它们。所以初期时只能我们去兼容，后期等待产品提给对应项目组提需求接入我们的新系统。

  • 对于下游系统：在新系统中对接下游系统提供的接口即可，无需特殊处理（需要注意接口入参与旧系统保持一致）
  • 对于上游系统：提供给外部系统调用的接口，需要在旧系统中增加防腐层，通过开关控制处理。
    • 上游系统：库存盘点、价格中台、供应链金融等
    • 例如：价格中台调用旧系统查询数据，在新系统启用的情况下，需要将该接口转发到新系统查询数据。
    • 采购模块上下游接口兼容