核心生产系统的数据库，从接到替换需求到完成分布式升级，需要多久？一个月，这是美年大健康的回答。一个月集中调配各种资源，美年大健康完成了应用程序基本零改造的平滑迁移，新数据库在成本更低的前提下，有力保障了全国数百家分院业务的稳定运行。
美年大健康（以下简称美年）产业控股股份有限公司成立于 2004 年，是一家集健康咨询、健康评估、健康管理为一体的健康体检与医疗集团，旗下“美年”、“慈铭”、“奥亚”、“美兆”四大品牌，目前，在全国 300 多个城市有 600 多家分院，每年体检人数超过 3000 万。
如此大的业务量背后需要一套功能强大的体检系统来支持。实际上，美年不仅业务量大，业务类型也很多，集团需要根据用户需求的变化和体检设备的升级不断推出新的业务类型，比如，2022 年 9 月新推出的“脑睿佳”专项脑检产品就颇受欢迎。
2023 年 3 月，美年 SOA 系统(Sale & Order Assistant System，销售制单辅助系统)原来使用的 RDS 告急，监控告警信息显示，随着新体检系统的部署上线，带来数据量的增长很快将突破 RDS 上限。黄伟表示：“如果再不更换数据库，SOA 系统随时有可能崩盘，为了保证新的体检系统顺利上线到各个分院，必须马上进行数据库升级。”在美年 SOA 系统数据库升级至 OceanBase 后，有效保障了各个分院销售制单业务的稳定运行，也为美年的数字化转型提供了坚实的支撑。
随着人们生活水平的提高和健康保健意识的增强，健康体验行业保持高速增长态势。同时，健康领域的消费升级和品质的提升也成为主要消费趋势。针对市场变化， 2019 年，美年提出了“医疗导向、品质驱动、服务支撑、创新引领”十六字核心战略，随后又提出“All in 数字化”来大力推动公司的数字化转型。
作为美年生产系统的体检软件是美年数字化转型的重要支撑。然而，这套业务系统已经很老旧了，该系统用十多年前比较流行的编程语言 PowerBulider（PB）开发，采用的也是当年流行的 C/S 架构。随着网络环境的改善和软件技术的不断进步，这套 C/S 架构系统逐步落后。2021 年，美年决定重新开发一套新的健康体检系统，这才有了今天的「扁鹊」和「SOA」系统。
扁鹊系统是美年新一代智慧体检管理 SaaS 平台。相比前一代系统，扁鹊在功能上有很大提升，它能实现分时预约、快速登记、智慧导诊、数据实时互通、样本追踪、检查类异常结果自动上报等功能，是美年提升医疗质量、客户体验、精细化管理水平以及创新能力的主要平台。
SOA 是美年为销售提供订单报价和落单的系统，用以提升订单的过程效率及管理规范，实现本地单、全国单、多品牌订单和实体卡等关键订单的业务在线化和管理协同。
SOA 是扁鹊系统的一部分，它作为扁鹊系统的一个独立功能模块，于 2020 年 6 月 30 日先行开发完成，并开始在各个分院上线。随着 2022 年中，新一代扁鹊智慧体检 Saas 系统的正式上线，SOA 系统也产生了新的版本迭代升级需求，例如：老系统订单、套餐数据的同步等，这类需求很明显带来了大量业务数据的增长。初期扁鹊系统上线比较慢，到去年年底共上线了 10 家分院。进入 2023 年，扁鹊上线节奏明显加快，到 3 月份上线了近 200 家分院。正当研发部门准备在剩下的 300 多家分院开始上线时——作为扁鹊业务支撑的 SOA 系统数据库报警了。原来，SOA 最早选的数据库是 RDS，到 3 月份的时候数据库容量逐渐承受不住。
“有一天 DBA 来告诉我，SOA 系统的 RDS 存储空间已经超过上限。后面还有 300 多家分院等着上，按目前的增长速度很快就要接近 RDS 极限。”美年高级研发总监黄伟表示。一旦数据库崩溃告急，所有订单都无法处理，美年的业务也将面临停摆风险。黄伟意识到替换数据库已经是当务之急，并给自己定了一个目标：在一个月内解决数据库升级的问题。
扁鹊系统和 SOA 两个系统都是关乎美年未来业务发展的关键项目。相比扁鹊系统而言，SOA 系统设计要早两年，有些设计没有考虑到后来业务大规模增长的情况。当黄伟仔细审视 SOA 数据库系统的时候才发现，SOA 的数据库设计存在一些不合理的地方，否则就不会出现眼下的局面。
比如，有超过 2 亿行的单表存在，这样的设计原本可以优化；目前数据库存储的数据量达数 TB，但其中存在很多应该归档的冷数据和一些无用数据……“过去有些分院对数据管理没有严格要求，订单没有很好地维护，有些订单早该结束了也不结束，还有些无主数据，需要进行清理和分类。” 黄伟说。不过，这些工作现在暂时顾不上，只能等到新数据库上线后再进行补救了，现在最要紧的把这个 MySQL 数据库替换下来。
黄伟介绍：“我们对于新的数据库第一个要求是要能承受得住不断增长的数据量，也就是要高度可扩展。其次，新数据库要能高度兼容 MySQL，否则就要对应用程序进行大量改造，时间上不允许。第三，不能比 MySQL 慢。最后，成本希望能与 MySQL 持平，如有增加也应该是有少许增加。”
基于以上几点需求，美年进行了数据库的测试、对比、选型，通过全面的评估和比较，OceanBase 满足了美年对数据库的各项要求，最终确认选型 OceanBase。何晶是美年后端开发专家，具体负责从 MySQL 数据库升级到 OceanBase 的工作。何晶介绍，为了评估 OceanBase 对 MySQL 的兼容性，美年对 OceanBase 用生产中的流量进行了全流量的回放，结果表明，99% 以上的语句是兼容的。而在性能方面，评估结果显示 OceanBase 80% 优于 MySQL。
SOA 系统中原来有一些非常复杂的 SQL 语句。比如，有多表聚合，还有很多子查询，在数据量不大的时候，性能降低不明显，一旦数据量达到一定程度，性能就明显下来了。针对剩下的 20% 不如 MySQL 的地方，开发人员做了针对性的优化以后，数据库的性能也有明显的改进。
在完成了对 SQL 语句的优化后，美年在 OceanBase 的支持下制订了详细的迁移规划，并在测试环境和预发布环境中进行了演练。最后在今年 4 月份，即下半年体检旺季到来之前顺利地完成了从 MySQL 到 OceanBase 的迁移。
数据库迁移的结果让美年非常满意。黄伟表示，作为一款分布式数据库，OceanBase 能稳定应对目前的 SOA 订单数据及未来的业务增长，在性能上也满足了需求。同时，在成本上也有节省，尤其在存储费用上。借助数据压缩技术，原来 TB 级的数据量经过数据的清理和压缩，现在只有 GB 级，数据压缩了 5/6，存储成本下降非常明显。
此外，上线 OceanBase 还降低了运维人员的负担，在一定程度上也等于降低成本。黄伟介绍，OceanBase 提供的工作台和一些工具，可以自动诊断数据库的问题，能对 SQL 进行审查并提出修改建议。另外，以往很多工作需要开发人员与 DBA 进行沟通，现在有了工作台和工具，研发人员自己就可以利用它们来进行业务的优化。
OceanBase 上线还有一个让黄伟感到很高兴的是：OceanBase 的主备集群也非常完美地契合了美年体检系统两地三中心的容灾架构。现在，美年的 SOA 系统在北京和上海两地各部署一套，上海为生产中心（两个可用区分开部署），北京为灾备中心，生产中心和容灾中心可以实现一键切换。相比美年其他一些系统灾备数据需要通过中间件来传输，SOA 将逻辑复制变成了物理复制，非常方便。
另外，OceanBase 数据库采用多副本，支持读写分离，其只读节点可以专门用作数据的统计和分析任务，供数据团队使用，避免了对正常业务的干扰。同时，因为不用再单独部署一个数据库，降低了系统的复杂性。比如 BI 部门就可以很好地利用只读节点进行日常的数据抽取。
鉴于 OceanBase 在 SOA 系统中的良好表现，另一核心系统「扁鹊」也采用了OceanBase 来进行数据归档和定制化改造。用 OceanBase 进行数据聚合后，一些查询可以直接接入到 OceanBase 中进行，相当于利用 OceanBase 做了扁鹊全量的数据聚合，保证了一些 2C 的业务数据直接查询。另外，美年还利用 OceanBase 来保存一些非热点数据，如过往三年的体检数据，为客户提供一些定制化改造服务，借助 OceanBase 至少保存 3 年以上的数据随时调用，方便客户拿到体检报告时，可以及时调取以前的数据来对比身体健康的变化。
对于未来的规划，黄伟表示，美年会结合 OceanBase 的特点对现有架构进行优化，提高可用性，以及进一步优化公司的数据存储体系，降低成本。另外，黄伟透露，他对 Serverless 数据库技术非常感兴趣。因为体检行业具有明显的潮汐特征，上午业务量高，下午业务量很少，非常适合 Serverless，希望能尽快引入 Serverless 技术，从而更好地赋能美年的业务、助力美年的数字化转型进程。
