实战解析｜大参林如何借助 OB Cloud 重构亿级会员系统

OceanBase 2024-12-04

331

*本文转载自公众号【参码思想汇】，转载时略有改动。

大参林是中国具有影响力的药品零售连锁集团化企业，截止 2024 年 9 月 30 日，大参林门店数量超过 16000 家，会员人数超过 1 亿。大参林在门店日常运营、门店下单交易、线上私域订单交易都围绕着会员进行。

为搭建一个高效的会员系统架构，实现数据驱动决策和精细化运营，大参林借助 OB Cloud 云数据库建设了自己的 CRM 系统【参林 CRM】。数据库系统切换到 OB Cloud 后，构建起现代数据库架构，数据库索引的查询效率、查询性能、响应速度等显著提升，同时也让顾客享受到更精准、更便捷、更高效的购物体验。

以下介绍了大参林会员 CRM 系统重构与优化的方案与实施解析，欢迎大家了解。

大参林原有的 CRM 系统是外采系统，采用本地化部署，包括旧的 CRM 管理后台、WSDL API 服务、营销规则引擎等。随着业务发展，原有的 CRM 系统已无法支撑大参林会员系统。其原有的数据库系统主要面临以下技术难点：

系统历史包袱重：原外采的系统存在内置的复杂业务流程，技术实现上也存在大量的技术债务，改动影响风险大；
缺失相关文档沉淀：作为一套外采的系统，缺少系统的设计文档，一直是在最上层做简单的维护，对于大部分开发人员，【外采 CRM 系统】是一个黑盒，没有人能全部了解系统的全部功能实现；
数据集成和同步：重构过程中，需确保数据在不同系统间的一致性和准确性；
系统性能与兼容性：超过一亿的会员，存储了数十张数据过亿的表，新旧系统之间的无缝集成和数据迁移是难点；
新旧系统切换风险管控：切换推广过程中，参林 CRM 任意一个接口出问题，或者与旧接口的业务有差异，都可能直接影响全国 16000 多家门店的销售收银业务。必须要把风险降到最低，风险可控。

在系统重构之前，产品和技术一起梳理了当前的系统功能清单，盘点哪些系统功能是应该在重构之后的系统中保留的，哪些是不属于参林 CRM 系统功能范围的。最终制定了功能重构、功能整合、功能迁移、功能删减四个策略。整套重构方案包含了重构改造的方案、数据双写方案、数据同步方案、灰度方案、回滚方案等。

（一）重构前-现状分析

CRM 系统是集团前端业务的核心底座系统之一，重构前的会员系统包括了【外采 CRM 系统】+【外挂 CRM 服务】，整套会员体系老旧且无法做到统一管理，对外提供了 WSDL、Restful 等多种协议，混乱且缺少文档和知识传递，不易维护。

图片来源：信息中心内部

其次，内嵌的管理后台组件，整个【外采 CRM 系统】管理后台，我们只能进行简单修改，交互老旧，系统逐渐无法满足业务发展；

最后，【外采 CRM 系统】还有一个对外提供服务的 WSDL API 的组件，上游系统通过 WSDL 协议来调用，因为组件化开发无法满足业务需求，又另外起了一个【外挂 CRM 服务】的 Java 服务，把部分新增的业务在这个 Java 服务上实现。对于上游系统来说，要用到 CRM 的服务，一部分要调用 WSDL API，一部分调用 Java 服务。上游对接的复杂度高，我们内部也无法做到统一管理。

基于对整个会员体系的分析，我们制定了重构计划，以下是重构的路线图：

图片来源：信息中心内部

（二）开始阶段-重构完成

重构目标：重构【参林 CRM】后台，统一 API 服务，下线原【外采 CRM 系统】；

策略简述：搭建新的数据结构，重构原 CRM 后台系统，数据变更迁移到新后台；原【外采 CRM 系统】对外提供的 WSDL API，迁移到 CRM 服务用 Java 重写。上游的所有请求统一归口到【外挂 CRM 服务】提供。

图片来源：信息中心内部

通过以上方式，可以快速实现对外采 CRM 系统的替换，并且实现对外提供服务的 API 集中统一管理，提升系统稳定性。

1. 数据双写

系统重构上线后，不是一次性切换的，会出现新旧两套系统并行的情况；这样就会产生新旧系统数据一致性问题。我们采用数据双写的策略，参考下图：

图片来源：信息中心内部

双写分两种情况，产生唯一 ID 的写业务和只是对信息更新的业务（主键不发生变化）。

数据新增，需要唯一 ID 的业务请求改为串联执行，主动拉取响应数据写入 OceanBase；
数据更新，非唯一 ID 写入变更的业务，由网关进行流量分发，然后前期以原旧数据库为准，那就先请求【外挂 CRM 服务】，得到成功状态码后网关开启异步的双写请求【参林 CRM】；
数据查询，前期对外 API 服务统一还是走【外挂 CRM 服务】，后期服务逐步切换到【参林 CRM】服务；

