保险行业核心业务系统中应用微服务架构的方法

摘要：文章首先以微服务架构概述及原理为出发点，分析了微服务架构的关键技术、微服务的拆分与重构策略，提出微服务架构应当考虑的问题，最后主要介绍了微服务架构在保险行业核心业务系统中的应用方法，以供保险行业应用微服务架构的参考和借鉴。

关键词：保险行业;核心业务系统;微服务架构;应用方法

一、引言

随着互联网技术和5G技术的不断发展，保险客户对于互联网的访问质量和效率提出了更高的要求，基于传统单体架构设计理念的应用模式已无法适应当前保险“互联网+”的高速发展需要。在保险产品快速更新迭代、保险客户差异化和个性化需求、金融科技全面发展的背景下，保险行业针对核心业务系统提出了高并发、大流量、高业务连续性及快速迭代交付的要求，传统单体式架构向着分布式的微服务架构已成为解决核心业务系统问题的首选途径。

二、微服务架构概述及原理

（一）微服务架构概述

微服务架构是指将复杂的单体应用拆分成为多个子服务系统的技术架构，使用轻量的通信机制，实现不同子服务系统之间的相互通信、协调和交互。各子系统的应用、数据库均独立部署，根据业务及服务需要而进行通信及调用，各个子系统既保持相对独立又相互配合。在通常情况下，每一个子系统仅代表一个独立微小的业务模块，通过借助全自动部署流水线机制实现快速独立部署。

（二）微服务架构的工作原理

微服务架构是将整个系统划分成多个子服务系统，使用分布服务的治理方式将微服务子系统注册于服务注册中心，通过负载均衡将各个子服务系统部署在生产环境中，通过路由器完成转发请求，客户端通过API网关进行后台访问。各个子服务系统之间可以根据业务需要进行相互访问和数据共享，并使用服务熔断技术，处理子服务系统的降级及熔断问题，对异常服务进行及时的降级及熔断处理，避免整个核心业务系统服务链路出现服务雪崩。

三、微服务架构的关键技术

（一）微服务注册与发现

微服务注册指的是将服务程序中的服务信息注册至服务注册中心，服务信息主要包括为服务程序所在的服务器地址、端口、协议以及服务状态等。不同的实例都需要通过注册中心获得服务，当系统发现在注册中心可以得到其他服务实例并请求提供对应的服务时，对于保险核心业务系统而言，可以将承保、理赔和保单查询等的微服务程序注册到服务中心，实现保险业务微服务功能的灵活调用，并使微服务处于高可用状态。

服务注册中心具有心跳检测、健康检查、异常处置等功能，如果未能检测到节点在多个心跳周期内的心跳，服务注册中心便会主动将其从服务节点中清除，以保证整个微服务系统调用链路的可靠性。微服务架构的注册与发现对于保险行业来说是一次技术上的创新，可以实现灵活的包括服务注册、服务发现及服务剔除等服务治理功能。

（二）微服务网关

微服务网关是一种特殊的服务，用于客户端进入微服务程序的统一入口管理，负责路由请求服务、组合API服务、转换对接协议，一般位于外部Nginx集群和内部微服务集群之间，并不直接对客户端提供服務。在微服务架构模式中，微服务网关通过服务方式，将自己注册到服务注册中心，并通过负载均衡将服务请求转发至各服务节点。

在保险行业核心业务系统中，运用微服务网关统一管理，对保险客户及管理人员的身份认证和安全性可以通过网关识别和控制;将不同服务请求动态路由至微服务集群，保证了各个服务器之间的调用性能，并对请求进行拦截和必要的业务逻辑处理;构建动态响应处理机制，在边缘位置处实现响应，降低和减少其转发至内部集群，进行接口聚合，将不同的请求结果进行合并返回，大幅降低了服务调用的复杂性;可以有效解决微服务应用过程中的权限、路由、API组合、请求过滤等问题。

（三）服务通信机制

在微服务架构设计模式中，完整的应用系统由一组服务构成，为完成业务请求的完整流程处理，就需要这些服务之间进行必要的请求协助和数据交互才能实现。而这些服务实例大都独立部署在相互独立的服务器中，需要进行程序进程之间的通信才能完成交互。

