来源：金科创新社微信公众号

在保险行业作业线上化、数据统一化的发展趋势下，传统核心系统架构随着展业工具更新换代，在长期持续迭代中集成了大而全的功能，在合理性、延展性、复用性、交付时效、交付质量等方面需要适用业务的发展，做到通过科技驱动高质量的业务发展。

鉴于此，在满足公司战略落地、销售展业需求的前提下，保留原有系统作业流程，解耦重要功能，建设保险业务中台系统成为沉淀业务能力、赋能前端业务，推进数字化升级的关键。

和谐健康银保业务中台集成了分布式技术、私有云高可用部署、微服务架构、敏捷交付工具、消息队列中间件、项目需求管理工具、自动化测试工具、系统网关层安全组件等，在架构转型、数据处理、产品工厂及流程管理等方面进行了有益探索和实践。

一、稳定的系统支撑业务发展

1.高并发集中出单系统建设迫在眉睫

2021年公司要求系统在几秒内支撑百亿级别的保费出单。经多方面的压力测评，当前系统高峰期并发处理能力无法满足瞬间高并发的业务场景需求，高并发集中出单系统建设迫在眉睫。

2.传统“烟囱型”系统架构与前端展业系统发展节奏不匹配

随着公司业务发展，按销售渠道划分出不同的App、小程序等前端出单系统，需要为每个对接系统研发对应的应用接口，极大的增加了研发周期及项目成本，急需一个可为上游系统提供统一接口，为下游核心系统进行标准化数据落地，且复用性强、延展性高的中间系统。

3.第三方出单系统对接成本激增

公司对接银行系统达到几十家，对接中介公司几百家，业务的开展对于系统交付时效的能力提出了更高的要求。不同第三方出单系统在交互标准以及数据完整性、闭环性等方面的要求不同，使得系统对接过程中产生大量代码冗余，以及由于开发标准不统一而导致风险激增，需要一套更合理、交付速度快、标准化强、维护成本低的中台系统。

二、银保中台建设思路

1.解耦核心，消峰可控

银保中台依据交易场景、数据结构进行分布化集成规划设计（见图1），既可在下游系统停机过程中独立完成上游系统的服务请求，又可根据下游系统处理能力进行访问量控制，在海量交易场景中设置熔断降级，实现与核心系统解耦，降低下游系统压力。

2.读写分离，多维风控

准实时写入业务数据库，实时访问数据中台。对计算指标进行参数化，相同参数提前计算并对结果数据进行预加载缓存，不同参数进行指标标准化便于传入执行。对数据进行热点分析，采用数据同步工具进行分等级频率同步。

3.监控补偿，交易可靠

根据“业务场景+数据流向”进行交易过程埋点监控，对于异常数据进行实时捕获并告警，根据埋点数据特征进行系统自动补偿或人为干预，保障系统交易的完整性、可靠性。

4.架构灵活，持续交付

系统规划蓝图如图2所示，依托微服务技术，逐步落地实施如下功能模块。

①交易中心：标准化OpenAPI，投保核保规则管理、客户管理、保单管理、数据批量同步等。

②运营中心：智能核保、智能风控等。

③产品中心：产品定义、保单计算、产品服务等。

④风控中心：黑名单客户管理、第三方系统对接、风险保额查询等。

⑤财务中心：第三方支付服务对接、支付查询等。

三、技术实现特点‍

1.技术集成度高

系统架构如图3所示，分为基础组件层、工具层、服务中心、应用层、网关层、视图层，通过合理使用一系列技术工具达到既定目标。

①前端：采用VUE+ElementUI，实现前后端分离。

②网关管理：提供OpenAPI，使用Swagger提供可视化Web API，降低沟通成本，动态生成API接口，实现上游系统快速对接；使用Zuul实现了网关服务的高可用、高性能；支持Http、Socket、Webservice等协议；支持MD5、DES、SSL网关接入、国密算法等数据加密。

③应用层：采用SpringBoot开发框架，对接规则引擎、批处理引擎，提供原子化服务进行交易编排。

④敏捷交付层：采用自研的需求平台进行需求管理，使用自研的自动化平台进行持续交付，使用版本控制工具进行项目过程管理文档，使用SoapUI提升交付质量。

⑤基础组件层：按需使用RabbitMQ、RocketMQ、ActiveMQ、Kafka等消息队列进行交易；使用SLB负载，提升横向扩展能力；使用Redis缓存组件对热点数据进行K/V模式预加载；使用ELK、SLS进行运维日志归集，数据库支持MySQL主流数据库。

2.预加载热点，处理复杂计算要素

依托于底层数据源结构，结合交易场景链路对计算要素进行如下处理。

①数据抽取：高频数据（客户累积风险保额、产品期停售控制、代理网点/人）等采用OGG同步数据中台指定表数据到业务中台MySQL数据库后，使用Canal组件进行增量订阅、消费MySQL的Binlog日志数据至RabbitMQ中间件。

