构建7×24可持续运营的新核心系统

近年来，大家一直都在探讨保险科技的应用，用技术改进保险系统的效率。以云计算服务、大数据、互联网IT技术、AI等科技创新技术应用为引擎内核，实现保险业新模式、产品与服务创新。保险科技越来越成为保险公司技术革新的着力点，从实际工作来看，支撑这些科技创新应用真正形成生产力，保险公司的核心系统架构必须转型。

阳光保险集团信息技术服务中心总经理 石运福

新形势下核心系统面临的新业务要求

　　互联网电商、移动支付以及社交媒体等APP的融合发展，不仅改变了人民的生活，也改变了保险的生态，也使得传统的保险核心系统面临新的考验。

　　1.面临突发流量的考验。社交媒体以及各类电商平台的运营，积累了大量原来线下无法采集的数据，这些数据使得保险公司的产品可以低成本、快速连接会员对接人的需求，为精准营销提供了无限可能。一旦产品戳中用户需求痛点，极易实现单一产品的突破，这种突破必然引起保险核心系统流量的突发。

　　2.面临7×24小时不间断运营的考验。互联网大大提升了客户的体验期望，近期Fintech理念的兴起不仅给了保险公司新的发展机会，也在一定程度上进一步提升了客户对保险公司的期望。如何更快、更好地处理客户的各类需求已成为基本需求，多渠道、全天候的服务要求也已成为保险公司的标配，这就需要核心系统7×24小时不间断运营。

　　3.面临更快、更好的服务压力。许多保险标天然具备流动性，如果再叠加上即时生效要求，必然对核心系统提出了更高要求，特别是互联网场景化的保险，对时效及稳定性具有极为苛刻的需求。谁能处理得更快，谁就会带来更好的体验，谁就会获得口碑。

　　综上所述，平稳应对突发流量处理且能够提供快速稳定的7×24小时运营服务是目前保险公司在新形势下面临的实际需求，也是核心系统架构转型的着力点。

保险核心系统的架构着力点

　　传统的保险业务处理，不会面临流量突发的情况，其流量冗余可以按预期进行管理，对时效性具有一定的容忍度。在面临数据准确性和一致性的严格要求之下，其设计主要依靠数据库来保证，涉及数据变化的业务处理，会尽可能地放在一个事务里，由数据库来保证数据的准确性和完整性。这种设计带来以下问题。

　　1.业务能力依赖数据库处理能力，扩展周期长。业务处理能力受限于数据库的处理能力，在流量突发的情况下，数据库的能力冗余是关键，一旦冗余能力不足，只能依靠数据库的纵向升级来处理。这种更换周期短则数月，长则数年，处理时效不能满足业务扩展要求，而且单一硬件的处理能力受限。

　　2.有价单证的业务号码连续性限制了并发能力。保险单号码受业务管理的要求，不仅有唯一性要求，而且还要满足连续性要求，需要根据业务归属机构和使用时间产生单调递增的序列号。这主要依靠数据库的锁机制来保证，当出现高并发时，就会产生很多数据库行级锁，单号生成一旦和业务交易绑定在一个事务里，极易引起业务系统的不稳定。

　　这种依赖数据库的设计对于流量稳定在一个波动范围的情况下，硬件的处理能力可以匹配这个波动，不会出现大的稳定性问题。一旦面临流量突发，其局限性就会大大暴露出来，系统很难实现7×24小时不间断地稳定快速运营目标。

　　因此，核心系统架构在新的发展形势下，必须破除对数据库的依赖。通过解决对数据库事务的依赖和数据库处理能力的依赖，才有可能实现在流量突发情况下提供7×24小时的快速稳定运行能力保证。

数据架构转型

　　摆脱对数据库的强依赖，必须依据保险业务的业务特性对数据架构进行重新构建。数据库数据覆盖范围越广，所涉及的业务过程越多，事务就有可能越大，单一事务占用资源就越大，应对突发能力就越弱。解决数据库的依赖问题，就要从解决单一数据库过大问题开始（如图1所示）。

图1 大数据库和单体应用拆分

　　1.长期数据和短期数据分离。场景类的保险需求，容易形成突发，但此类保险产品，大多是短频交易，大部分的产品周期数据产生在外部，内部的处理要求相对简单，因此适合与长期保险数据进行分离。

　　2.过程数据和结果数据进行分离。保单数据一般会经过询价、报价、核保、缴费、出单、打单等众多环节。其中间交互过程产生诸多数据，这类数据具备很强的“热数据”特性，一般是在一个特定的时间范围之内，超过这个范围，其数据活性就大大减少，甚至基本不用。比如核保过程的流程类数据，提交、核保、打回等工作流数据，只在待核保期间具备活性，一旦拒保或者承保，这类数据就基本上失去活性。这类数据可以和保单类数据进行分离。

　　3.强一致性数据按业务特性进行串行化分离，降低事务复杂度。业务连续类单号依靠数据库的锁机制来保证，这类数据是并发处理的敌人，是处理突发流量的瓶颈。这类数据可以考虑和其他交易类数据拆离，形成单一的数据服务，从而提高单个号码生成速度，减少资源需求，提高其并发特性。