根据交互方式的不同，微服务中存在同步与异步两种通信方式，其中同步通信方式使用请求与响应的方式实现一对一交互，异步通信方式使用异步请求与异步相应或单向通知的方式实现一对一交互、使用发布与订阅或发布与异步响应的方式实现一对多交互。同步通信的交互方式通常使用代理接口用于对通信协议进行封装，常用的有REST或gRPC。异步通信的交互方式多使用消息代理，较为流行的消息代理有Apache ActiveMQ、Apache Kafka及RabbitMQ等开源软件。

（四）微服务运维

传统的单体架构属于单块应用结构，而微服务架构是一种多服务和多应用的结构。对比单体架构模式，微服务架构由于其运行节点多、部署方式多样化，问题点往往会出现在不同的地方，加之服务产生的日志较多，因此需要在大量的日志中找到问题的所在就会变得异常困难，需要借助完善的日志管理和服务运行状况监控，从硬件层面、系统层面以及服务访问层面实现切入式的全链路管理。在保险行业核心业务系统中应用微服务架构，可以利用聚合监控组件保证监控的正常运行，对微服务架构技术平台实现全方位、全链路的监控，通过设置合理的熔断和降级调控开关，实现必要的服务降级控制和服务限流控制，自动化地调整具体的应用运行状态。

四、微服务的拆分与重构策略

（一）微服务拆分原则

微服务架构的核心理念是对应用系统拆分为高内聚、低耦合的一组服务，进行独立部署，实现独立运行，并通过服务间通信进行交互。为实现微服务架构设计的最佳实践，保险行业在进行微服务拆分时，可以从营销管理、承保服务、理赔管理、客户服务、再保管理及风控管理等业务能力维度入手，分析保险公司运营管理流程、抽象出保险业务能力、根据业务能力映射并定义出服务;也可以从保险业务领域的客户投保、保单批改、报案、查勘、定损及两核等子域入手，分析保险公司运营管理各领域、抽象出保险业务子域定义出服务。在定义和实现服务的过程中，一般以服务所承担的业务职能尽量单一并能在一个服务中完整实现为原则，以达到良好的可维护、高容错及易部署要求。

（二）微服务重构策略

因保险行业信息化发展的历史原因，保险行业核心业务系统大多采用传统的单体架构，存在产品交付慢、软件扩展性差及版本交付质量低等问题，技术债务较大，设计全新的基于微服务架构的核心业务系统快速替代现有系统的成本较高，可以采用逐步替换的策略进行微服务重构，将新需求所延伸出来的业务能力按照微服务模式进行设计，以微服务开发新功能，并与原单体架构应用进行集成，以实现业务需求的快速交付;划分原单体架构应用的前后端边界，进行必要的拆分并隔离，逐步缩小其应用范围，并实现前后端的独立开发、部署和维护管理;主动对原单体架构应用的业务能力进行抽象和提取，按照微服务架构模式进行重新定义和实现，随着服务的不断被提取，微服务的业务功能不断扩展，原单体架构将不断缩小，直至下线。

五、应用微服务架构时需要面临的问题

（一）运行的可靠性

微服务架构采用灵活、复杂的通信机制，如果网络出现问题或者是某一个服务节点出现故障，就会导致服务调用失败，当需要服务的对象和数量越来越多时，故障点也会在这样的背景之下快速增加，为了保证系统的稳定、安全和可靠运行，需要一个健全与完善的保障机制为支撑。

（二）运维的复杂性

微服务架构的技术栈较为丰富、多采用分布式部署、服务节点多、服务之间调用和交互关系复杂，为实现快速交付的目的，应用自动化的持续交付/持续部署，使得整体部署和运行环境十分复杂，对运维的要求较高，需要建设全域环境的自动化管理体系，实现对微服务的实时监控、服务异常的自动处置、服务资源的弹性扩展，以提高微服务系统的高可用性、业务连续性和安全性。

（三）分布式事务的一致性

