查看原文
其他

舒明:稳定支撑日高峰亿级保单交易,国泰产险的运维创新实践

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

国泰产险自 2018 年以来业务开始高速增长,现平峰日均保单量达数千万级,高峰日均保单量达亿级。面对财产保险场景化、碎片化特征,国泰产险最终选择分布式数据库 OceanBase 并已平稳运行近 5 年。在此期间,国泰产险积极探索,在运维创新与数据库迁移等方面沉淀了大量可借鉴的行业经验。3 月 25 日,2023 OceanBase 开发者大会在京召开,国泰产险资深数据库专家舒明分享了《国泰产险的 OceanBase 上云实践》的主题演讲,以下为演讲实录。


国泰产险于 2008 年在上海成立,迄今已在东南沿海和中西部地区 9 个省市设立25家分支机构。过去的 2022 年,全年保单数量达 57.8 亿单,保费规模达 53.8 亿元,累计服务客户达 3 亿人,  并获得 2021 年中国金鼎奖“年度卓越财产保险公司”、2022 年“金理财”奖年度企业社会责任奖。

国泰产险互联网产品有两个比较明显的特点:

一是场景化。所谓场景化,就是在生活和工作中遇到的一些场景。例如以电商场景为代表的退货运费险,大家在淘宝、天猫等平台购买商品时商家赠送的退货运费险,很有可能就是我们国泰产险的产品。这种产品特点体现在“小单”和“天量”,“小单”是指保费收入和保额较少,但相对其他险种它的“天量”即数量非常大。像过去几年的“双 11”期间,国泰产险的退货运费险日保单量基本都在 1 亿以上。

二是碎片化。国泰产险的产品覆盖生活场景中的很多碎片化需求,这类产品特点通常不能用一些通用的模型来解释,比较偏定制化、个性化。例如大家给自己买的健康险、给宝宝买的“萌宝保”、给父母买的“孝顺保”等。国泰产险针对这些碎片化场景打造了 200+ 创新产品,驱动业务高质量发展。



基于国泰产险产品场景化、碎片化的特点,我们在实际生产过程中遇到了一些业务和技术上的挑战。

 
▋ 挑战一:要求 7×24 小时全天候高可用

升级为互联网科技保险公司后,我们的系统要求 7×24 小时全天候提供服务,因为即使是在深夜也会有用户在淘宝、天猫等线上平台下单,进而同步购买我们的各种产险产品,假设停止服务五分钟,都会给我们带来直接的经济损失。而作为底层服务的数据库需要保持更高的可用性。

▋ 挑战二:业务快速增长,分库分表逻辑复杂

近年来,国泰产险在互联网平台上的保单数快速增长,数据库的单表数据量急剧膨胀。这种情况下,我们曾经考虑分库分表加历史数据归档,还对一些分库分表方案进行了选型,如通过第三方中间件,如直接自己写框架在程序层进行逻辑控制。但无论哪种方案,整体逻辑都会比较复杂且后续维护不方便。

▋ 挑战三:并发高,性能要求苛刻

每逢节假日、大促日,尤其是“双 11”期间,高并发的特征非常明显。像在大促日 24 点时,很多用户都守在 APP 前准备集中下单,短期内成千上万甚至上亿的保单量,瞬时流量非常大,对我们的应用来说压力非常大。再加上保险业务的一个请求要经过承保前置、承保、合约、风控等链路,并且对链路上每个节点的运行流畅度要求都非常高。所以我们对数据库性能的要求可以说是非常苛刻的。



为了提升互联网化交付速度、敏捷响应大规模业务需求,国泰产险决心全力打造保险中台,而保险中台的底层需要一款经历过海量数据考验的数据库做支撑。

一方面是基于打造保险中台的大背景,一方面是基于以上三点业务和技术上日益凸显的挑战,我们开始进行大量的数据库调研工作,发现 OceanBase 有三个特点非常吸引我们,也是我们最终选择握手 OceanBase 的主要原因。

 
特点一:高度兼容 MySQL 和 Oracle,无需分库分表。

