查看原文
其他

GCash all in OB Cloud,打造菲律宾国民级钱包APP

与客户手拉手的 OceanBase 2023-09-28

GCash 创立于 2017 年,由菲律宾电信巨头 GlobeTelecom 推出,是菲律宾排名第一的移动钱包和该国首个双独角兽公司,主要为用户在智能手机上提供储蓄、贷款、保险和投资服务。截止 2022 年 6 月,GCash 注册用户数量达 6600 万,这相当于菲律宾平均每两人中,就有一人是 GCash 的用户。



作为东南亚的移动支付领头人,GCash 在业务迅速增长的大背景下,使用传统数据库面临着扩展性、性价比、稳定性等多重挑战。

第一,单机数据库成本高昂且存在性能瓶颈。在业务发展初期,其电子钱包业务通常采用单体架构的数据库,但随着业务发展再逐步扩容,若选择增加单机数据库,不但成本高昂,且依旧难以支撑密集的并发读写,存在性能瓶颈;若选择采用分库分表方案减轻数据库压力,不但技术改造成本非常高,稍有不合理的设计,系统的整体性能、可用性都将大打折扣。

第二,数据量激增,原有数据库存储空间逼近上限。随着业务不断增长,GCash 不得不投入大量资源进行数据拆分、数据清理。但这种方案治标不治本,整体数据库架构已经难以支撑业务的平稳变更,并且服务连续性无法保证,原有的云上传统型数据库难以支持如此大量的数据规模,技术团队只能定期删除数据来释放存储空间,工程量巨大且低效,运维成本也随之上升。

第三,数据安全性和业务连续性难以保证。电子钱包从属于支付领域,其收单、支付、计费等系统要求数据库对突发流量洪峰具备高抗压能力,短时间内高并发 SQL 请求哪怕每条多延迟 1 毫秒,都会影响用户体验。此外,支付领域对业务连续性和数据完整性要求非常高,传统数据库架构下如果出现机房断电、设备故障等情况,大概率会导致数据丢失和业务中断,无法保障数据的安全性和业务连续性。

正是由于业务的高速增长,带来了 GCash 的极端“内忧”,大刀阔斧的 IT 改革势在必行。OceanBase 作为承载中国头部电子钱包支付宝 100% 核心链路的数据库,在支付领域积累了丰富经验与方法论。2020 年初,OceanBase 受邀与 GCash 进行了跨国技术友好交流,开始探讨构建基于新一代数据库的存储底盘,并对方案进行了全面验证。2021 年,GCash 中数据量最大的系统完成迁移,2022 年底,GCash 所有系统全线投入 OB Cloud。



早在 2020 年,GCash 的日均交易量已达百万级,而原数据库的数据量每月都在以大约 10% 的增幅在上涨。由于传统云数据库普遍存在的规格限制,数据激增后需要扩容存储时,CPU 也不得不跟着升级,资源浪费明显。为此,GCash 每月的存储成本居高不下,当务之急是要将数据持续激增的传统数据库平滑迁移到一个真正具备平滑扩展的数据库上,OB Cloud 进入了 GCash 的视野。

决定与 OceanBase 进行合作后,摆在用户面前的难题是:如何在异构数据库之间做到不停机的无缝迁移?虽然 OceanBase 的 OMS 平台已经具备非常成熟的数据库迁移能力,但是考虑到 GCash 对业务连续性的极高要求,以及全站大规模迁移带来的复杂性,我们需要为客户提供一个尽可能降低业务改造成本,甚至无需停机发布的自动切换方案。

对此,OceanBase 专为 GCash 设计了一套专属的数据迁移方案,结合蚂蚁集团数据库 SRE 团队的最佳实践,通过在 OMS 平台直接打通应用访问数据库的数据源权重接口,将“源端权限回收,增量数据追平,目标端重新建立连接”的过程在一个自动化工作流中封装起来。该方案加持下,GCash 能够很顺利地在不停机的情况下将全站数百例数据库平滑顺畅地成功迁移至 OceanBase。

