导读

云盛海宏的零售系统是支持全渠道、全品类运动鞋服的零售服务平台，为全球 8000+ 多家线下门店提供零售服务支持。发展至今，云海零售系统的数据库经历了从 MySQL 到 *** 再到全面 TiDB 的架构演进。

本文由 InfoQ 主编赵钰莹撰写，与云盛海宏首席架构师洪亮共同探讨了云海零售系统整体架构从 MySQL 到原生分布式变迁的思路和收获，以及数据库设计在零售业业务发展中的重要性。

目前，国内某知名运动品牌在全球经营着 12 家鞋服运动品牌，在全国有近万家线下门店，耐克、阿迪达斯、彪马、匡威等品牌门店绝大部分都是其代理经营，注册会员达 6000 多万，这些业务由旗下科技公司云盛海宏全面支撑。过去十年间，云海零售系统是支撑全渠道、全品类运动鞋服的零售服务平台，支撑了 8000+ 线下门店的零售。

这样一家零售领域的老牌企业是如何一步步从 MySQL 转向原生分布式数据库的？整体的架构变迁思路是怎样的？实践过后又是如何从成本视角评价 *** 和国产分布式数据库的......近期，InfoQ 有幸采访到了云盛海宏首席架构师洪亮，就上述问题逐一进行了探讨。

1 | 背景介绍

在介绍云盛海宏的数据库架构设计之前，我们先了解下其整体的业务背景。云盛海宏的核心业务是零售系统，包括库存、终端零售以及用于集团内部的财务辅助系统三大模块。

自 2013 年起，云盛海宏就开始搭建整个数据库架构，中间因为业务的不断发展经历了多轮迭代。2016 年之前，云盛海宏基本还处于传统零售时代，内部各大区自建设信息化系统，维护自己的数据库架构，每天向总部上传业务数据，数据库采用集中式单库，这种方式的优点是架构简单，缺点则随着业务发展越来越明显，比如没有办法及时查看地区汇总数据，也无法跨大区查看全国的实时库存等。

为了解决这些问题，云盛海宏在 2016 年上线了全新的架构——云海零售系统，开启了数字化零售时代的架构演进之路。

2 | 从 MySQL 到 *** 再到全面 TiDB 的架构演进

发展至今，云海零售系统主要经历了三个阶段的演进。

阶段一：应用微服务化，实现数据共享，初步精细化运营，支撑数字化业务发展

在这一阶段，云盛海宏使用的是微服务+ MySQL 分库分表的方式。立项之初，团队调研时考虑到数据垂直切分的模式短时间内较稳定，MySQL 集群的开发难易程度对团队来说又比较好掌握，所以选定了 MySQL 。

随着业务的飞速发展，很多问题超出了团队的原始预期，MySQL 集群对于复杂报表分析支持不足，团队尝试引入 *** 分担这部分需求，再通过 Otter 进行数据的实时同步，保障两边的数据完整。对于 TOB 业务来说，内部报表非常关键，且对数据精度要求极高，冷热数据变化频繁，*** 的引入很好解决了实时报表方面的问题。

此后，云海零售系统支撑了业务高速发展的五年，实现了很多小目标，比如实现了全国各地区、各大区的海量数据的存储，实现了数据实时共享，也达到了业务可视化的目标。但是随着业务的扩展和需求难度的增加，慢慢地出现了一些新的挑战。首先，整个架构基于 MyCAT 做分库分表，在日常维护中，如果有新的业务，比如要增加表或者调整表，维护层面会增加人力成本，需要人工调整配置，然后再调用配置，需要花费很多精力。

其次，当时的 Otter 同步渠道已经有 110 +，使用起来也没有那么理想。比如源端加表，目标端没有加表，或者是仅仅是字段的调整也可能导致一些同步的中断，这需要大量人力维护。最主要的是 *** 也遇到了一些瓶颈，例如海量数据无法扩展、聚合库分析时效差等问题。

阶段二：解决数据爆发式增长导致聚合库分析时效性差

2020 年之前，*** 的单点性能已经无法横向扩展，团队开始积极寻求替代方案。此时，团队开始接触到 TiDB ，并于当时 InfoQ 举办的 ArchSummit 大会上听到了时任 PingCAP 联合创始人兼 CTO 黄东旭的详细讲解，后又经过详细的对比测试，主要集中在大数据量的查询以及复杂 SQL 的查询性能两方面，发现 TiDB 可以解决 *** 存在的问题并且非常便捷。在内部小规模试用取得显著效果之后，云盛海宏最终决定快速推进 TiDB 集群的部署工作。

决定将 TiDB 部署到生产时的压测方案

（利用了 Percona 公司的开源工具 Percona-playback 实施的压测）

“2020 年，疫情爆发，这对我们的业务带来了很大冲击，我们开始发力做线上业务，技术侧最直接的压力来自于库存管理模块的变化。原本，从接到需要对接淘宝、京东、唯品会、抖音等平台的需求到最终落地需要三个月甚至半年的时间，但因为我们前期已经切换到了 TiDB ，技术栈层面做好了充足的准备，最终只用了两周时间就完成了单平台库存管理模块的调整”，洪亮如是说道。

