三津谈保险系统建设（一）： 现状分析和建设目标规划

不去谈一些虚的上价值的东西东西，作为技术人直面主题，讲解下我对行业系统建设的理解以及对整个行业系统建设的规划

行业系统建设现状

1. 传统架构
中科软的核心系统是目前市场上主流的寿险公司保险系统建设解决方案，无论是系统成熟度以及监管信任度上都是绝对的龙头老大，外资保险公司喜欢选择易保，而国内大的保险公司一般都会选择自研，这些自研的核心系统或多或少都会借鉴中科软的系统建设经验。而大部分中小型保险公司都会选择中科软的核心业务系统。传统架构大部分都是基于如下架构建设：

一般分为核心系统、外围系统、渠道系统和数据平台，核心系统在这个架构下作用非常重要，所有的业务逻辑、业务流程包括收付费、财务数据加工、上报数据加工都是在核心系统完成，可以算是大核心系统，外围系统主要就是一些影像、单证、增值税、资金平台和代理人销管系统，渠道系统主要就是电商平台、银保通、经代通、保单导入平台等；而一些和数据处理相关的系统主要就是监管平台、BI系统和财务系统，中间可能还会加设一个所谓的数据交换平台来做这些数据导入导出、格式转换清洗的工作。行业内大部分寿险系统架构都是在这个架构下衍生而来，包括现在的阿里双中台架构、腾讯的三核心。这个架构后续面临的问题也比较明显，就是核心系统承载着过多的逻辑和任务，导致核心系统自己成为了单点风险、成为了瓶颈，起初可能通过负载均衡（Nginx）来解决一些性能问题和高可用问题，但随着核心系统承载的功能越来越多，简单的负载已经无法支持高可用的问题了，所以就有了后续的“核心减肥”。

2. 轻核心、大外围
随着“核心减肥”概念的推广，“轻核心、大外围” 是很多保险公司该一阶段的建设方案：让核心系统专注于核心业务，更多的流程规则前置，交由上层的渠道和外围系统承接，伴随着业务架构的变化，技术架构也在同步升级，微服务成为很多外围系统架构选择的宠儿，逐渐就演化成了业务中台。
同时数据加工处理的类的工作也逐步抽象，随着hadoop技术的成熟，也逐渐形成了大数据平台的方案，财务、监管、BI都是基于大数据平台的能力进行建设，保险公司逐步将数据平台的建设与业务平台分离开来，形成了自己的保险数据平台。随着AI技术的发展，数据与AI的结合越来越紧密，有些公司会将AI算法作为数据平台的一个组件，也有一些公司会分为数据平台和AI平台。

技术服务于业务，随着业务架构的升级，技术架构也在同步变化，云原生、微服务就是这个时候融入进了保险系统的建设方案中。随着技术复杂度的提升，依赖很多的专业中间件产品或者开源框架，于是就有了技术中台或者能力中台的概念，将这些技术能力进行封装，通过技术中台直接为业务系统提供服务，让业务研发专注于业务，也就形成了如下的架构方案：

是不是和阿里的双中台架构很像啊 ，这个是一个相互影响的过程，毕竟当时阿里的技术在行业内如日中台，开源产品和技术布道都做的非常不错，保险行业的技术迭代恰好赶上了阿里的中台概念推广，所以也就逐渐形成了双中台的解决方案。说实话当时我也是受了一个阿里云的架构师指导，形成了建设保险电商中台的想法并开始实践。当然阿里有阿里的问题，当时并没有被他们的EDAS打动，而是选择了在dubbo的基础上进行二次开发形成自己的微服务框架，后续随着springcloud的出现，也逐步转移到了springcloud的产品体系中。

3. 服务化转型，走向云原生架构

随着保险公司系统架构的复杂加上云厂商为了推广自己的产品，云原生架构成为了目前行业比较推崇的解决方案，用来承载微服务架构以及提供高可用高并发的解决方案确实是一个不错的选择， 但云原生是否真的是必要的，是否这的是保险公司的必然选择？如果厂商给保险公司设定的场景和前提都是正确的，那么云原生确实是一个不错的方案选择。只有保险公司自己才知道自己的真实需求，厂商通常只是想销售产品，抓住商机去推销自己的方案和产品，所以还是需要保险公司技术部自己来去规划和分析。撇开技术选型和需求分析不谈，下面就聊聊云原生架构 ，下面是CNCF就云原生的定义：
首先微服务 + 容器 是云原生的一个重要要素，并不是使用了微服务就达到了云原生的要求，DevOps是一个重要的因素，而且微服务和容器只能在软件层级保证高可用和弹性扩容，基础架构的方案也是云原生的重要依赖之一（不是说一定要上云，良好的虚拟化支持一样可以提供一个高可靠、可扩展的基础架构）。 那么云原生的架构可以简单的表示如下图 ：