②数据清洗：接收到增量数据后，首先判断数据是否为自增，自增数据则不做处理，非自增数据利用数据主键进行计算。以客户风险保额为例，消息队列消费消息过程中，以解析后的保单号判断是否为业务中台受理的保单作为幂等条件，未触发幂等则根据单号查询客户五要素，根据五要素遍历客户层级各个保单，根据风险保额类型，以客户五要素为Key计算后的风险保额为Value的Redis缓存，再次出单时实时计算当前客户在途+存量的累积风险保额，并在受理成功后进行实时更新累积缓存。

③数据加载：预加载数据分为高频（保单产品计算要素、投核保计算要素、代理机构/人有效性等）、低频（保单受理状态、服务器配置信息、单证领用信息等）两种，高频采用以上描述实时同步；低频数据利用数据中台ETL工具，定时同步到中台数据库进行直接数据加载到Redis缓存。

3.构建产品工厂，实现一次开发高度复用

通过一个平台进行产品定义，根据产品计算要素、产品基础信息、产品投核保规则、产品计算公式、产品受理条件等信息，通过产品工厂模块实现一次性开发已有全出单渠道适用。根据对接渠道，细化交易范围，微调个性化数据传输，通过微服务架构中的原子服务编排即可满足新增渠道、交易迅速对接。（见图4）

4.打造标准化作业流程

一是在系统生命周期中，通过关键位置埋点，使用Swagger进行对外API实时更新，外围研发团队通过此工具可随时试错，极大减少沟通成本。

二是作为公司前端系统标准化对接流程，高度复用，减少对接成本。

三是MQ消息中间件对交易全链路进行数据持久化，对消息消费节点进行监控预警，如遇系统问题可以根据订阅消息进行单点补偿或部分交易链路进行数据补偿，保障数据的一致性和完整性。

四、项目成效

银保业务中台对接银保渠道，高效平稳支撑了2022年1月开门红作业高峰期出单，实现700TPS的高并发响应；对接新增渠道，缩短交付周期，提升交付质量，降低了研发、运维成本。

交易量指标方面，2022年1月1日银保渠道开门红业务高峰当日交易总量达到21.7万笔，平均交易耗时290毫秒，作业高峰780笔/秒。2023年1月1日银保渠道开门红业务高峰当日交易总量39.3万笔，平均交易耗时341毫秒，作业高峰2312笔/秒。与2021年老系统宕机、平均交易耗时2.5秒、处理瓶颈28笔/秒、吞吐量2.7万笔相比，业务中台上线后表现突出，完全满足出单需求，效果提升明显，运行平稳可靠，无生产事故产生。

系统性能指标方面，高峰期中间件资源使用率29%，CPU占用率67%，内存使用率34%，磁盘读写15.17/秒，系统资源预估、分配合理，未达到系统上限。

交付时效、运维指标方面，一是对接外围、第三方出单系统由20-30天缩短至5-10天，由每1款产品对接每1家渠道研发周期为5-8天缩短至1款产品对接1次即满足所有渠道出单；二是实现标准化API、标准化微服务处理、产品工厂化，在公司内部形成了系统研发标准，可以迅速对接新增交易渠道，极大提升了研发产能；三是在交易链路中埋点，下钻探针，实现一体化运维（如图5所示），降低运维成本。

五、经验总结

在系统剥离、重构的过程中遇到了三个无法绕过的问题：上线版本控制问题（项目实施至上线过程中会产生增量需求并行问题，如已有需求不上线、新提需求紧急上线、未上线需求同步/延后上线等）、数据一致性问题(不同上游系统上线时间不同，过程中如果为非本平台受理的交易数据，将受制于非实时的数据同步结果，此外也难以避免非标准化生产运维数据产生)、外围平台兼容性问题(在对接下游第三方服务系统时，如第三方体检服务平台、第三方风控平台、加密机等，如对其他系统承载量预估不足，将很容易导致系统处理能力下降，影响交易响应速度）。

针对上述问题，采取了如下解决办法。

版本控制方面，采取分步验证方式，减少问题产生概率。上线前进行平行测试，将预估范围内（如按周期1个月、1年或按不同渠道、不同产品）的交易数据，同步生产环境，按时间顺序进行批量交易，比对上游响应结果和下游落地数据，采用灰度上线方式，按最大可容忍比例进行灰度验证、灰度试运行，同时监控数据准确性，一段时间后逐步扩大灰度范围至全面上线。

数据一致性方面，只有所有交易环节全部接入业务中台系统后数据一致性问题才能从根本上解决，逐步交付的过程中，需要采用定期巡检重算的方式，将持久化缓存数据提前异步重算、实时更新。

外围平台兼容性方面，在已有交易链路中增加外围服务平台需要做好系统资源的预估规划，保证上下游系统的处理能力，采取业务高峰期弹性配置扩展资源，设置熔断、降级等措施，以防系统雪崩。