云上数据库助力鞋服物流仓储规模化降本

随着公司业务的快速增长，自 2021 年起，丽迅物流开始启动业务系统上云战略，致力于为客户提供更稳定、更灵活、更高效的服务。

1. 践行 SDK 分库模式存在问题
   1. 在仓储系统重构之前，丽迅物流的数据库是部署在 IDC 机房，采用的是 shardingJDBC 这种 SDK 分库模式，虽然它有去中心化的优势，但伴随着丽迅物流的业务增长，在实际应用过程中，发现其仍然存在问题。
      1. 应用启动慢：在应用启动的时候需要加载元数据，随着业务表增多会越来越慢；
         1. 性能问题明显：在跨库合并查询分页的时候，也会存在一些性能问题，比如应用内存拉爆、产生分布式慢事务锁表；
            1. 版本升级复杂：因为分库的逻辑写在应用内部，所以系统上线以后需要伴随组件升级，难度显著增大；
               1. 弹性能力弱：原有数据库架构想要扩容比较麻烦，除了需要新增一组数据库节点外，应用还要全部改一遍配置后再重新启动，对连接数耗用也较大。
2. 尝试 Proxy 模式分库分表仍遇挑战
   1. 正是由于以上原因，丽迅物流决定对仓储系统进行深度重构、升级。一开始，丽迅物流采用了云数据库+中间件的 Proxy 分库分表模式。最早使用的是更稳定的云数据库+中间件 DBLE，经过一段时间的使用一些问题开始暴露出来；
      1. 开源版本不稳定：DBLE 开源的组件版本稳定性不足，需要专人对分支版本进行维护与调优，升级困难；
         1. 配置文件结构不合理：数据库账号和分片规则配置在一起，导致各环境需要重复配置，运维复杂度增加；
            1. 分布式事务问题：比如全局表不一致、分布式事务锁表等问题；
               1. 运维成本增加：代理中间件增加，导致运维成本的增加。

1. 高级压缩技术
   1. ​通过先进的基于 LSM-Tree 的高级压缩技术，具有超高数据压缩比，有效降低存储成本 70% - 80%，进一步节约备份时间，为海量数据的规模化降本提供更出色的选择；
2. 自我保护能力
   1. ​ob_query_timeout、ob_trx_timeout 设计非常巧妙，用户可以根据业务场景对查询、事务的最大时间进行控制，防止业务被一些异常语句打满，非常好地保护了数据库；
3. 灵活的弹性能力
   1. ​OB Cloud 扩展性好、具备多级弹性能力，可以跟随丽迅物流的业务增长，随时进行扩缩容，包括存储也可以支持快速扩缩容，应对物流行业流量峰值；

1. 仓储管理系统（WMS）
   1. 通过使用两个 30 核 180GB 的分布式节点，替换了 5 组 64 核 128GB 的 MySQL 服务器，上线半年后，原来 5TB 的业务数据压缩到 600GB 左右，业务性能同步提升，至今运行稳定。
2. 财务管理系统（FMS）
   1. 丽迅物流的 FMS 财务管理系统有两组 64 核 128GB 的 MySQL 服务器，团队通过对其进行数据合并迁移，去掉 ShardingJDBC，迁移到一个 14 核 70GB 的集群上，迁移后，该系统业务量占比大量缩减，只需简单调整业务代码，原来一年 2.5TB 的数据可以压缩到 350GB。
3. 其他：客户系统、工单系统、HR系统、接口平台等
   1. 除以上核心系统外，公司内部的客户系统、工单系统、HR 系统、接口平台，也以综合形式部署在 14 核 70GB 的 OB Cloud 上，借助 OB Cloud 的集中式架构优势，充分利用了现有的服务器资源，大大减少了数据库使用率。

仓储、库存、财务等多套关键业务系统均已成功迁移到OB Cloud云数据库，丽迅物流获得同城双活、灵活高效、易观测的数据库体验，整体数据库成本降低 50%，开发和运维效率大大提升。

1. 显著降本
   1. ​在丽迅物流迁移上云的过程中，存储成本下降 70%；同时通过多租户共享实例，运维复杂度也下降，DMS 实例数也大大减少，总体数据库整体拥有成本下降50%；
2. 性能提升
   1. ​上线 OB Cloud 以后，在一些库存记账，仓库RF扫描等高并发场景下，性能提升 20%，对比之前的模式，硬件成本大幅度下降；
3. 轻松应对业务流量增长
   1. ​得益于 OB Cloud 天然具备的分布式能力，丽迅物流的业务系统很容易就可以进行水平、垂直扩容，轻松应对业务流量增长，平稳支撑公司业务周转。