随着微服务架构的流行与普及，过去需要在单体应用中执行的多个逻辑操作现已被拆分成了多个服务之间的远程调用，各子服务一般拥有独立数据库，这将带来分布式事务的一致性的问题。对习惯于传统单体架构ACID事务的开发团队而言，将会面临很大的障碍。

六、微服务架构在保险核心业务业务系统中的应用

保险行业属于金融严监管行业，信息化建设起步较早、力度大，保险公司大多基于传统单体机构构建了支撑业务作业管理的核心业务系统。但随着保险行业“互联网+”的高速发展，对核心业务系统提出了高并发、大流量、高业务连续性及快速迭代交付的要求。现有核心业务系统的诸多问题逐步暴露，比如新产品开发上线慢、互联网保险支撑能力弱、保险客户体验度低;而微服务架构天然具有业务整合能力强、产品交付速度快和用户体验度高的架构能力，具有高并发、高可用和弹性扩展等特点，可以有效解决保险核心业务系统所面临突出问题。

（一）微服务框架的技术选型

技术选型从当前核心业务系统既有业务流程管理模式和技术栈入手，充分考虑核心业务的复杂程度、核心开发团队能力、微服务技术积累以及技术栈转换和迁移过程中的兼容性。目前微服务主流技术框架有第一代的Spring Cloud及Dubbo、第二代的有Istio，框架情况对比。微服务架构的选择必要要与保险公司的业务、技术及团队情况相匹配，找准合适切入点，选择合适的开发框架;因笔者所在公司以Spring/Spring Boot框架为主，选择基于Spring Cloud的微服务框架进行系统重构较为适宜。

（二）核心业务系统的重构与实践

围绕Spring Cloud微服务架构，对核心业务系统按照业务服务职责、业务活动域综合分析，进行适应保险行业运营管理的核心业务系统微服务拆分，规划出产品服务、定价服务、营销服务、费控服务、承保服务、批改/保全服务、保险理赔、收付费、客户管理及智能风控等子系统，使其对保险业务的支撑更加便捷、可靠和弹性。应用架构如图2所示。

采用基于Spring Cloud微服务架构作为保险核心业务系统的基础技术平台，落地实施保险核心业务系统的应用總体架构，将服务治理、配置管理、日志管理、CI/CD、全链路监控等开源组件整合起来，将敏捷开发与持续交付融合起来，全面嵌入自动化运维当中。

采用新业务功能以服务方式实现、变更运行环境部署方式及存量业务功能转换为服务方式的多维度、综合的重构策略，按照统一规划的核心业务系统应用架构和技术架构，在限制原核心业务系统单机架构持续扩展的基础上，逐步以微服务模式进行持续的迭代更新，结合敏捷开发和DevOps实践，以实现核心业务需求的快速交付和循环迭代改进，最终实现核心业务系统微服务架构整体改造，推动其业务平台和技术架构的持续更新升级。

七、结束语

综上所述，在保险行业核心业务系统中的应用微服务架构，对已有系统进行重构、整合和升级，可以有效提高保险产品和业务功能的迭代升级速度，适应高并发、大流量及高业务连续性的要求，但也面临着系统安全性、稳定性及数据一致性等方面的高要求。基于当前保险科技快速发展的利好背景下，各项新技术不断出现并快速应用于保险科技当中，如何让微服务架构更好地应用于核心业务系统的迭代建设中，是一个需要持续研究和探讨的问题。

作者单位：侯守立    浙商财产保险股份有限公司

参  考  文  献

[1]王方旭.基于Spring Cloud实现业务系统微服务化的设计与实现[J].电子技术与软件工程，2018（08）：60-61.

[2]辛园园，钮俊，谢志军，张开乐，毛昕怡.微服务体系结构实现框架综述[J].计算机工程与应用，2018，54（19）：10-17.

[3]克里斯·理查森（Chris Richardson）.微服务架构设计模式[M].喻勇译.北京：机械工业出版社，2019.

[4]王丽沙. 基于微服务架构的保险核心系统改造[D].上海交通大学，2020.