保险公司系统是否所有系统都适合云原生架构？ 云原生架构带来的弊端是什么？我们要如何从组织架构、研发体系、运维管理体系去与之相适配？我们的管理能力、研发能力是否可以跟上，相应的人才我们是否可以留住，团队稳定性和人力成本增加我们要如何面对 ？这些都是保险公司需要考虑面对的内容，那么接下来我们首先看下保险公司的系统都有哪些需求，以及云原生的系统架构规划要面临什么样的挑战。
结合之前分析的保险公司的系统中台架构，再考虑到历史遗留系统以及一些财务、监管、税收相关的系统限制，必须要保留一部分传统架构的系统运行，可以得出以下一个稍微细化的保险公司系统架构概图：

补充说明： 最右下角的PaaS服务主要是指的外部依赖的PaaS服务，比如一些影音视频相关的、AI智能相关的、人脸核身相关的PaaS服务。左下角的管理系统则是指的一些历史系统以及增值税、财务、OA这类的传统架构应用，有些事集中式的SSH架构，有些都不是java体系，比如.Net\PHP\C++等，这些多数都是内部管理系统，所以我们必须要为这些系统的运行提供一个个服务支撑。

保险系统建设目标假想

另外我们必须还要考虑的一个问题就是成本问题，微服务是带来了应用解耦，带来了弹性扩容，带来了服务瘦身，但也同时加大了系统研发成本、交流沟通成本、架构复杂度、维护复杂度、开发人员要求的增加。所以我个人认为在规划系统建设的时候，无论是否采用云原生，都要保留一套开发简单、维护方便的集中式架构作为选择，可以极大降低二开的成本和需求响应效率。
所以保险公司新一代架构无论采用何方案，研发框架建议至少准备4套架构： 云原生的微服务框架、单体应用开发框架、管理平台研发框架、前端研发框架（包含移动开发框架），加上历史的遗留系统框架，所以一个保险公司的系统面临7、8个开发框架是很常见的事情。

保险系统建设需要针对不同的业务需求和场景提供不同的适配研发架构，才能将研发效能最大化，提高需求研发效率，降低维护成本。

我对保险系统的建设设计是建立在我对保险业务需求理解的基础上，我在此基础上规划出了目标产品需求大图 。首先我先把我的业务假设描述出来，方便理解和讨论

首先谈下保险核心最终要的核心业务运营功能，此部分功能的成熟是在支持传统保险业务的阶段由简单到复杂再回归简单，经历这个阶段保司的核心系统的业务运营支持功能已经相对成熟。这里提下传统的保险业务是以代理人线下推广为主要模式，业务以线下收单、集中录入为主，代理人作为保险公司与客户的桥梁，起到至关重要的作用，运营团队如何支持好代理人的工作，如何快速出单、对代理人提供展业支持成为此种业务模式的主要工作。此时的保险系统注重的是对核心业务的运营流程支持，包括新契约出单、新单收费、影像管理、单证管理、保单服务支持等，配合上代理人展业平台，支持线下业务的开展，传统保险业务的保险系统的建设重点在保险业务运营能力建设和新产品支持能力建设上。
随着保险业务的发展，渠道出单逐步占有越来越重要的位置，银保、经代业务的迅速崛起，加上互联网的蓬勃发展，各式各样的电商平台、垂直业务平台都逐步与保险挂钩，以蚂蚁保、微保、携程、饿了么等电商网站的交易崛起，保险公司的产品发生了变化，对新产品的上线速度、产品的形态要求越来越高，同时保费规模、保单数量都急剧增加，这些业务上的变化，使得保险公司必须优化系统能力，对产品中心、保险营销、保险客户运营的需求日益增加，产品中心、营销中心在此基础上逐步形成（产品中心解决产品统一管理、快速上线和产品运营等需求，而营销中心不单单指的营销活动，包括了客户运营、客户服务、营销活动、客户触达投放等，每家保司叫法不同，但大都具备这些能力）
另外随着业务的快速发展，带来的问题也越来越多，这时候银保监针对新的业务模式、产品形态逐步形成了新的监管要求，同时银保监为了推动行业的数字化建设，中银保信的成立为各家保司提供了一个行业的服务标准和上报平台。随着行业合规以及数字化的监管日趋严格，保险公司对监管上报也越来越重视，逐步形成了监管中心，应对银保监、行业协会、各个地方保监局的监管要求，为业务保驾护航（毕竟被监管处罚的代价还是蛮大的）
基于以上的业务假设，我将保险的业务系统分为了产品中心、营销中心、运营中心和监管中心。我们传统的业务流程建设归于运营中心，产品中心也是衍生自核心系统的产品定义模块，但有不能只服务于核心系统，所以独立出来成为单独的产品中心支持整个保司的系统产品需求，监管中心也是从核心系统中监管报表以及一些上报平台扩展而来。
基于以上的业务场景，我形成了一个保险业务系统的产品需求规划，欢迎各位同行指正讨论。后续我会对这个产品需求逐步拆解，形成保险数字换建设的产品方案。