OceanBase 高度兼容 MySQL 和 Oracle,对国泰产险现有的 SQL 代码无需额外改动,对开发人员非常友好。针对数据量膨胀的问题,我们之前需要分库分表,现在只需通过表分区就能解决,无需额外进行繁杂的分库分表工作。

特点二:应用透明的水平扩展。

高并发下全链路压测 OceanBase 的性能非常优秀,针对节假日、大促日等的高并发场景下,能进行快速的扩容、快速的缩容,并且对应用透明无感。

特点三:极致的高可用。

两地三中心、三地五中心等多机房的容灾能力,是我们非常关注的。有多机房容灾的情况下,才能保证数据不论是发生机房级还是服务器级故障时都能快速恢复、才能保证在高并发写入情况下数据零丢失。

得益于稳定可靠的数据底座,我们能更好更快地通过技术创新赋能业务增长。从2018 年开始选型到正式上线,如今,OceanBase 已经在国泰产险平稳运行近 5 年,并得到以下主要成果:

  • 高并发。国泰产险的日均保单量级基本在数千万,在“双 11”期间有超高流量涌入,日均保单量超一亿。OceanBase 完美支撑了我们一次又一次“双 11” 日均保单量过亿级的业务请求,巅峰达 8.5 万次 TPS。

  • 稳定性。稳定性是金融行业选型数据库最看重的点之一,运行 OceanBase 多年来国泰产险整体实现 RTO<30s, RPO=0 的目标。即使硬件偶尔出现故障,OceanBase 的预警功能也能提醒我们及时介入处理,我们就可以把故障节点上的Leader 租户切走,快速替换再切回来。

  • 多租户。我们将业务通过保障等级(高保、中保、低保)划分为不同的租户,租户之间处于硬件资源隔离、数据资源隔离的状态。如大促来临,国泰产险可以动态调整,优先把资源调给链路前端部门应对高并发流量。即使当前端正在高并发写入情况下,动态资源调整对应用也无感透明。

  • 降本增效。OceanBase 在降本增效这块表现地非常好,国泰产险的数据库综合成本降低 2/3,数据库性能整体提升 20%。



国泰产险接触 OceanBase 较早,我们最先使用的是 1.X 版本,那时的运维体验并不像现在好。于是我们基于 OceanBase 的系统视图自建了一个数据库平台,主要包含三个模块:

 
模块一,监控。监控非常重要,因为我们必须要掌握数据库当前的状态,包括各租户的资源状态。国泰产险的表的数据非常大,我们精细统计到了所有表空间具体的值,将数据落库进行趋势展示,同时实时展示 CPU、内存等资源,方便运维人员和开发人员迅速分析。

模块二,报警。当数据库租户的资源发生报警时,运维人员需要及时地了解并介入。我们基于视图做了资源报警,如 CPU 等资源报警;慢 SQL 报警,如报警当前执行的慢 SQL、超过不能接受范围的慢 SQL,反映数据库的状态;还有应用层的异常表监控,保证整个系统的稳定运行。此外,我们还接入了钉钉进行及时的报警提醒。

模块三,慢 SQL 治理平台。慢 SQL 的危害非常大,甚至会拖垮租户和集群造成大规模的应用超时。根据慢 SQL 产生的特点,我们将整个过程分为事前、事中、事后三个阶段。

  • 事前 Review SQL。事前我们会进行 DBA 的人工审核和程序卡点,双 Review 统一进行,争取在慢 SQL 上线之前就消灭它。

  • 事中抓取慢 SQL 落库。慢 SQL 发生时,我们首先会通过前面提到的报警模块先报警出来,然后把慢 SQL 通过抓取落到我们自建的日志库。

  • 事后形成工单流程跟踪优化。事后我们会对慢 SQL 进行整改,把聚合后的慢 SQL 进行清洗、分析、统计,最终形成一个工单流,派发给对应业务的开发人员。由开发人员和 DBA 双重角色维护,因为有时慢 SQL 不仅要从 SQL 层优化,还可能要从系统层优化。

