解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始

ywz888
发布于 2022-10-9 10:42
浏览
0收藏

根据麦肯锡相关报告显示,2020 年全球支付业收入 11 年来首次下降。黑天鹅事件让支付行为发生重大转变,现金使用量大幅下降,商务服务从线下快速转移至线上,这些转变为支付参与者带来了新的机会与挑战。

 

2021 年,支付业收入指标快速修复反弹,其中,数字支付在面对危机时展现出来的敏捷性成为推动经济更快复苏的重要因素之一。如菲律宾电子钱包 GCash 在2022 年 Q1,注册用户数首次超过 6000 万,达到覆盖菲律宾 83% 成年人口的里程碑。

 

在此轮快速修复与爆发增长中,企业间的竞争优势之战也拉开帷幕。整个支付业开启二次变革,由多场景单一服务向全场景数字化运营转变,数字支付从便利选择变为基本服务,为数字化经济和产业互联网注入新的活力。

 

部分企业已经通过基础设施升级、技术架构迭代和新技术的引入,通过科技创新手段提升了成本控制能力、提高了服务质量、优化了单位成本生产效益,继续扩大自身优势和市场规模。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

数字支付面临新挑战

 

数字支付的技术架构经过多年的发展,已从单体架构逐渐发展为微服务、单元化等分布式架构,但鲜有企业采用原生分布式数据库,在最核心的数据底座上缺少业务发展的强有力支撑。

 

早期数字支付的传统数据库架构大多采用单机数据库,因为其简单易用,且强 ACID(Atomic 原子性,Consistency 一致性,Isolation 隔离性,Durability 持久性),帮助支付企业快速积累了一定市场规模。

 

随着业务增长,单机数据库的容量、性能很容易达到上限,应用架构开始升级为分布式架构。与此同时,基于中间件的分库分表方案应运而生,这种方式短期内有效解决数据激增、高并发等问题,但本质还是单机数据库的横向组合,与之也带来一系列其他的问题,制约了企业在新一轮增长期的发展。

 

业务连续性难保障

 

保证业务连续性是数字支付的重中之重,主要包括高可用、高容灾。高可用需要数据库在机房断电、网络异常、磁盘静默等故障,甚至是光纤断掉等极端情况下,仍然能保证数据 0 丢失,业务正常运行;高容灾则是指在地震、火灾、洪水等本地数据库遇到灾难时,备灾数据库能快速承担起本地数据库任务的能力。

 

传统的单机数据库遇到故障后,业务可能长时间中断,甚至数据丢失;即使能做到高可用、高容灾,也依赖于操作系统、存储硬件、数据库等多组件的整合分级实现,与业务自身应用的配合度低,切换要求高、难度大,不足以保证数字支付企业的业务连续性。

 

频繁分库分表效率低下

 

数字支付企业的业务初期,数据量不大时,采用单机数据库架构往往就能很好地正常运行。但当业务发展到一定规模时,伴随数据量激增,要么选择不断增加单机数据库;要么分库分表,分库分表也就意味着要做技术改造,这对整体架构设计能力的要求甚高,稍微有设计不合理之处,都将可能使系统的整体性能、可用性大打折扣。

 

此外,分库分表也就意味着要在一定时间内停止业务,对运维人员来说则是大量的数据清理、拆库拆表的繁琐工作。大量的数据库实例,也将导致运维的复杂度直线上升,造成整体运维效率低下。

 

存储成本日益高昂

 

毋庸置疑,随着多年的发展和积累,导致数据量的激增,数字支付企业的数据库成本会越来越高。

 

● 一是监管要求的热数据存储周期要求,以及监管审查的全量数据存储要求;
● 二是业务增长导致不断增加的数据库的硬件成本;
● 三是分库分表的多实例的资源利用率低,造成计算资源浪费;
● 四是累积的海量数据存储导致存储成本的上升。

 

因此,数字支付企业的存储成本普遍高于其他对数据保存时间要求较低的企业。

 

高并发时稳定性差

 

随着移动互联网的到来,海量高并发场景的背后都需要数字支付企业做稳定支撑,如直播带货抢购时、超低折扣商品秒杀时需要同时调用第三方支付的接口,保证用户的交易、支付等行为正常;如通过技术手段将银行、第三方支付等多种支付整合于一体的聚合支付,每天都面临着大量高并发的场景。

 

传统数据库架构需要根据业务发展提前规划容量,不支持动态扩缩容,不具备突发流量的承载能力。面对短时间大量的支付、交易等 SQL 请求,如果每一条 SQL 都增加 1 毫秒的延迟,用户将会有延时等待的不佳体验,数据库也很有可能直接宕机。

 

