​致欧家居股份有限公司是中国跨境电商行业里的翘楚，产品先后进入西欧、北美、日本等超过 50 个国家和地区市场，总体客户评价在各销售渠道排名前列。目前已经成为亚马逊欧洲第一大家居卖家，也是中国内陆最大的 B2C 跨境电商出口品牌之一。2021 年营收近 80 亿，同比增长 100%。

随着跨境业务的高速度发展，致欧对后端业务系统的承载能力要求不断提高，特别是对系统的稳定性，连续可用，安全性等各方面有了更高的要求，对此我们特别邀请了致欧家居总架构师朱辉，从当前业务现状出发，梳理出面临的一些挑战，以及相应的规划，给大家讲述致欧家居上线 OceanBase 的故事。

朱辉：第一代互联网从业者，从单片机到云，从 CGI 到 MicroService，见证、参与着行业的发展。实现了一个个的从零到一的跨越，完成了一个又一个创新的项目。

业务的现状

• 外购系统比较多，技术架构差异比较大。当前开发语言有 java、php、go，多个系统交织在一起，业务复杂度高；

• 数据库类型较多。MySQL、sqlserver、mongodb、postgres，加上业务系统参差不齐，使日常运维管理工作比较繁杂，对运维人员要求高； 

• 部分业务系统对 MySQL 使用比较深入，对数据库功能依赖高，使用了大量的存储过程与触发器，据不完全统计在其中一个业务库中存储过程多达 1200 多个，一个过程代码多达 6000 行。

• 数据库运维管理成本高。目前数据库实例分布在不同平台如 aws 欧洲、aws 北美、阿里云香港、阿里云欧洲以及自建 IDC 机房，不同地域的数据库实例、架构、资源不尽相同；不同地域、不同时区的差异在无形中加大了运维管理的要求与成本；

• 数据库实例以传统单实例为主，不能横向扩容，满足持续的业务增长需求。

面临的挑战

基于以上现状，致欧家居面临的挑战有：

• 业务推广流量大、有高并发需求，当前数据库基本上是单实例的传统数据库，随着业务的增长并不能做横向的扩容，活动推广，秒杀场景下易导致业务系统瘫痪；

• 数据量快速增长，传统数据库单实例难支撑，需按需对存储扩容；

• 业务高速发展，系统对数据库可用性、安全性、可靠性，运维稳定要求增加，单实例数据库 RTO 与 RPO 难以满足业务发展需求；

• 业务平台分布全球，数据需要融合汇聚，以做分析决策，对数据库要求有 HTAP 功能；

• 信息系统国产化自主可控要求；

• 公司开源节流，降本增效要求。

为什么选择 OceanBase 

从实际情况出发，致欧家居对目前主流的分布式数据库进行了对比了解，最后发现，无论是从数据库的产品功能还是产品体系上，OceanBase 都比较完善，可以很好地解决当前业务架构中的痛点。

具有完善的数据库功能与配套开发运维管理工具

• 优雅的内核架构；

① 基于 paxos 协议同步数据，节点之间使用 Paxos 复制数据要比 Raft 更优

② 多租户管理模式，可以很好的对系统资源按租户隔离，各租户之间可以各自指定 leader 节点，可以充分的利用各节点的 CPU 与 IO 隔离

③ 分区与表组功能可以按需设计，减少分布式事务

• 兼容 SQL 协议：同时兼容 MySQL 与 Oracle，特别是兼容存储过程、触发器、自定义函数，现有业务系统可以平滑的迁移，对业务系统无侵入；

• 存储：自研分布式存储引擎，数据压缩比高，同比 MySQL 有 5～7 倍压缩比；

• 数据副本：分为全能型(读写)、加密投票型副本、日志型、只读型，可根据不同业务性能与 SLA 要求选择相应的架构；

• 分布式事务：读写分离，DML 操作内存，读事务操作基线数据；

• 运维管理：丰富的性能视图，四大产品家族集开发、部署、数据迁移以及自动化运维于一体化；

• 数据迁移：基于 OMS 工具，按图索骥一站式迁移数据，集全量、增量、数据校验、反向同步链路于一体。

性能适配

在性能上，我们基于 OB 进行相应的性能验证，以查验对应的性能是否能满足业务的需求，以下是相关的基准测试情况：

• cpu:mem:disk=16c:100G memory:120G ssd

• 环境与版本信息: 专有云部署 3.2.2 版本

• 表数量：32

• 单表数据量：1kw

• 每个场景 thread 测试时间：5min

• 测试工具：sysbench

• 相关命令：sysbench --config-file=config oltp_point_select  --tables=32 --table_size=10000000 --threads=8 --db-ps-mode=disable --mysql-ignore-errors=6002,6004,4012,2013,4016 prepare

• 架构：同一机房三节点，三个数据节点，一个日志型节点，具体如下

• 测试结果：

• OS 监控：

通过以上的部署架构可以看到，OceanBase 在副本的选择上非常的灵活，可以根据不同的业务需求来选择副本类型。对应的数据库基测试 IO 都处于理想的状态，相应的 TPS 与 QPS 都符合预期。

遇到的问题与解决方案

我们在从 MySQL 实例迁移到 OceanBase 的过程遇到了不少问题，这些问题虽然给我们带来了不少麻烦，但是在 OceanBase 研发的技术支持下，都得到了很好的解决，下面列举几个比较典型的问题。

Q1：在 MySQL 模式下，对没有主键或唯一键的表迁移，OMS 不支持。

这个问题在 OMS 产品文档中有明确说明。由于我们的不少系统是外购来的，有不少表就存在有主键与唯一键这样的问题，且部分表的数据量还不小。