通过事前、事中、事后这三个阶段,国泰产险自建的慢 SQL 治理平台能对慢 SQL 进行全链路的跟踪、优化,直到它上线。



数据库迁移是很多行业尤其是金融行业感兴趣的话题,我们花费了将近小半年的时间进行迁移工作,其中大部分时间都在进行方案的论证与整理,最终实际迁移花费三个月的时间,主要分为三个阶段。


 
▋ 第一阶段,前置工作。

首先进行 OMS(OceanBase Migration Service,OceanBase 数据迁移工具)搭建。其次,进行账号权限梳理,有些账号已经没有使用或者账号异常,我们要趁这个机会进行统一梳理。然后环境初始化,跨域跨账号需要更多网络打通,以及各种数据库环境创建。最后,脏数据排查,从低版本到高版本有些数据可能对数据库来说是脏数据,我们需要清理掉,例如,某些 datatime 值不兼容的问题,就可以提前更新并处理掉。

▋ 第二阶段,迁移和灰度。

迁移过程本身并不漫长,但国泰产险为了验证整个方案的稳定性和成熟度,将时间拉长至 2~3 个月,通过时间维度来验证方案的可行性。主要包含四个步骤:

步骤一,全量、增量迁移。我们会将所有库表进行全量和增量的数据迁移,可以在 OMS 里进行库表任务的任务配置。

步骤二,数据一致性校验。这是迁移的重中之重,我们非常关心迁移前后的数据是否一致。针对一致性校验,OceanBase 提供数据校验的功能,如果发现数据不一致会显示出来。作为金融行业,国泰产险对数据一致性的要求非常高,所以我们还自建了一个校验数据一致性的小工具,监控这些表的同步情况,双保底方案验证迁移前后的数据一致性,确保源端和目的端的数据一致性。

步骤三,差异数据处理。如果真正在迁移过程中发现数据不一致怎么处理?针对差异数据,根据实际情况具体问题具体分析,判断是选择重新同步这张表,还是在目标端进行相关操作。例如,唯一索引的问题,若在早期版本中建了唯一索引,虽然有重复数据会建失败,但还是建了,但在迁移过程中先建唯一索引的话,重复数据写入就会报错。

步骤四,应用灰度切流。最后是部分应用的切流,我们将应用的查询请求打到新的OceanBase 集群,把 OceanBase 当成一个热备,通过只读场景去验证新集群的整个功能是否有问题。

▋ 第三阶段,切换和验证。

做了这么多前置工作,第三阶段相当于最后的临门一脚。在整个切换过程中非常顺利、顺滑。那天晚上我们 8 点开始,8 点 30 基本就结束,大概持续不到半个小时即切换成功,这里分享一下我们当时做的具体工作。

工作一,应用限流。我们对应用做了一个系统的开关,将应用进行限流后,对底层数据库的请求相对比较少,压力也就比较小。工作二,OceanBase 源端禁写。我们通过修改参数把 OceanBase 源端进行禁写,尽可能保证源端和目的端的数据一致性。工作三,统一切换配置。我们写了一个脚本,可以批量修改数据源的配置,使其连接到新的数据源。工作四,应用验证恢复。我们把所有应用启起来进行功能验证,恢复流量后进行最终验证。

整个过程花了不到半个小时,这得益于我们前面进行的大量的反复演练,不用大家蹲守到半夜发布,这对运维人员来说是非常好的体验。



上云 OceanBase 后,DBA 能明显地感受到运维效率提升。