大数据分析过程漫长

 

中国的数字支付无论在市场规模还是增长速度一直引领全球支付市场,也基于不断的业务创新,包括场景数字化运营转变。不论是第三方支付还是聚合支付,都有从面向 B 端商家进行大数据分析的场景,如商家查询近期交易的汇总数据、分润数据统计分析等;到面向 C 端的用户画像的精准营销场景,如支付收单与银行数据联动等。

 

由于传统架构通常将 OLTP 和 OLAP 分为两套数据库,当遇到需要大数据分析的场景时,往往需要将负责 OLTP 数据库的数据同步至 OLAP 数据库,再由 OLAP 数据库进行大数据分析,大多统计分析时效为 T+1,影响商业决策时效性,也制约了业务模式的创新和发展。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

数字支付亟需底层基础设施升级

 

数字支付正面对新一轮机遇与挑战,面对不断攀升的数据成本,亟需数据库最根基的底层基础设施升级。

 

从单机数据库到基于中间件的分库分表数据库,没有从根本上解决问题。随着数据爆发式增长,不仅稳定性无法有效保障,性能下降也直接带来了服务体验下降,同时数据库相关的硬件、存储等成本也会越来越高,但计算、运维等效率却并没有相应提升。部分支付企业引入原生分布式数据库,实现了数据底座的高可用、高扩展、高性能等架构升级。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

除了将价格高昂的单机数据库替换为成本更低的普通 PC 服务器,原生分布式数据库与传统数据库在底层有着本质的区别,能有效解决数字支付企业遇到的以上种种挑战。

 

第一,原生分布式数据库在设计之初,就是假定硬件是不可靠的,数据会被系统自动打散存储在不同的副本中,这些副本可以存储在不同的机柜、机房、地域,实现了城市级的无损容灾需求。多副本之间通过分布式一致性协议保证全局数据一致性,数据修改后其他副本保证成功提交,因此具备高容灾能力。

 

在高可用方面,原生分布式数据库也有其核心优势。如原生分布式数据库 OceanBase,基于分布式选举协议在故障发生时可进行自主选举,当少数派节点发生宕机时快速无损自动切换,达到 RTO=0,RTO<30 秒,达到国家标准定义的最高等级容灾标准;且内置多种强校验机制,能自动发现多副本数据不一致、网络数据错误、磁盘静默错误等,保证数据强一致。

 

第二,原生分布式数据库能够在普通 PC 服务器上实现无限水平扩展,实现计算、存储资源的线性扩展能力,数字支付企业无需再进行繁琐的人工扩容、复杂的分库分表建设,有效降低运维复杂度,提升运维效率。如原生分布式数据库 OceanBase 的一张表即可扩容至 PB 级、千亿条记录以上,数字支付企业可按需配置算力资源,灵活扩展、收缩资源。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

在无限水平扩展的基础上,原生分布式数据库解决了分库分表的全局一致性、跨库事务、复杂关联查询、负载均衡等问题,实现了超级数据库计算集群,如原生分布式数据库 OceanBase 实际案例中单个集群超 1000 节点,整个集群通过 MVCC、全局索引,保证全局一致性和高性能。

 

第三,从昂贵的单机数据库到普通 PC 服务器,硬件成本就已经大幅降低。此外,原生分布式数据库在存储空间、计算资源的利用率上也更上一层楼。如原生分布式数据库 OceanBase,因其完全自研存储引擎,能有效发挥基于数据变长-定长的存储压缩技术、基于数据编码的存储压缩技术、基于数据日志分离的低成本存储技术。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

与 MySQL 和 Oracle 数据库相比,同一业务的数据存储量,OceanBase 大约是后者的 1/4~1/3,能有效降低 70%~90% 的存储成本。

 

第四,分布式数据库的弹性伸缩能力,能够帮助数字支付企业平稳迎接高并发。如原生分布式数据库 OceanBase,基于线程加协程的技术,具有超高的连接数,单点连接数是其他数据库的 5~8 倍,集群的连接数可按照节点数线性增长。

 

此外,OceanBase 具备提前解行锁(ELR)能力,让业务在面对大促、秒杀等高并发场景,优化分布式事务响应能力,提升系统的整体吞吐能力。如同等规格下,MySQL 热点行更新 3000TPS,OceanBase 通过 ELR 可达到 3500~10000TPS。

 

