共计 3581 个字符，预计需要花费 9 分钟才能阅读完成。
原作者：InfoQ 主编 赵钰莹
目前，国内某出名静止品牌在寰球经营着 12 家鞋服静止品牌，在全国有近万家线下门店，耐克、阿迪达斯、彪马、匡威等品牌门店绝大部分都是其代理经营，注册会员达 6000 多万，这些业务由旗下科技公司云盛海宏全面撑持。过来十年间，云海批发零碎是撑持全渠道、全品类运动鞋服的批发服务平台，撑持了 8000+ 线下门店的批发。
这样一家批发畛域的老牌企业是如何一步步从 MySQL 转向原生分布式数据库的？整体的架构变迁思路是怎么的？实际过后又是如何从老本视角评估 Oracle 和国产分布式数据库的 …… 近期，InfoQ 有幸采访到了云盛海宏首席架构师清脆，就上述问题逐个进行了探讨。
云盛海宏首席架构师清脆
背景介绍
在介绍云盛海宏的数据库架构设计之前，咱们先理解下其整体的业务背景。云盛海宏的外围业务是批发零碎，包含库存、终端批发以及用于团体外部的财务辅助零碎三大模块。
自 2013 年开始，云盛海宏就开始搭建整个数据库架构，两头因为业务的一直倒退经验了多轮迭代。2016 年之前，云盛海宏根本还处于传统批发时代，外部各大区自建设信息化零碎，保护本人的数据库架构，每天向总部上传业务数据，数据库采纳集中式单库，这种形式的长处是架构简略，毛病则随着业务倒退越来越显著，比方没有方法及时查看地区汇总数据，也无奈跨大区查看全国的实时库存等。
为了解决这些问题，云盛海宏在 2016 年上线了全新的架构——云海批发零碎，开启了数字化批发时代的架构演进之路。
倒退至今，云海批发零碎次要经验了三个阶段的演进。
阶段一：利用微服务化，实现数据共享，初步精细化经营，撑持数字化业务倒退
在这一阶段，云盛海宏应用的是微服务 + MySQL 分库分表的形式。立项之初，团队调研时思考到数据垂直切分的模式短时间内较稳固，MySQL 集群的开发难易水平对团队来说又比拟好把握，所以选定了 MySQL。
随着业务的飞速发展，很多问题超出了团队的原始预期，MySQL 集群对于简单报表剖析反对有余，团队尝试引入 Oracle 分担这部分需要，再通过 Otter 进行数据的实时同步，保障两边的数据残缺。对于 TOB 业务来说，外部报表十分要害，且对数据精度要求极高，冷热数据变动频繁，Oracle 的引入很好解决了实时报表方面的问题。
尔后，云海批发零碎撑持了业务高速倒退的五年，实现了很多小指标，比方实现了全国各地区、各大区的海量数据的存储，实现了数据实时共享，也达到了业务可视化的指标。然而随着业务的扩大和需要难度的减少，缓缓地呈现了一些新的挑战。首先，整个架构基于 MyCAT 做分库分表，在日常保护中，如果有新的业务，比方要减少表或者调整表，保护层面会减少人力老本，须要人工调整配置，而后再调用配置，须要破费很多精力。
其次，过后的 Otter 同步渠道曾经有 110 +，应用起来也没有那么现实。比方源端加表，指标端没有加表，或者是仅仅是字段的调整也可能导致一些同步的中断，这须要大量人力保护。最次要的是 Oracle 也遇到了一些瓶颈，例如海量数据无奈扩大、聚合库剖析时效差等问题。
阶段二：解决数据爆发式增长导致聚合库剖析时效性差
2020 年之前，Oracle 的单点性能曾经无奈横向扩大，团队开始踊跃寻求代替计划。此时，团队开始接触到 TiDB，并于过后 InfoQ 举办的 ArchSummit 大会上听到了时任 PingCAP 联结创始人兼 CTO 黄东旭的具体解说，后又通过具体的比照测试，次要集中在大数据量的查问以及简单 SQL 的查问性能两方面，发现 TiDB 能够解决 Oracle 存在的问题并且十分便捷。在外部小规模试用获得显著效果之后，云盛海宏最终决定疾速推动 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 都会带来比拟实用的个性和性能。接下来，云盛海宏会尝试从 Oracle 到 TiDB 的迁徙，逐步收拢数据库集群，更进一步升高运维累赘。在云盛海宏外部，Oracle 不会承当太多外围业务和写操作，迁徙根本面向 AP 类的数据和业务，所以这部分相对来说比拟容易，团队重心会放在前端数据迁徙，包含数据准确性校验。
采访中，清脆示意目前外部的 TiDB 集群的机器规模曾经达到 100 台，曾经部署了两个 TiDB 集群，别离承当前端和后盾的业务负载，打算在 2024 年前实现第三个 TiDB 集群的部署，承当前文所述的 AP 类业务，也就是目前 Oracle 承当的财务报表剖析负载。届时，云盛海宏的所有业务将全副运行至 TiDB 集群，Oracle 集群将逐步停用。
除此之外，整体架构将会逐步云化。以后，云盛海宏局部利用做了公有云化，将来会尝试将一些环境私有云化，比方开发、测试、培训、生产等。
数据库设计外围问题探讨
在批发行业，云盛海宏算得上是对技术投入较大的公司之一，而且联合其业务范围和体量，技术架构的搭建是存在肯定难度的，数据库选型和架构演进须要思考因素很多。在这个过程中，团队也摸索出了一些教训。
零售业有没有可能齐全舍弃 Oracle？
在批发畛域，有肯定历史的企业外部晚期必定部署着 Oracle 数据库，尤其是对精度要求极高的财务数据，那时可代替的国产数据库并不多。现在，国产数据库越来越成熟，可供选择的空间也越来越大，很多企业都开始尝试迁徙至其余数据库。
从云盛海宏的教训来看，批发畛域将来齐全有机会舍弃 Oracle，即使是要求极高的财务报表数据的解决也能够由国产数据库来负责。
选型上，企业须要提前依据业务特点做好压测，迁徙之前也须要做好相干预案，云盛海宏从 MySQL 到 TiDB，从 Oracle 到 TiDB 都做好了充沛的备案。
从老本视角来看，分布式数据库值吗？
当初谈到老本，根本涵盖软件受权费用、软件服务费用、硬件洽购费用以及日常维护费用等泛滥维度，企业外部状况不同也存在差别。
从云盛海宏的教训来看，TiDB 相比 Oracle 在软件受权费用上必定是具备显著劣势的；在软件服务费用方面，TiDB 自身的生态和社区建设（包含文档）绝对比较完善，但不排除一些国产数据库因为成熟度有余而尚无奈投入人力建设成熟的服务生态，这一点须要依据选型状况具体判断；在硬件洽购费用方面，云盛海宏应用前后差别不大；在日常保护方面，TiDB 的门槛低、易保护节约了大量人力老本。
如果与治理 MySQL 集群相比，数据备份、硬件故障解决、主从节点治理等绝对都比拟麻烦，但 TiDB 根本能够做到轻量级保护，前期云化之后可能会更进一步升高运维老本。
要不要全面云化？
如前文言，云盛海宏其实将来会逐渐云化，其团队外部对此也有很多思考。
采访中，清脆示意从整个集群而不是单个数据库的角度登程，云化在机房治理、网络安全、高可用、容灾等层面会比本地部署更有劣势。现在，TiDB 和阿里云也有单干，云化是比拟容易进行的，尤其是针对原有技术栈基于 MySQL 的企业。
智能化运维值不值得初期就思考？
最近两年，很多数据库都在踊跃整合 AI 能力，以期让部署、运行、运维等全过程更具智能化。对云盛海宏而言，企业外部对落地 AI 的诉求相对而言没那么迫切。
“智能化运维或者说引入 AI 能力取决于底层的根底建设是否到位，如果存算拆散或者是运维能力没有晋升，AI 就像是海市蜃楼。只有底层根底打好了，智能化运维能力施展出更大作用。比方，MySQL 的一些指标监控必定没有 TiDB 欠缺，没有这些指标，AI 监控就无从谈起了。”