2. 如何解决数据库性能问题

数据量大：单表接近 20 亿条记录，查询时需要扫描大量数据，即使使用索引，单表也会导致索引树过大，影响查询性能；
I/O 压力：海量数据集中在一个表中，会对 I/O 产生巨大压力，增加查询延迟；
内存消耗：单表查询时，查询缓存和索引缓存的内存消耗会非常高，导致内存不足，从而影响查询速度。

3. 通过 OceanBase 分区可以有效缓解上述问题，优点如下

减小索引大小：将数据分散到多个分区，可以减小每个分区的索引大小，提高索引的查找效率；
并行处理：分区表可以利用多个节点进行并行处理，提升查询性能；
减少 I/O：分区可以减少每次查询所需的 I/O 操作，提升响应速度；

但同时，分区也需要注意一些事项：

分布式事务：OceanBase 底层已实现；
维护索引表：需要维护额外的索引表，满足非分区键的查询场景。主表数据变更，需要同步更新索引表。

4. 分区策略

图片来源：信息中心内部

/ 基于分区策略：以优惠券模块为例 /

第一，优惠券主表（coupon）：按券生成日期进行 range 分区。

新券码中内嵌了生成日期，有了券码就能命中单个分区。
对于存量旧券码，通过读取历史数据生成旧券码索引表（coupon_history_index），维护旧券码对应的生成日期，按旧券码进行 hash 分区。数据查找时先从旧券码索引表找到生成日期，再去优惠券主表查找明细，只命中单个分区；

第二，优惠券领取记录表（coupon_receive）：按会员 ID 进行 hash 分区。按会员查找只命中单个分区；

第三，优惠券索引表（coupon_index）：按券规则编码进行 hash 分区。对于非券码查找的其他场景，以券规则编码为必要条件进行查找才有实际意义，经常跟有效截止时间、券状态、推荐员工编码等字段组合进行查找。

5. 新旧系统数据同步方案

在新系统刚发布运行阶段，存在新旧系统并行的情况，会遇到以下问题：

数据同步与初始化：超过一亿的会员，存储了数十张数据过亿的表，新旧系统异构数据之间的无缝集成和数据迁移是难点；
数据一致性：重构过程中，需确保异构数据在不同系统间的一致性和准确性。

图片来源：信息中心内部

针对以上问题，有如下解决方案：

原旧数据库按照新 OB Cloud 数据接口生成数据库快照：【外采 CRM 系统】的库表与重构后的库表是异构，重构的系统需要对数据结构做一次重新设计，因此在原旧数据库做好快照临时表；
DataX 对 OB Cloud 进行数据初始化：DataX 是阿里巴巴离线数据同步工具，通过 DataX 很快完成 OB Cloud 的上百亿数据的初始化；
XXLJOB 进行增量同步：第一步中是在原旧数据库生成临时，不停机同步，同步期间肯定也有新的业务数据源源不断的写入旧库，所以用定时同步服务对会员最后修改时间进行扫描比对，最后进行同步覆盖。

（三）当前阶段

重构目标：重构【外挂 CRM 服务】服务，上游切换到重构后的【参林 CRM】，并下线【外挂 CRM 服务】；

策略简述：原【外挂 CRM 服务】对上游系统提供的 API 服务，重构到【参林 CRM】，重构的 API 向上兼容，所有上游系统的 API 调用切换到【参林 CRM】服务，保证整个切换过程上游系统无感。

图片来源：信息中心内部

1. 数据一致性

两类数据库一致实时同步要求非常高，为了规避这个技术难点，在重构的服务未成为核心调用服务前仍以【外挂 CRM 服务】为准，数据也以【外挂 CRM 服务】的旧数据库为准确数据源，利用网关进行双写。这里可以看到如果简单的靠 API 双写分布式事务很难保持数据库一致，我们再增加 XXLJOB 对两个库的会员数据对平，保证数据最终一致性；这时候我们可以简单的认为 OceanBase 此时是原旧数据库的一个从库。

在完成大部分读流量切换到【参林 CRM】后，原旧数据库存在大量的大数据报表、数据库 Job、以及外部一些历史原因其他系统直接连接数据库查询的需要进行改造。重构的收尾阶段需要多团队配合，开发时间不可控，这时候我们双写顺序反转以 OceanBase 先维护，定时任务进行逆向同步，把旧库作为从库来保障会员业务的实时一致性。此刻意味着原旧数据库已经不是核心数据源了。

2. 接口兼容

【参林 CRM】在技术设计阶段，就考虑到旧系统对上游接口的兼容性。确保上游系统无需改动或者极小的改动就能与重构后的【参林 CRM】的完成对接；