致欧家居股份有限公司是中国跨境电商行业里的翘楚，产品先后进入西欧、北美、日本等超过50个国家和地区市场，总体客户评价在各销售渠道排名前列。目前已经成为亚马逊欧洲第一大家居卖家，也是中国内陆最大的B2C跨境电商出口品牌之一。年营收近80亿，同比增长%。
随着跨境业务的高速度发展，致欧对后端业务系统的承载能力要求不断提高，特别是对系统的稳定性，连续可用，安全性等各方面有了更高的要求，对此我们特别邀请了致欧家居总架构师朱辉，从当前业务现状出发，梳理出面临的一些挑战，以及相应的规划，给大家讲述致欧家居上线OceanBase的故事。
作者简介：
朱辉：第一代互联网从业者，从单片机到云，从CGI到MicroService，见证、参与着行业的发展。实现了一个个的从零到一的跨越，完成了一个又一个创新的项目。
业务的现状
外购系统比较多，技术架构差异比较大。当前开发语言有java、php、go，多个系统交织在一起，业务复杂度高；
数据库类型较多。MySQL、sqlserver、mongodb、postgres，加上业务系统参差不齐，使日常运维管理工作比较繁杂，对运维人员要求高；
部分业务系统对MySQL使用比较深入，对数据库功能依赖高，使用了大量的存储过程与触发器，据不完全统计在其中一个业务库中存储过程多达多个，一个过程代码多达行。
数据库运维管理成本高。目前数据库实例分布在不同平台如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:Gmemory:Gssd
环境与版本信息:专有云部署3.2.2版本
表数量：32
单表数据量：1kw
每个场景thread测试时间：5min
测试工具：sysbench
相关命令：sysbench--config-file=configoltp_point_select--tables=32--table_size=00000--threads=8--db-ps-mode=disable--mysql-ignore-errors=,,,,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：对于迁移有数据的表，存在索引名与表名相同时报错，如下表定义：
createtablet_xxxxx(`id`intunsignednotnullauto_increament,`code`bigint(20),......);createindex`code`on`t_xxxxx`(`code`);
对于迁移的表，存在列名与索引名相同时，OMS不支持，OceanBase的临时解决方案是通过改索引名的方式来解决，最终的解决方案则是通过OMS产品功能研发支持。
这个问题在反馈之后的两天内，产品就迅速解决了这个问题，效率很高。
Q3：存储过程不支持GETDIAGNOSTICSCONDITION语法。
在我们的一个应用系统中，使用了大量的存储过程，其中有不少过程使用了GETDIAGNOSTICSCONDITION语法来获取MySQL执行过程的异常捕获。
经查验后发现内核不支持GETDIAGNOSTICSCONDITION异常捕获，若从业务侧出发来解决的话，多个存储过程中，有多个过程用到了这个语法，代码量改动很大，所以最根本的解决方案是从内核上功能支持。
由于OceanBase内核对存储过程不支持异常的捕获处理，需要在内核上做功能改进，经过一个多月的研发，产品功能研发完成，业务代码无须做相应的调整，基本上可以做到平滑迁移。
收获、规划与期待
虽然在数据迁移、运维管理上，OMS与OCP带来了很大的便利，但是，我们在实际过程中也遇到了不少的问题，特别是一些产品功能上还存在一些缺陷。这些问题在OceanBase工程师与研发团队的支持下，第一时间得到了响应，并对产品的不足之处及时进行了跟进与处理，最终得到了很好的解决，这种山穷水复疑无路，柳暗花明又一村的感觉，让致欧家居认识、收获了基于OceanBase的应用与实践心得：
数据迁移过程中要可以使用OMS与datax搭配使用，可以快速解决MySQL模式下无主建表的迁移；
外购系统中存在很多设计不规范的地方，如表字段、索引的命名；
对于表结构要尽可能的有主键设计，特别是一些核心表；
迁移到OceanBase，对于核心的大表需要认真的规划，如是否要分区、与其他相关联的表是否要考虑做表组；
接下来，我们计划继续使用OMS工具迁移其他业务系统到OceanBase，达到跨境多云数据融合目标，如下图所示：
在以上基础上，同时基于OceanBase的HTAP能力构建实时的分析业务平台。
当然，经此一役，我们更加坚信OceanBase在%自研的道路上，能更好的发挥自主研发的优势，碰到问题一定可以快速解决，哪怕是内核级的问题，对此我们也热切期待，OceanBase在产品与功能上更上一层楼：
OceanBase的内核功能进一步完善与加强，更加完美的兼容MySQL语法，对于业务的适配更加友好。
OMS在数据的传输与转换过程中能胜任更多的场景，如从sqlserver、postgres等其他数据库迁移到OceanBase；支持基于列或是SQL的数据脱敏或转换。
后记（架构师感悟）——
OceanBase架构师何志勇：
致欧科技，作为跨境电商的翘楚，在面临业务爆发式增长，后端IT系统和运维带来极大挑战的背景下，毅然绝然的对当前系统与架构进行了改造、变革。在短短的两个月里，迁移了6个业务系统到OceanBase。
虽然很大一定程度上得益于OceanBase提供的OMS迁移工具，但主要还是依靠致欧科技研发、运维团队的协作，以及OceanBase产品的研发力量的共同努力与支持。无论是在迁移前的测试验证，兼容适配，还是在最后的正式上线切割，都保持着认真负责，积极响应，一丝不苟的态度，最后在大家精诚合作的努力下，不断攻克一个个困难险阻，确保在设定的时间内，把多个业务系统迁移到OceanBase。在这段时间时，与大家一起合作的每一天都是仰拾俯取，收获成长。
诚然，现在我们阶段性的取得了一定的成绩，但是雄关漫道真如铁，而今迈步从头越。致欧未来的规划与展望给了我们前行的压力与动力。期待在产研同学的支持下，OceanBase能更好地赋能致欧，以及其他像致欧这样的企业，同时也期待，致欧能借助OceanBase，构建全球跨区域的数据融合管理，为自己的跨境分布式电商业务提供稳健的系统支撑，为出海企业提供可复制的成功案例。