行业系统建设现状不去谈一些虚的上价值的东西东西，作为技术人直面主题，讲解下我对行业系统建设的理解以及对整个行业系统建设的规划
1. 传统架构
中科软的核心系统是目前市场上主流的寿险公司保险系统建设解决方案，无论是系统成熟度以及监管信任度上都是绝对的龙头老大，外资保险公司喜欢选择易保，而国内大的保险公司一般都会选择自研，这些自研的核心系统或多或少都会借鉴中科软的系统建设经验。而大部分中小型保险公司都会选择中科软的核心业务系统。传统架构大部分都是基于如下架构建设：
一般分为核心系统、外围系统、渠道系统和数据平台，核心系统在这个架构下作用非常重要，所有的业务逻辑、业务流程包括收付费、财务数据加工、上报数据加工都是在核心系统完成，可以算是大核心系统，外围系统主要就是一些影像、单证、增值税、资金平台和代理人销管系统，渠道系统主要就是电商平台、银保通、经代通、保单导入平台等；而一些和数据处理相关的系统主要就是监管平台、BI系统和财务系统，中间可能还会加设一个所谓的数据交换平台来做这些数据导入导出、格式转换清洗的工作。行业内大部分寿险系统架构都是在这个架构下衍生而来，包括现在的阿里双中台架构、腾讯的三核心。这个架构后续面临的问题也比较明显，就是核心系统承载着过多的逻辑和任务，导致核心系统自己成为了单点风险、成为了瓶颈，起初可能通过负载均衡（Nginx）来解决一些性能问题和高可用问题，但随着核心系统承载的功能越来越多，简单的负载已经无法支持高可用的问题了，所以就有了后续的“核心减肥”。
2. 轻核心、大外围
随着“核心减肥”概念的推广，“轻核心、大外围” 是很多保险公司该一阶段的建设方案：让核心系统专注于核心业务，更多的流程规则前置，交由上层的渠道和外围系统承接，伴随着业务架构的变化，技术架构也在同步升级，微服务成为很多外围系统架构选择的宠儿，逐渐就演化成了业务中台。
同时数据加工处理的类的工作也逐步抽象，随着hadoop技术的成熟，也逐渐形成了大数据平台的方案，财务、监管、BI都是基于大数据平台的能力进行建设，保险公司逐步将数据平台的建设与业务平台分离开来，形成了自己的保险数据平台。随着AI技术的发展，数据与AI的结合越来越紧密，有些公司会将AI算法作为数据平台的一个组件，也有一些公司会分为数据平台和AI平台。
技术服务于业务，随着业务架构的升级，技术架构也在同步变化，云原生、微服务就是这个时候融入进了保险系统的建设方案中。随着技术复杂度的提升，依赖很多的专业中间件产品或者开源框架，于是就有了技术中台或者能力中台的概念，将这些技术能力进行封装，通过技术中台直接为业务系统提供服务，让业务研发专注于业务，也就形成了如下的架构方案：
是不是和阿里的双中台架构很像啊 ，这个是一个相互影响的过程，毕竟当时阿里的技术在行业内如日中台，开源产品和技术布道都做的非常不错，保险行业的技术迭代恰好赶上了阿里的中台概念推广，所以也就逐渐形成了双中台的解决方案。说实话当时我也是受了一个阿里云的架构师指导，形成了建设保险电商中台的想法并开始实践。当然阿里有阿里的问题，当时并没有被他们的EDAS打动，而是选择了在dubbo的基础上进行二次开发形成自己的微服务框架，后续随着springcloud的出现，也逐步转移到了springcloud的产品体系中。
3. 服务化转型，走向云原生架构
随着保险公司系统架构的复杂加上云厂商为了推广自己的产品，云原生架构成为了目前行业比较推崇的解决方案，用来承载微服务架构以及提供高可用高并发的解决方案确实是一个不错的选择， 但云原生是否真的是必要的，是否这的是保险公司的必然选择？如果厂商给保险公司设定的场景和前提都是正确的，那么云原生确实是一个不错的方案选择。只有保险公司自己才知道自己的真实需求，厂商通常只是想销售产品，抓住商机去推销自己的方案和产品，所以还是需要保险公司技术部自己来去规划和分析。撇开技术选型和需求分析不谈，下面就聊聊云原生架构 ，下面是CNCF就云原生的定义：
首先微服务 + 容器 是云原生的一个重要要素，并不是使用了微服务就达到了云原生的要求，DevOps是一个重要的因素，而且微服务和容器只能在软件层级保证高可用和弹性扩容，基础架构的方案也是云原生的重要依赖之一（不是说一定要上云，良好的虚拟化支持一样可以提供一个高可靠、可扩展的基础架构）。 那么云原生的架构可以简单的表示如下图 ：
保险公司系统是否所有系统都适合云原生架构？ 云原生架构带来的弊端是什么？我们要如何从组织架构、研发体系、运维管理体系去与之相适配？我们的管理能力、研发能力是否可以跟上，相应的人才我们是否可以留住，团队稳定性和人力成本增加我们要如何面对 ？这些都是保险公司需要考虑面对的内容，那么接下来我们首先看下保险公司的系统都有哪些需求，以及云原生的系统架构规划要面临什么样的挑战。
结合之前分析的保险公司的系统中台架构，再考虑到历史遗留系统以及一些财务、监管、税收相关的系统限制，必须要保留一部分传统架构的系统运行，可以得出以下一个稍微细化的保险公司系统架构概图：
保险系统建设目标假想补充说明： 最右下角的PaaS服务主要是指的外部依赖的PaaS服务，比如一些影音视频相关的、AI智能相关的、人脸核身相关的PaaS服务。左下角的管理系统则是指的一些历史系统以及增值税、财务、OA这类的传统架构应用，有些事集中式的SSH架构，有些都不是java体系，比如.NetPHPC++等，这些多数都是内部管理系统，所以我们必须要为这些系统的运行提供一个个服务支撑。
另外我们必须还要考虑的一个问题就是成本问题，微服务是带来了应用解耦，带来了弹性扩容，带来了服务瘦身，但也同时加大了系统研发成本、交流沟通成本、架构复杂度、维护复杂度、外包人员要求的增加。所以我个人认为在规划系统建设的时候，无论是否采用云原生，都要保留一套开发简单、维护方便的集中式架构作为选择，否则就会出现大炮打蚊子的情况。所以不管保险公司新一代架构采用什么方案，个人认为研发框架需要准备至少4套架构： 云原生的微服务框架、单体应用开发框架、管理平台研发框架、前端研发框架（包含移动开发框架）。再加上历史的遗留系统框架，所以一个保险公司的系统面临7、8个开发框架是很常见的事情。
那么我们得到一个结论： 保险系统建设需要针对不同的业务需求和场景提供不同的适配研发架构，才能将研发效能最大化。
撇开对传统架构的兼容，对不同场景的兼容问题，我们需要一个什么样的系统呢？也就是说我们要明确需求，所以我对我自己的设计的系统提供了一个基于自己对保险的理解，制定了一个假设的系统建设需求。 传统的保险业务主要靠的是代理人推广，保险的系统只要提供出单支持、在线服务支持、代理人展业支持即可，所以保险公司的系统主要就是在业务流程建设上投入。随着保险业务的发展，对保险营销、保险客户运营的需求日益增加，对数据资产、营销服务、产品形态的系统支持日益重要，同时银保监对行业合规以及数字化的监管日趋严格，所以我将保险的业务系统分为了产品中心、营销中心、运营中心和监管中心。我们传统的业务流程建设归于运营中心，产品中心也是衍生自核心系统的产品定义模块，监管中心也是从核心系统中监管报表以及一些上报平台扩展而来，基于这个目标后续我们会对整个产品方案进行展开，进行方案完善，需求目标如下图：
以上是我个人的一些理解和浅见，与大家分享。欢迎各位提出宝贵建议，不当之处也欢迎指导指正。
