案例实战_运用分布式自主可控数据库推动保险应用系统架构演进.docx

《案例实战_运用分布式自主可控数据库推动保险应用系统架构演进.docx》由会员分享，可在线阅读，更多相关《案例实战_运用分布式自主可控数据库推动保险应用系统架构演进.docx（9页珍藏版）》请在第一文库网上搜索。

1、案例实战.运用分布式自主可控数据库推动保险应用系统架构演进案例实战运用分布式自主可控数据库推动保险应用系统架构演进1一、引言数据库选型与测试分析21 .SerVer进程宕机（1eader副本）场景32 .数据盘的数据丢失场景4数据库应用架构设计及配置51 .数据库应用架构设计52 .基础环境配置.S四、架构演进中遇到的问题与对策8五、结束语摘要因为各种原因，保险公司的基础设施多采用国外设备与软件，如何保障基础设施安全和自主可控的需要，也要求保险公司必须探索和实践国产化软硬体体系的迭代升级；而基础软件与应用软件的升级替换由于场景复杂、需求差异化和涉及面广，显得尤为困难。一、引言随着各种数字化技术

2、的应用，保险客户对保险服务的线上化需求越来越多；为应对不断增加的线上化服务需求，并通过业务创新和产品迭代提升公司的竞争力，公司需要持续推进数字化转型，推动数字化与业务、服务的全面融合，就需要敏捷高效的科技基础架构支撑；而传统的基础架构受限于成本、建设周期及扩展性等难题，难以有效满足保险公司创新的需要。同时，因为各种原因，保险公司的基础设施多采用国外设备与软件，如何保障基础设施安全和自主可控的需要，也要求保险公司必须探索和实践国产化软硬体体系的迭代升级；而基础软件与应用软件的升级替换由于场景复杂、需求差异化和涉及面广，显得尤为困难。二、数据库选型与测试分析公司数字化转型过程中，需要持续提升线上化

3、水平，这势必大幅增加数据交易量和并发量；同时互联网类系统和功能的大范围应用使得公司的基础设施，特别是数据库面临不脉冲式的使用压力，现有数据库难以支撑，需要对未来数据库进行选型和迭代升级。因公司大数据体系架构经过多年的建设，已基本实现自主可控的升级迭代；基础数据库体系主要针对公司管理类、业务交易类等应用系统提供服务；通过对生态体系、行业案例、技术支持力量、现有数据库迁移匹配及应用系统体系架构匹配等情况进行综合分析，选定某型分布式数据库作为未来数据库体系演进的主要技术路线，并对该分布式数据库进行了一系列的测试。在业务交易类系统中使用分布式数据库，需着重保证数据库体系的高可用性；为测试该分布式数据库

4、的高可用服务能力，在搭建PoC环境时，分布式数据库集群为双机房主备集群架构。其中，主集群采用为3副本模式进行部署，每个副本部署2台SerVer,即2-2-2架构；备集群为3副本模式进行部署，每个副本1台server,即ITT架构。测试过程中，设计了SerVer进程宕机（Ieader副本）、SerVer进程宕机（fo11ower）.数据库反向代理进程退出、数据盘的数据丢失及集群单Zone整体宕机等五个场景，基本达到预期要求。1.SerVer进程宕机（Ieader副本）场景表1：SerVer进程宕机测试用例测试目的SerVer宕机，集群正常工作，访问该节点上的副本的交易恢复时间RT（K30秒预置条

5、件数据库集群运行正常测试步骤持续运行sysbench脚本登陆任意节点，将Server进程杀掉检查SySbenCh压测程序流量恢复时间预期结果少数成员故障的情况下，受影响的业务租户在秒级恢复（RTOMISCConfigSupportSmmu设置为“Disab1e”；关闭预取：AdvancedMISCConfigCPUPrefetchingConfiguration设置为Disab1e”；关闭NUMA：AdvancedMemoryConfigNUMA设置为“Disab1e”；关闭省电模式：AdvancedPerformanceConfigPowerPo1icy设置为“Disab1e”。2） BIO

6、S需要开启项：启动顺序1：HDDNetworkUSB；启动顺序2：HDD启动项中，第一块盘作为第一启动项o磁盘划分配置为：查看/sys/b1ock/*/queue/hw_sector_size,如果不是512,需要联系服务器厂商更新磁盘驱动，修改SeCtorSiZe为512。以磁盘配置是480G2+3.84TSATASSD8、内存配置是512G为例：1) 2块480G系统盘做RA1D1,用来安装操作系统，分50G挂载给根目录，分350G挂载给/home；2) 2块盘做RAID1,划分2.IT挂载给/data/1og1；另外6块盘做RAID5,全部挂载给/data/1。其中，var和/opt目录

7、不要单独挂载分区。四、架构演进中遇到的问题与对策架构演进是个体系工程，涉及到方方面面，需要不断优化、迭代升级。在引入自主可控的分布式数据库过程中，对基础架构团队、研发团队和运维团队都有着不小的挑战，出现了诸多问题，各团队也在问题的分析和解决过程中，不断成长，为后续应用系统的升级和迭代积累了宝贵的经验，形成了较为完善的迁移和使用规范。主要问题： 各技术团队的技术存储不足，对分布式数据库的最佳实践了解不够,评估与实施周期被拉长，上线生产后遇到了较多问题； 生产环境部署采用分布式存储，各节点为存算一体化管理，部署后进行验证时发现IO读写速度达不到预期，经联系硬件厂商协助排查，进行必要参数调整和优化，

8、问题得以解决； 分布式数据库的备份管理、备份策略、恢复性测试及容灾模式等技术实现、管理操作和传统数据库有较大差异，和现有管理制度和规范有一定的冲突，需要更新完善； 公司数据中台现有的数据同步技术不支持分布式数据库的同步，需要部署和调试新的同步插件； 并遇到日常监控、运维管理及性能优化等一系列问题。应对策略： 成立数据库体系迭代推进小组，包括系统架构、基础软硬件、研发、运维和安全等各条线人员； 联系分布式数据库的技术支持，针对硬件基础团队、研发团队和运维团队组织技术培训，并与行业已实施的技术团队展开交流； 加强基础设施、应用系统等多维度测试，及时发现问题并设计对应的解决方案； 按照从外围到核心，从管理类系统到交易类系统，由易到难，逐步进行数据库体系的迭代更新，取得实践经验后，再加快推广； 及时总结经验得失，对实施方窠进行优化改进，持续演进，不断完善。五、结束语通过运用自主可控的数据库进行应用系统架构演进的尝试，可以基本满足业务创新和自主可控的相关耍求，但实施过程中也遇到了各种难题，距离全面推广尚有很长的道路要走。前一阶段迭代升级中，为降低实施难度，选择了外围管理类和简单业务交易类系统作为试