要如何解决这个问题呢，在我们与 OceanBase 产研同事的沟通中了解到，对于这种无主键或是唯一键的表，在 Oracle 模式下，对于这种表是可以支持的，其原因是由于 OMS 自动帮忙加了一个隐藏的主键，在正式切换上线时删除，而在 MySQL 模式下，在全量迁移完之后，增量数据同步时性能会非常差，对于大表甚至于没法做，对于这类表，目前只能通过类似左 datax 的数据传输工具来处理。

关于 datax+OMS 的解决方案——

表结构迁移：手动导出导入处理

数据迁移：使用 datax 做全量数据迁移

数据校验: OMS 支持单独选数据校验这一步

增量数据同步：这一步做不了

回退：使用 datax+OMS 反向同步

由于表数量不少，datax 的配置文件是以表为单位进行配置的，在这里我们 DIY 了一个脚本，自动生成配置文件，然后再批量执行迁移任务。

与此同时，反向同步也是一个全量的过程，这个过程我们提前测算好正向与回退的时间，以及业务的验证时间，变更的时间窗口为：正向+反向+2 倍验证的时间。

Q2：对于迁移有数据的表，存在索引名与表名相同时报错，如下表定义：

create table t_xxxxx(  `id` int unsigned not null auto_increament ,  `code` bigint(20),  ......);create index `code` on `t_xxxxx`(`code`);

对于迁移的表，存在列名与索引名相同时，OMS 不支持，OceanBase 的临时解决方案是通过改索引名的方式来解决，最终的解决方案则是通过 OMS 产品功能研发支持。

这个问题在反馈之后的两天内，产品就迅速解决了这个问题，效率很高。

Q3：存储过程不支持 GET DIAGNOSTICS CONDITION 语法。在我们的一个应用系统中，使用了大量的存储过程，其中有不少过程使用了 GET DIAGNOSTICS CONDITION 语法来获取 MySQL 执行过程的异常捕获。

经查验后发现内核不支持 GET DIAGNOSTICS CONDITION 异常捕获，若从业务侧出发来解决的话，300 多个存储过程中，有 200 多个过程用到了这个语法，代码量改动很大，所以最根本的解决方案是从内核上功能支持。

由于 OceanBase 内核对存储过程不支持异常的捕获处理，需要在内核上做功能改进，经过一个多月的研发，产品功能研发完成，业务代码无须做相应的调整，基本上可以做到平滑迁移。

收获、规划与期待

虽然在数据迁移、运维管理上，OMS 与 OCP 带来了很大的便利，但是，我们在实际过程中也遇到了不少的问题，特别是一些产品功能上还存在一些缺陷。这些问题在 OceanBase 工程师与研发团队的支持下，第一时间得到了响应，并对产品的不足之处及时进行了跟进与处理，最终得到了很好的解决，这种山穷水复疑无路，柳暗花明又一村的感觉，让致欧家居认识、收获了基于 OceanBase 的应用与实践心得：

• 数据迁移过程中要可以使用 OMS 与 datax 搭配使用，可以快速解决 MySQL 模式下无主建表的迁移；

• 外购系统中存在很多设计不规范的地方，如表字段、索引的命名；

• 对于表结构要尽可能的有主键设计，特别是一些核心表；

• 迁移到 OceanBase ，对于核心的大表需要认真的规划，如是否要分区、与其他相关联的表是否要考虑做表组；

接下来，我们计划继续使用 OMS 工具迁移其他业务系统到 OceanBase ，达到跨境多云数据融合目标，如下图所示：

在以上基础上，同时基于 OceanBase 的 HTAP 能力构建实时的分析业务平台。

当然，经此一役，我们更加坚信 OceanBase 在 100%自研的道路上，能更好的发挥自主研发的优势，碰到问题一定可以快速解决，哪怕是内核级的问题，对此我们也热切期待，OceanBase 在产品与功能上更上一层楼：

• OceanBase 的内核功能进一步完善与加强，更加完美的兼容 MySQL 语法，对于业务的适配更加友好。

• OMS 在数据的传输与转换过程中能胜任更多的场景，如从 sqlserver、postgres 等其他数据库迁移到 OceanBase ；支持基于列或是 SQL 的数据脱敏或转换。

后记（架构师感悟）——OceanBase 架构师何志勇：

致欧科技，作为跨境电商的翘楚，在面临业务爆发式增长，后端 IT 系统和运维带来极大挑战的背景下，毅然绝然的对当前系统与架构进行了改造、变革。在短短的两个月里，迁移了 6 个业务系统到 OceanBase。

虽然很大一定程度上得益于 OceanBase 提供的 OMS 迁移工具，但主要还是依靠致欧科技研发、运维团队的协作，以及 OceanBase 产品的研发力量的共同努力与支持。无论是在迁移前的测试验证，兼容适配，还是在最后的正式上线切割，都保持着认真负责，积极响应，一丝不苟的态度，最后在大家精诚合作的努力下，不断攻克一个个困难险阻，确保在设定的时间内，把多个业务系统迁移到 OceanBase。在这段时间时，与大家一起合作的每一天都是仰拾俯取，收获成长。

诚然，现在我们阶段性的取得了一定的成绩，但是雄关漫道真如铁，而今迈步从头越。致欧未来的规划与展望给了我们前行的压力与动力。期待在产研同学的支持下，OceanBase 能更好地赋能致欧，以及其他像致欧这样的企业，同时也期待，致欧能借助 OceanBase，构建全球跨区域的数据融合管理，为自己的跨境分布式电商业务提供稳健的系统支撑，为出海企业提供可复制的成功案例。