2020 年引入 TiDB 之后的架构图

就内部工程师而言，TiDB 的部署推进得也非常顺利。首先，云盛海宏的主要业务都是在 MySQL 的基础上构建的，TiDB 完全兼容 MySQL 协议，从 MySQL 迁移到 TiDB 是比较顺利的。其次，TiDB 的日常运维、扩容、缩容非常方便，原来 DBA 按月或者季度为周期需要在凌晨一次性完成十几个实例的数据迁移，维护工作量巨大，而且数据迁移风险极高，一旦出现问题后果非常严重，引入 TiDB 之后基本不需要做迁移动作，更别提 MySQL 日常巡检、归档和备份这些动作耗费的时间。最后，MySQL 分库分表带来的局限性无法让团队快速应对变化，公司组织架构的每一次调整都会对业务带来一定冲击，团队需要快速消化这种冲击，TiDB 的引入让整个技术栈更具弹性。

阶段三：向全面部署分布式数据库迈进，初步探索架构云化

目前，云盛海宏内部已经完成了 MySQL 到 TiDB 的迁移，从最初的 4.0 版本到目前线上的 5.4.2 版本，每一次升级 TiDB 都会带来比较实用的特性和功能。接下来，云盛海宏会尝试从 *** 到 TiDB 的迁移，逐渐收拢数据库集群，更进一步降低运维负担。在云盛海宏内部，*** 不会承担太多核心业务和写操作，迁移基本面向 AP 类的数据和业务，所以这部分相对来说比较容易，团队重心会放在前端数据迁移，包括数据准确性校验。

采访中，洪亮表示目前内部的 TiDB 集群的机器规模已经达到 100 台，已经部署了两个 TiDB 集群，分别承担前端和后台的业务负载，计划在 2024 年前完成第三个 TiDB 集群的部署，承担前文所述的 AP 类业务，也就是目前 *** 承担的财务报表分析负载。届时，云盛海宏的所有业务将全部运行至 TiDB 集群，*** 集群将逐渐停用。

除此之外，整体架构将会逐渐云化。当前，云盛海宏部分应用做了私有云化，未来会尝试将一些环境公有云化，比如开发、测试、培训、生产等。

3 | 数据库设计核心问题探讨

在零售行业，云盛海宏算得上是对技术投入较大的公司之一，而且结合其业务范围和体量，技术架构的搭建是存在一定难度的，数据库选型和架构演进需要考虑因素很多。在这个过程中，团队也摸索出了一些经验。

零售业有没有可能完全舍弃 *** ？

在零售领域，有一定历史的企业内部早期肯定部署着 *** 数据库，尤其是对精度要求极高的财务数据，那时可替代的国产数据库并不多。如今，国产数据库越来越成熟，可供选择的空间也越来越大，很多企业都开始尝试迁移至其他数据库。

从云盛海宏的经验来看，零售领域未来完全有机会舍弃 *** ，即便是要求极高的财务报表数据的处理也可以由国产数据库来负责。

选型上，企业需要提前根据业务特点做好压测，迁移之前也需要做好相关预案，云盛海宏从 MySQL 到 TiDB ，从 *** 到 TiDB 都做好了充分的备案。

从成本视角来看，分布式数据库值吗？

现在谈到成本，基本涵盖软件授权费用、软件服务费用、硬件采购费用以及日常维护费用等众多维度，企业内部情况不同也存在差异。

从云盛海宏的经验来看，TiDB 相比 *** 在软件授权费用上肯定是具备明显优势的；在软件服务费用方面，TiDB 本身的生态和社区建设（包括文档）相对比较完善，但不排除一些国产数据库因为成熟度不足而尚无法投入人力建设成熟的服务生态，这一点需要根据选型情况具体判断；在硬件采购费用方面，云盛海宏使用前后差异不大；在日常维护方面，TiDB 的门槛低、易维护节约了大量人力成本。

如果与管理 MySQL 集群相比，数据备份、硬件故障处理、主从节点管理等相对都比较麻烦，但 TiDB 基本可以做到轻量级维护，后期云化之后可能会更进一步降低运维成本。

要不要全面云化？

如前文言，云盛海宏其实未来会逐步云化，其团队内部对此也有很多考虑。

采访中，洪亮表示从整个集群而不是单个数据库的角度出发，云化在机房管理、网络安全、高可用、容灾等层面会比本地部署更有优势。如今，TiDB 和***也有合作，云化是比较容易进行的，尤其是针对原有技术栈基于 MySQL 的企业。

智能化运维值不值得初期就考虑？

最近两年，很多数据库都在积极整合 AI 能力，以期让部署、运行、运维等全过程更具智能化。对云盛海宏而言，企业内部对落地 AI 的诉求相对而言没那么迫切。

“智能化运维或者说引入 AI 能力取决于底层的基础建设是否到位，如果存算分离或者是运维能力没有提升，AI 就像是空中楼阁。只有底层基础打好了，智能化运维才能发挥出更大作用。比如，MySQL 的一些指标监控肯定没有 TiDB 完善，没有这些指标，AI 监控就无从谈起了。”