第五,HTAP 是近年来数据库领域的新兴趋势,旨在打破原有 OLTP 和 OLAP 的壁垒,让事物处理和决策分析更高效。相较于传统数据库只能分别进行 OLTP 和 OLAP,分布式数据库天然具备将这二者相结合的能力,大幅缩短数字支付企业大数据分析的时长。

 

如原生分布式数据库 OceanBase,能将 OLTP 和 OLAP 部署在同一套数据库集群,通过数据整合避免信息孤岛,真正做到一份数据既能做事务处理又能实时分析,为数字支付企业提供更快、更准的数据分析。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

分布式升级后,降本提效效果显著

 

一、利楚商服:存储成本下降74%,分润统计时间缩短近1倍

 

利楚商服是聚合支付的领军企业之一,旗下拥有聚合支付中台“扫呗”、商户轻  SaaS “赋佳”、全域营销中台“有域” 3 大产品体系。其中,“扫呗”位居聚合支付行业规模前二。作为创新型互联网企业,利楚商服密切关注新兴技术发展趋势并积极投入实践,为稳定支撑未来业务的持续增长,选择进行分布式升级。

 

聚合支付企业的数据库每天都要支撑海量的交易场景、支付场景,日积月累的数据导致利楚商服的存储成本持续攀升。升级至分布式数据库 OceanBase 后,基于 LSM-Tree 的存储架构和自适应高级压缩技术,利楚商服某业务从 MySQL 迁移至 OceanBase 后,整体存储成本下降 74%。

 

利楚商服每天的订单量非常大,如面向代理商等场景,涉及到汇总清算和分润分析,所以在进行联机交易的同时也有不少实时统计分析的需求。以分润统计分析为例,应用 OceanBase 之前,分润统计通常需要 30~40 分钟才能分析完成,应用 OceanBase 之后,只需 15 分钟即可统计分析完毕,时间缩短近 1 倍,商家满意度也由此大幅提升。

 

同时部分 T+1 的统计分析依赖其他列存数据库,应用 OceanBase 后,依靠 HTAP 引擎,实现了准实时数仓分析的能力,同时也简化了架构的复杂度。

 

二、GCash:运维效率大幅提升,数据压缩比近90%

 

GCash 是菲律宾电信公司 Globe Telecom 旗下的小额支付系统,截止 2022 年 Q1,已经拥有超 6000 万的注册用户,超 500 万的入驻商家,超 17 万家存取款站点,目前已经成为菲律宾国内第一大电子钱包。随着业务的爆发式增长,GCash 的 MySQL 集群已达存储上限,需要频繁进行人工拆分清理数据;大量的数据库实例,让 DBA 陷入低效循环等一系列问题出现。于是,GCash 决定升级至全新的分布式数据库架构。

 

通过 OceanBase 提供的迁移服务,GCash 在不停机的情况下实施全站业务向分布式数据库的完整迁移,并采用三可用区高可用架构,保障任意可用区级别故障业务不中断。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

GCash 原有上百个 MySQL 实例出现问题时都需要单独处理,运维成本高昂,借助 OceanBase 的多租户能力,资源池化后仅用 10 余套集群全部容纳。此外,OceanBase 提供运维管理工具(OCP),包括数据库组件及相关资源的全生命周期管理、监控告警,性能诊断、故障恢复,备份恢复等, 大幅提升运维效率及 DBA 幸福感。

 

GCash 原有单数据库的数据近 5T,迁移至 OceanBase 后压缩至不到 500G,数据压缩比近 90%,增量数据迁移也有基本接近的数据压缩比,数据存储空间因此显著提升。同时,这也意味着很长一段时间运维同学不需要进行数据归档、数据清洗,可以将精力放在更重要的事情上。

解决方案架构师周贵卿:数字支付降本提效,从分布式升级开始-鸿蒙开发者社区

数字支付将会驱动数字化产业模式升级,通过对多元场景的覆盖,促进产业互联网场景协同性提高,深入商户企业的供应链、金融链等,将商户企业的资金流、信息流和物流打通,驱动商户企业业务模式的变革升级。

 

 

面对新一轮的机遇与挑战,数字支付不仅在需要商业模式上与时俱进,也需要在基础设施和技术架构上更新迭代,淘汰过时或中间台的技术,引入多元化的包括人工智能、原生分布式等新技术,降低运维成本,提高生产效益,充分夯实基础设施能力,不断巩固深化数字支付的领先优势。

 

文章转载自公众号:OceanBase

分类
标签
已于2022-10-9 10:42:33修改
收藏
回复
举报
回复
    相关推荐