退运险业务及系统架构演进史

⽂章简介：本⽂回顾退运险上线⼗年以来相关系统架构的演进。

背景   

退运险对于我司来说是⼀个举⾜轻重⼀款产品，初创时期贡献了 99.9% 的保费收⼊，随着公司的发展各类产品的不断创新，退运险的⽐重在缩⼩，但 它的规模在不断扩⼤，当前年保单量已超百亿。为了满⾜业务的发展，相应的系统经历不断的演进。

初代架构

核⼼系统于 2013 年 11 ⽉开始设计，当时不知道业务到底能有多⼤，所以起个名字叫⽆界⼭，由于对未来的不可知，初版微架都⽐较保守（初代⼤神⼤⻦⾔）。退运险作为其⽀持的最重要也是量最⼤的业务，很多设计都基于它，当时⽇需处理的保单达 380 万，可能现在看这个数据不算什么，但是要知道当时通常中⼩型保险公司核⼼系统的⽇均⽀持保单量在 10 万以内，较普遍是 1 ⾄ 3 万左右；⼤中型公司则约在⼏⼗万量级，不超过百万。处理⽅式也特 别简单：ODPS 预处理报⽂，再解析报⽂，扔出 notify 消息，核⼼收到后处理，通过分库分表⽅式解决⼤数据存储问题。各个系统在 hsf 等中间件的帮助下具备⽔平扩展能⼒。

初代架构存在的问题是性能实在是蜗⽜，资源调度极度上不去，消息压⼒⼤，⼀旦有异常，堆积导致 notify 奔溃，业务规模也不断在扩⼤，特别是双⼗⼀⼤促时尤为突出，⽇保单量已达亿级别，系统也渐渐显得⼒不从⼼，2015 年进⾏升级引⼊美洲豹（JStorm），将之前 dispatcher 和 nightelf 两个项⽬合⼆为⼀，架构上通过中间件解决⽔平扩容和单点问题，于当年年 11 ⽉份正式⽣产运⾏。

⼆代架构  

初代架构迭代优化后基本能很好的⽀持退运险业务，但是公司在不断发展，后续健康险、意外险、财产险等业务不断的开展，核⼼系统也需要⽀持 越来越多的实时业务，对系统的稳定性要求越来越⾼，然⽽退运险⼊库时间⽐较集中，系统负载持续在⾼位，导致系统稳定性下降。要同时⽀持退运险业务和实时业务，虽然可以通过⽔平扩容的⽅式提⾼系统的吞吐量，但是⼀ 天就跑四五个⼩时跑报⽂，扩容会⼀定程度上造成资源浪费，⽽且在跑报⽂时间段内也不能避免不影响实时业务。在电商平台进⾏⼤促活动时尤为突出，在双 11 期间为了追求更⾼的 QPS，前期需要投⼊⼤量的⼈⼒和资源进⾏ 系统调优和压测，⽣产也需要准备⼤量的云资源进⾏⽀持。JStorm 是分布式 实时计算引擎，⽽在退运险场景⾥只⽤其任务分发的功能，有点杀鸡⽤⽜⼑。⽽且 JStorm ⽇常维护成本太⾼，使⽤极其不便。  

在 2018 年进⾏⼀次完全的重构，针对退运险的业务基于⽆界⼭核⼼系统衍⽣出⽆界⼭-电商⼦系统，底层使⽤⽆界⼭ 1.0 的 DB，⽀持电商场景包括退运险、保证保质保险等创新业务。得益于公司 Devops 的建设，让这套系统测试、发布和扩容更⾼效。服务间的调⽤使⽤ dubbo，消息中间件使⽤ kafaka， bill 服务也通过消息进⾏异步处理。上线后当年双 11 单⽇⽀持 8 千万保单⼊库， 峰值 TPS 达到 2.2 万，期间未造成其它实时业务的超时等异常情况。   

完成基础架构调整后，于 2019 年进⾏业务层的深度优化。因为退运险作为公司第⼀批险种，在核⼼已经运⾏了五六年。在这段时间⾥，核⼼已经新上了数千个产品，对接了四五个事业部，为了兼容，原有的单独针对淘系报⽂的⼊库逻辑已经被改的⾯⽬全⾮。另外⼈员以及部⻔的变动，短时间内经历多次交接，⼀些特殊逻辑在过程中没交待清晰。以上这些问题，都给维护、测试和排错等⼯作带来诸多的不便。⽽随着众安与淘系的合作程度加深，淘系退运险保单量正在进⼀步增加，预计 2019 年双⼗⼀会达到顶峰。完成本次优化后，删减了冗余的代码逻辑，减少了 DB 查询次数，提升了系统的整体性能。上线后 2019 年双 11 单⽇处理保单 1.6 亿，处理⽤时⽤了 160 分钟， 峰值 TPS 达 2.7 万，报⽂报⽂同⽐去年增加⼀倍处理时⻓缩短 40%。

主要改进内容：

