共计 4357 个字符，预计需要花费 11 分钟才能阅读完成。
致欧家居股份有限公司是中国跨境电商行业里的翘楚，产品先后进入西欧、北美、日本等超过 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，构建寰球跨区域的数据交融治理，为本人的跨境分布式电商业务提供持重的零碎撑持，为出海企业提供可复制的胜利案例
