2020年12月21日第十一届中国数据库技术大会（DTCC 2020）于北京如期举行，网商银行架构师，存储底盘负责人杨祥合先生，在 “OceanBase 企业级分布式数据库实践专场” 分享了《网商银行分布式数据库应用实践》的演讲，以下为演讲实录：
随着数据量爆发，业务日益复杂，现今 IT 环境中面对的场景复杂度和故障率也越来越高，甚至在国内出现了多起数据安全“黑天鹅”事件。以下分享将以网商银行的架构历史演进和对数据库的应用徐徐展开，以期给诸位带来启发。
网商银行架构史，斩获人行科技奖
网商银行是一家以普惠金融为使命的互联网银行，业务主要面向三农和小微企业。技术底盘架构在蚂蚁金融云和 OceanBase 上。作为 OceanBase 服务的第一家银行，网商银行对高并发、扩展性、数据一致性的需求一开始就存在。而在数据库选型的过程中，首先考虑的是高可用和高弹性，其次是低成本和自研。
我们先从存储架构和数据库版本两个方面来谈谈网商银行的发展史。
存储架构方面，从最初的两地三中心，到后来从 OceanBase 0.5版本升级到 OceanBase 1.0版本，实现了三地五中心的单元化。“三地五中心”，即在三座城市部署五个中心，一旦其中一到两个中心发生故障，甚至一个城市出现问题，业务都能够在 30 秒内自动恢复。
2019年，将 OceanBase 在高可用、扩展性用于混合云架构，在做多云架构时，面对不同业务目标的多朵云，可以一键将数据扩展到另一朵云上。2020年，开始落地云原生架构，配合全栈加密，从用户数据进入到服务的全过程，整个生命周期数据传输加密，落在磁盘上的数据都是密文。
在数据库方面，网商银行基于分库分表的数据库架构，从设计之初就设定单元化的目标。使用分库分表多集群，解决了库设计上的单点问题，数据库的升级、备份等在不同集群之间错峰进行，避免影响全局。
网商银行架构师，存储底盘负责人杨祥合
网商银行到底有怎样的技术实力？这在网商银行成立之初，就在行业中引起了热议。当时我们做了一个勇敢的决定，在生产系统中来一次断网演练。当完成了相关的报备后，我们就正式开始了这次断网演练，直接把生产系统中其中一个机房的流量全部断掉。让行业震惊的是，网商银行用了不到 1 分钟便实现了快速恢复，这背后其实充分体现的就是 OceanBase 的高可用、快速恢复的自治能力。
整个三地五中心异地多活的项目落地之后，我们把项目上报到人行，该项目最终获得了人行科技发展二等奖。实际的生产环境中，网商银行利用人行的窗口，定期做断网演练，这是发现自身问题的重要举措。
网商银行架构一览，从分库分表到批场景
OceanBase 不只是数据库，云原生架构之后，可实现链路加密，在 ServiceMesh 做加密，数据库做解密。目前，网商银行数据库集群规模 100 多套，数据量达到 PB 级。在线库和历史库架构中，历史库访问量较低。云原生微服务起来后，数据库、业务系统不断被拆分，需要下游的核心能力，包括建立一些基于 AI 能力的加持。
在分库分表方面，网商银行采用分区架构，在生产实践当中，有热点库、热点行、热点表等挑战，这些热点利用分区的能力，每一个分区独立到一台机器。
银行业务中的海量数据的处理方面，数据库设计是每批次并发处理 13~130 亿。具体逻辑为，每个批次查询 5000-100 万条，单表拆分片数 13 片到 2600 片，按照这个逻辑，网商银行使用了 999 分片，最大每批次可处理 130 亿账户。
批场景中，利用分库分表的基础上，使用表分区提高并发跑批能力。如银行工资代发、团体险等需使用表分区的能力，如企业人员导入，原本一个单表导入做成多个分区，把不同的数据打散不同的分区上提升性能。
业界有厂商宣称，库高可用是人为切主对业务无影响。我们认为应增加主库宕机 1 分钟内自动恢复，且数据保持一致的要求。网商银行数据库的标准是在此基础上，两个机房同时故障，也能够达到 RPO=0、RTO<1分钟。
金融业选型建议，从数据库到历史库
数据库选型，性能隐私双保险
一是主备模式不适合金融高并发场景。主库出问题需层层上报，强拉备库为主会丢数据。如果采用强同步模式，经测试性能会降 10 倍，这种性能下降是无法接受的。
据中国信通院发布云数据库标准选型建议，一致性协议应该成为金融数据库标配。高可用架构=快速恢复+最小影响面。快速恢复依赖一致性协议的加持。最小影响面分横纵两个纬度，横向拆分成多个集群、做分库分表和表内分片，纵向拆分成多个机房，让不同范围的用户编号进入到不同的机房，这样单机房/单个分库的故障影响面影响降到最小。
国家越来越重视用户隐私，用户安全的主题下，将全行数据加密提上日程。数据从金融网关进入网商那一刻起就变成密文，密文传输、密文存储；银行的备份和传统企业不一样，既要有同程备份又要有超远程的备份，中间有网络传输加密、透明加密，传输到超远程机房，再做一层存储透明加密。
历史库选型，让数据远离丢失风险
冷热分离为什么会带来数据丢失的风险？因为，在线数据库通过读取校验整个数据，CRC 验证 block 完整性，冷数据如果发生故障，没有读请求来验证数据块是否正常，从而难以发现坏块，极端情况甚至会导致多个副本永久丢失。
OceanBase 数据库有一个后台的进程，不间断扫描数据进行校验，以此发现问题，让数据库的备份真正的有效。如果几个月后才发现问题，为时晚矣，因为数据备份保存不了那么久。根据我们的历史库选型原则，一定要有后台校验，让数据远离丢失风险；此外，还要关注加密，保护用户隐私。
高性能探索实践，创新迭代扛大促
网商银行和 OceanBase 一路创新前行，不断探索向上。
线上性能摸底—链路压测
网商银行用的全链路压测方法进行容量摸底。通过压测代码上传到平台，将产出的流量打入金融网关，网关调用一层层业务服务。直接在生产系统进行压测，标通过标记区分是压测的业务，中间件把压测流量打到影子库中去；整体上，流量穿越所有的微服务链路，通过全链路压测进行容量摸底，确保链路上无单点流量瓶颈。
每年大促活动前，通过全链路压测进行容量摸底。
混合云弹性架构—大促弹出(20%)
假如网商银行一朵云上机器资源已用尽，能否并让流量跑到另一朵云上？通过混合云的弹性架构，数据库的一键扩展，应用上做单元化适配。今年大促最终弹出 20% 的流量到新云上，充分验证了 OceanBase 的快速的扩展能力。
OceanBase 致力于打造金融行业银行业的数据库，同时最令人骄傲的一点是 OceanBase 是中国人自己的数据库，希望行业同仁的交流能带来更多创新的尝试，带动国产数据库走向更广阔的发展。
