OB Cloud 助力 GCash 分布式架构全面升级

2020年底，随着数据量激增，数据库存储空间逼近上限，GCash不得不投入大量人力物力进行数据拆分、数据清理，并试图不断的通过整理表空间以缓解燃眉之急。但此举治标不治本，当前数据库难以支撑业务平稳变更，服务连续性低，大量MySQL实例导致运维复杂度和运维成本直线上升，DBA团队陷入疲于奔命的低效循环。业务高速增长带来的极端“内忧”，大刀阔斧的IT改革势在必行。 

1. 成本居高不下
   1. GCash的日均交易量已达百万级，原数据库的数据量每月都在以大约10%的增幅在上涨。由于MySQL云数据库普遍存在的规格限制，数据激增后需要扩容存储时，CPU也不得不跟着升级，从而造成资源浪费。为此，GCash每月的储存成本居高不下；
2. 业务连续性隐患
   1. 随着数据量的累积， GCash最初数据库底层架构设计不够合理而产生的问题开始逐渐显露：这些问题大多存在于一些关键链路上的业务和服务，会导致当发生故障和稳定性问题时引起较大范围的影响和抖动。这种数据库架构上的不合理在业务的持续增长中被逐渐放大，导致GCash业务连续性隐患逐渐增加；
3. 用户体验受限
   1. GCash的交易、支付系统是承担在线突增流量最多的系统，很多高并发场景都需要借助该系统实现用户的流畅交易与支付，短时间内高并发SQL请求哪怕每条多延迟1毫秒，都会造成用户体验不佳。往常面对突发大流量请求，GCash原本使用的MySQL集群连接数受限于架构设计，对高并发请求极为敏感，很容易导致系统不稳定。

1. 数据迁移及压缩方案
   1. OceanBase专为GCash设计了一套非标准化数据迁移方案，结合蚂蚁集团SRE团队的最佳实践，通过在OMS打通应用访问数据库的数据源权重接口，将“源端权限回收，增量数据追平，目标端重新建立连接”的过程在一个自动化工作流中封装起来；此外，OceanBase 基于LSM-Tree的高级压缩技术，帮助GCash无损压缩海量数据；
2. 重新按照业务维度梳理架构
   1. 一方面，OceanBase将GCash的核心链路划为十余个大集群的几百个租户，这样一来，即使其中某一个集群发生抖动事件，整体的影响也仅有10%；另一方面，将GCash的核心链路和非核心链路分别放在不同的集群上，通过 OceanBase 的多租户能力，原有上百套 MySQL 实例，资源池化后仅用 10 余套集群全部容纳 ；
3. 三可用区高可用架构
   1. 传统数据库若遇到记账时数据库宕机，强行切换很有可能会丢失当笔记账数据。OceanBase采用三可用区高可用架构，任意可用区级别故障业务不中断。升级后，OceanBase仅单节点的连接数就约为MySQL的5～8倍，一个多节点集群的总连接数更多，足以平稳支持更大规模的流量冲击。