欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
国泰产险自 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%。
运维创新：1.X版本基于系统视图自建数据库平台
国泰产险接触 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 进行全链路的跟踪、优化，直到它上线。
仅需半小时，1.x版本平滑迁移至2.x版本
数据库迁移是很多行业尤其是金融行业感兴趣的话题，我们花费了将近小半年的时间进行迁移工作，其中大部分时间都在进行方案的论证与整理，最终实际迁移花费三个月的时间，主要分为三个阶段。
▋ 第一阶段，前置工作。
首先进行 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 治理、数据架构治理、数据安全等工作，更多地开发配套的提效降费工具，而不是将时间浪费在重复而又繁杂的基础运维工作上。我今天的分享就到这里，希望能对大家有所帮助，谢谢大家！
欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/