GCash 的某些电商业务,数据量巨大的库可能访问量并不是特别高,而另一些数据量较小的业务却访问量极大,这就导致在传统以实例为单位的单体数据库上无法实现计算资源和存储资源的灵活互补,性价比不高。而 OceanBase 基于 LSM-Tree 架构有天然的数据存储优势,再加上行列混存的自研引擎,大大降低了存储成本,同时 OceanBase 以集群为单位的多租户架构,可以自有分配管理计算资源和存储资源,做到动态资源互补均衡。传统数据库几个 TB 的数据在 OceanBase 上只有几百 GB,以 GCash 某单库为例,在迁移到 OceanBase 之后,骤降为原有的 1/10。

由于 OceanBase 高效的存储引擎,结合云上高速的块存储服务,可以做到节点级的磁盘平滑在线扩容。最终,GCash 实现数据存储空间节省 70% 以上,数据库资源成本节省 40% 以上,大大提效降本。



随着业务快速增长、数据量不断累积,带来的不仅仅是存储成本的攀升。与此同时,原有基于单体数据库架构设计产生的问题也开始逐渐显露。尤其是对于一些关键链路上的业务和服务,传统数据库可能会导致遇到单点抖动时业务爆炸半径难以控制。借由此次数据底盘迁移,OceanBase 帮助 GCash 重新按照业务维度梳理优化了全站的高可用架构。

GCash 的交易、支付系统是承担在线突增流量最多的系统,很多高并发场景都需要借助该系统实现用户的流畅交易与支付。往常面对突发大流量请求,GCash 原本使用的传统数据库集群连接数受限于架构设计,对高并发请求极为敏感,很容易导致系统不稳定。

上线 OceanBase 之后,在运维方面,GCash 原来数以百计的实例变为 10 多个集群,多租户架构下拓扑逻辑清晰,运维方便。同时对于业务上大表经常面临的 DDL 发布需求,OceanBase 无需表锁,实时生效,完美解决了过去大表 DDL 不敢做不能做的困境。通过对 GCash 的各个租户的特性进行分析,将只需要大量计算的业务和只需要大量存储的业务放到一个节点上,不同画像互补,充分利用资源。升级后,OceanBase 仅单节点的连接数就约为原有数据库的 5~8 倍,一个多节点集群的总连接数更多(百万级别),足以平稳支持更大规模的流量冲击。

同时对于 GCash 的业务快速增长,OceanBase 通过提供无感扩容的方案,在集群有冗余资源的前提下,在大促和波峰到来前,通过租户规格变配,对业务进行无感扩容。随着业务的发展,调整低负载租户的资源补充给高负载租户,大大降低成本。同时对于某些业务需要跑批拉数据的场景,可以使用读写分离的方式, 把对实时性要求不高的拉数业务路由到从副本上,保证了集群的稳定性,也节省了资源。

此外,承载了记账、对账及核算三大主要功能的账务系统,是支付行业最关键的核心系统之一,对数据的强一致性要求极为苛刻;传统数据库若遇到记账时数据库宕机,强行切换很有可能会丢失当笔记账数据,而 GCash 迁移至 OB Cloud 后,采用的三可用区高可用架构可以做到任何单机房故障时业务不中断,RPO=0,RTO<30 秒,让 GCash 具备了多可用区金融级容灾的能力。


经历过支付宝架构历代升级的 OceanBase,将在支付宝沉淀和打磨多年的最佳实践,完美复刻在此次 GCash 的数据架构重构中。来自中国的移动支付背后的技术实力,也正随着 GCsah 落地到“千岛之国”菲律宾。

搭载 OB Cloud 全新出发后,GCash 实现了分布式架构的全面升级,获得了数据存储空间节省 70%、数据库资源成本节省 40%、数据节点减少 80%,运维效率大幅提升。这种显著的降本增效能力不仅是 GCash 等海外本土企业的关键诉求,对于越来越多的国内出海企业也意义重大。GCash 与 OB Cloud 的跨国组合,让菲律宾居民的每一笔「支付」都算数!


往期推荐

▼ 点击下方「阅读原文」,看更多客户故事。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存