一是监控报警,基础运维工作可以配置报警规则,关心哪些参数可以及时报警出来;二是可视化运维操作,我们可以将切可用区、主动发起备份等操作直接在白屏进行,相对稳定安全,不用黑屏做这件事。


三是灾备系统完善,我们之前需要通过写脚本进行备份和恢复,现在通过页面化的功能来配置即可实现;四是支持数据传输,不仅支持集群间的数据传输,还支持通过 OMS 传输至国泰产险的数仓进行离线/在线分析等。


▋ 全生命周期管理数据安全


金融行业对数据安全非常重视,随着数据成为生产要素,各行各业对数据安全的重视程度基本上都是只增不减。我们把数据从生产到销毁浓缩成三个阶段:传输、存储、使用。


 

在传输层通过 SSL 链路加密且进行严格的访问白名单控制。在存储层进行 TDE 加密,对一些敏感数据进行加密存储。在使用层针对人工查询访问数据库的请求,我们统一收口到数据管理平台,在里面进行敏感数据保护的设置,做权限控制和操作等级的设置等。这样就在全生命周期的各个环节加固数据安全。


▋ 玩转云上 OceanBase 精细化运维


上云之后,很多基础运维工作确实被替代了,这个相信大家也深知,我们也没什么好避讳的。但不代表 DBA 没有事情可做了,我个人应对云数据库时代的方案是——走近业务,贴近业务实现 DBA 的价值。



首先,在架构治理上。有些业务创建上线的时候,不能很好地识别业务的保障等级,业务推进过程中才能识别,因此需要进行高/低保租户隔离的动作,避免低保障的应用影响高保障的应用。

当一个新业务上线时,开发 leader 一般无法准确预估该业务未来会有多大的流量,分配资源也是按照当前该业务符合的资源,需要 DBA 后期运营。那国泰产险是怎么做的?我们把资源使用情况通过 API 拉到近数月、一个月、一周的数据,通过数据分析该资源的使用率。如果这个月的使用率不到 20%,其已分配资源就该被动态调整。

其次,降本增效上。原来,国泰产险的表压缩比不是很高,我们持续在更改一些表的压缩格式,转成一个更低的压缩比。此外,业务每天的全链路很多,每个节点每天的数据量都会有一两千万的增长,对于整个 OceanBase 的存储压力非常大,于是我们自建了一个数据库清理归档平台,把这些大表做了一个数据大盘,每张表的数据量、存储情况以及最近的增长情况一目了然。根据数据分析推动开发进行配置删除策略,这些策略集成在平台中,可以按产品、时间等多维度进行归档。

对于金融行业,备份必须要做,但异地备份的性价比不是很高,除非真正发生大故障,否则很少去做。大家可以考虑把异地备份转归档存储,同时还可以降低使用成本。

最后,SQL 治理上。一是可疑 SQL 展示与限流,如果某个 SQL 确实比较慢或性能不太好,我们可以针对它进行限流,直接在页面上配置即可;二是全量 SQL 审计,当我们线上出现不明 SQL,可以在页面上开启审计开关,找到 SQL 是从哪里来的?是否是内部执行等;三是索引建议,OceanBase 可以提供索引建议供 DBA 参考,进行相应的 SQL 优化;四是慢 SQL 工单流,基于上述提到的国泰产险自建的平台,方便我们与开发同学一起优化慢 SQL。

总之,真正迁移到云上的 OceanBase 后,DBA 对于数据库运维的整体效率提升,感受非常明显。我们可以更多地聚焦 SQL 治理、数据架构治理、数据安全等工作,更多地开发配套的提效降费工具,而不是将时间浪费在重复而又繁杂的基础运维工作上。我今天的分享就到这里,希望能对大家有所帮助,谢谢大家!

*最后,本次开发者大会可对外分享的 PPT 和演讲视频现已上线官网,感兴趣的小伙伴可以点击文末“阅读原文”进入查看。

往期推荐

▼ 点击下方「阅读原文」,查看完整视频回放!

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

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