　　从生命周期来看，投保数据和保单数据具备相似性，其差距主要在状态数据，因此可以考虑将投保数据和保单数据进行分离。投保数据可能会进行频繁的数据交互，而保单数据大多提供读取服务，而且保单库即使不工作，理论上可以从投保单库重新生成，分离之后，更容易从各自业务特点实现7×24小时的设计。

　　4.根据读写特性分离数据。像配置类数据、代理协议类数据以及内部管理类数据，数据具备写少读多特性，主要提供读，其写入功能暂时失效对业务影响不大，因此适合将此类数据进行分离。分离之后，最大的好处是可以最小的成本实现双活，以保证7×24小时运营。

　　5.外部数据和内部数据分离。保险业务一般都会使用外部数据，这类数据往往需要第三方来维护，这类数据适合单独剥离出来，以避免对主要业务的影响。

应用架构转型

　　根据新的数据架构设计，单一大型数据库就会变成分类存放的数个小型数据库，此时应用架构就可以按数据库进行拆分，并实施应用服务化拆分，把紧耦合业务服务按照服务化思维进行拆分，从服务入口，到服务实现、服务数据库、服务部署完全独立。因此，新的应用架构需要根据数据源的分布重新编排，形成服务化架构（如图2所示）。

图2 完整的互联网应用架构

　　1.数据库之间耦合向应用服务转变。应用和数据库遵循单元化原则，进行DBLINK治理和数据源治理，避免跨库操作。DBLINK加剧了数据库之间的耦合，容易造成性能的互相影响。因此应该杜绝或者严格管理DBLINK的使用，将DBLINK类的功能变更为应用服务来提供。

　　2.读写功能分离，隔离“列表”类查询功能。将时效性不强的读功能和其他功能进行拆分，独立部署，形成单独的读服务。查询结果经常不可控，大的查询结果使用大量的内存，一旦并发稍大，极易引起应用的崩溃，通过读写分离，可以控制故障的影响范围。

　　3.引入消息系统，进行大事务串行化解耦。将可以一次生成的事务进行分割，引入高可靠消息系统进行异步处理，将大事务变成小事务，来提供系统吞吐。

　　4.前后端架构分离。前后端分离是指把业务展现和业务服务提供从一个大应用里剥离开，分项目进行开发测试部署。前端应用与后端应用边界清晰，前端只使用后端提供的API进行数据交换，前端关注UI展现速度、兼容性、用户体验，可以根据业务的需求进行高频次升级。后端提供完整的业务逻辑和数据处理，关注高并发、高可用、高性能，同时注重数据安全。

　　5.引入缓存架构，降低对数据库资产的消耗。针对配置类数据，引入缓存架构，将对数据库的访问变成内存的应用访问，将大大降低资源的消耗。通过大量缓存的使用，可以显著提高扩展能力，提升系统的响应速度，降低系统负担。从前端缓存到应用缓存，再到数据换错，多层次的缓存，可以有效应对系统接入和处理能力的压力。

　　6.构建统一的异步任务管理平台，将定时任务按照标准化进行封装，实现统一的监控和治理。定时任务类功能一般是以处理数据为主，消耗大量的内存，运行时间较长，同步调用极易引起应用的崩溃，将此类功能剥离出来，可以有效隔离故障，降低对数据库的影响。

　　7.动静分离，分层部署。构建分布式对象存储层，为静态层的对象提供读写服务。影像类、电子保单类、文件类等处理独立成单独的对象服务，不仅仅可以提高安全性，而且可以引入CDN，提高业务的响应速度，减少网络流量。

　　8.外部服务隔离。对于行协、税务等实时交互的平台，需要进行事务隔离，确保这类服务的异常不影响系统的整体服务。

　　9.让应用逐步接管数据一致性。适度让应用提供对数据一致性的保证，减少外键的使用，可以降低事务的复杂度，提高并发性。

　　10.构建统一的服务治理平台。建设统一服务平台，经过两年多的摸索和结合互联网技术，我们完成了统一的基于Ngnix的Web服务和负载均衡平台。搭建了统一的服务治理平台，包括服务路由、编排、灰度、降级、容灾、全链路监控。搭建了统一用户会话平台、统一日志输出、分析监控平台、统一缓存平台。集中平台的搭建解耦了核心业务系统的关注点，让核心业务系统关注业务的逻辑，流程，用户处理，让技术平台解决技术的问题。

　　通过核心架构的转型、落地实施，阳光保险新一代核心系统已经成功上线运行一年之久，取得了很好的效果。以上架构转型的原则或者方法是我们在建设新一代时逐渐形成并行之有效的实战经验；同时良好的核心系统架构也是随着业务需求和技术发展变化而持续演进的。希望本文能给大家带来一些思路方法，并在各自核心系统建设中有一定的指导和借鉴意义。

（文章来源：金融电子化杂志）

扫码即可手机
阅读转发此文