开发⽆界⼭-电商⼦系统，与其它险种系统进⾏隔离，减少相互影响，bill 通过 kafaka 异步⼊库，进⼀步削峰；

使⽤ dubbo 中间件替代⽼旧的 HSF 进⾏服务间调⽤，提⾼系统性能；

使⽤新的报⽂处理平台和 kafaka 消息中间件替代 JStorm 进⾏异步处理；

优化 ODPS 预处理逻辑，调整报⽂结构，降低 ODPS 处理资源消耗；

产品配置、⽤户信息进⾏本地化缓存，减少重复 DB 查询，提升系统性能。

三代架构   

数字⽣活事业部⼀直在⾮阿退运险⽅向进⾏了不断地努⼒，期间接⼊过蘑菇街、趣店等电商平台，但都量不⼤⽇保单在万单级别，近年来随着抖 ⾳、快⼿等新兴平台电商业务蓬勃发展，使得退运险在⾮阿渠道得以突破， 2020 年 6 ⽉份快⼿接⼊，2021 年 7 ⽉份抖⾳接⼊后，⾮阿退运险⽇保单量逐渐超千万单。退运险不仅仅只有阿⾥单⼀渠道和场景，逐步向多元化的⽅向发 展。三代架构在这过程中也逐渐形成，公司⽆界⼭核⼼也升级为 2.0 不在和退 运险共⽤ DB，其它险种和退运险相互再⽆影响。根据当前需求新开发报⽂管 理平台，使⽤ OCeanBase 分区表替代原来分库分表，使⽤ Redis 的 Message queue 进⾏报⽂⽂件的分发处理。以及开发 gateway-data、anacientone 系统处理退运险实时业务。   

在降本增效的环境下，不再不计代价的追求⾼ QPS，⽽是要求以更经济的⽅式⽀持业务。为了达到这个⽬标，在优化系统的同时，也优化业务模式，⽐如淘系报⽂之前 T +1 给前⼀天所有的报⽂，导致会出现⼀个报⽂有上亿条数据，处理数据时间过于集中，处理过程只能串⾏进⾏，导致系统资源没有充分利⽤。最终我们和渠道⼀起进⾏优化整改，以 T+H 的⽅式给报⽂增加给报⽂频次，给了更⻓的时间窗⼝处理数据，也⼤⼤减少单个报⽂数据量， 从⽽进⼀步进⾏了削峰，⽇常只需 400QPS 就能保障业务正常运转，以往需要 达到 4000QPS。⼤促期间以往需要⼏⼗台 ECS ⽀持，QPS 需要达到 2 万，现 在只需原来的⼗分⼀就能满⾜要求，以更少的系统资源⽀持业务，达到降本增效的⽬的。同时也提⾼保单的⼊库时效，提升了⽤户体验。

主要改进内容：

⽀持实时接⼊，其中快⼿以及⼀些⼩渠道通过实时⽅式接⼊；

⽀持配置个性化策略解析报⽂，可以配置不同频次解析报⽂；

⽀持异常检测、预警，以及⾃动修复；

剔除 ODPS 预处理报⽂，⼀来减少报⽂处理环节，⼤⼤降低⼤⽂件传输消 耗，⼆来直接减少了 ODPS 计算费⽤；

⽀持回传结果⽂件，解决对账问题；

其它险种 DB 隔离，不再相互影响。

总结

对⽐三代架构，其中的中间件可能⼤不相同，但是核⼼的思想基本是⼀致的，就是通过异步的⽅式进⾏削峰。⼤道⾄简⽀持年保单量百亿的系统也 不过如此。其实退运险虽然数据量庞⼤，但是它在电商的交易场景⾥⽤户感知不强，所以它对实时性的要求⽐较低，结合它的这⼀特性才有这样的系统 设计。另外是因为站在巨⼈的肩膀上，依托公司的各项基础设施，才能这么简单构建这类处理海量数据的分布式系统。   

我司成⽴⼗周年，退运险业务上线也正好⼗年，这⼗年业务规模不断地扩⼤，形态也有变化，系统经历了⼏次变⾰。也经历公司各个时期，从⼈⾁运维，到 Duang、boom、ship、最后到现在的 DevCube。基于公司⾃研的 DevOps 研发运维⼀体化解决⽅案，使我们的系统能敏捷迭代，全链路监控预警，以及快速修复⽣产故障等。   

退运险是互联⽹的产物，所以得益于互联⽹相应的技术和思想，才构建这套系统。正如布鲁克斯在《⼈⽉神话》中所说的没有银弹，没有⼀个系统 ⼀开始就能做到尽善尽美，会随着业务发展、技术进步不断的调整和优化。 回头看之前的技术选型会有问题，但在当时就是最合适的⽅案。  

本⽂未对业务场景以及⼀些技术细节进⾏展开，对相关⽅⾯有兴趣的同学可以单独找我探讨。后续相关的负责⼈也会输出相关⽂章介绍。