微服务架构应用于保险行业核心业务系统的探讨

朱俊

【摘要】    随着信息技术的不断发展，传统的单体开发架构已难以适应保险行业险种产品在核心业务系统中快速迭代上线的业务需求.微服务架构是一种将一个单体应用程序开发拆分为一系列小型服务程序开发的架构，每个服务独立运行在各自的进程中，服务间通信采用了相对较为轻量级的通信规则并且强调服务组件化，同时支持在云中部署各类应用和服务，增强了系统的伸缩性和负载性能，系统维保人员可快速响应险种产品的开发需求，有效的缩短交付周期，并可结合微服务架构中的持续集成和持续部署工具，实现险种产品的快速上线。但该架构在系统效率、维护以及成本方面也带来了一些新的挑战。本文以微服务框架为基础，以险企核心业务系统的建设为背景，探讨架构应用于系统带来的创新与问题。

【关键词】    微服务架构    保险行业    核心业务系统    Spring Cloud

引言

随着人们生活水平的不断提高、对风险意识的不断增强以及对自身风险保障意识的逐渐重视，带动了各险企险种产品的不断发展及更新。而险种业务的正常开展，除险种产品自身的特点外，核心业务系统的稳定运行及能否快速地上线险种产品起着至关重要的作用。从核心业务系统的研发和技术建设层面进行分析，传统的单体架构（包含所有功能的应用程序，可以是JAR、WAR、EAR或其它归档格式包）在业务需求功能实现上呈现出一些弊端，例如复杂性高、扩展能力差、阻碍技术创新等。同时随着业务的发展、技术的更新、计算机硬件性能的不断提升，行业对核心业务系统的实现方式和数据服务质量上有了全新的要求，而原有的系统设计架构已不能完全满足业务发展的需要，这就迫使行业在系统建设上需要提供一套新的软件架构，能够解决传统单体架构无法解决的一些问题，例如扩展性、移植性、维护性、效率性等。

微服务架构的系统开发是将单体应用拆分成为一系列小型服务程序的过程，服务程序间可独立部署、可控制实现的复杂度、可采用不同的技术路线且扩展方便，每个服务只需关注一个具体业务功能的实现，例如核心系统中的保单查询微服务、理赔立案微服务等，过程实现相对简单。由于实现可采用不同的技术路线，每个微服务可由不同的技术团队进行独立开发部署。微服务是独立运行的，它区别与传统的单体架构有两大较为明显的优势：扩展性和隔离性。每个微服务程序可根据需求独立扩展，当系统需要频繁发布不同程序时，保证了其他系统功能模块的可用性，是系统持续交付的基础，是核心业务系统的不间断运行强有力的保障。扩展性允许我们快速地添加集群服务，提升系统综合服务能力，而传统的单体架构如需满足这些，往往需要在软件及硬件上进行重新架构。隔离性将微服务程序分隔为一个个独立运行的单元，系统运行时，某一单元自身的崩溃或失败往往只影响自己或部分其他微服务程序，但不会造成系统整体的崩溃，在系统运维人员根据服务定位和解决问题的过程中，保证了系统其他功能的正常使用，有效的解决了系统“一崩全崩”的情况，大大地增加了系统的可用性及可靠性。

图1    单体架构结构图

图2    微服务架构结构图

一、架构创新

微服务架构的创新可从框架提供的部分组件上进行分析。微服务架构的开发框架很多，例如Dubbo、Motan等，而Spring Cloud是目前使用较多，资源相对丰富的开发框架之一，本文将以Spring Cloud框架应用于核心业务系统进行架构创新上的探讨。Spring Cloud是采用Spring Boot技术实现的云应用开发框架，Spring boot专注于快速、方便地集成个体应用服务，而Spring Cloud则是关注全局的服务治理框架。它将复杂的配置进行屏蔽，提供了一套易于部署和维护的组件工具包，例如Eureka（服务发现）、Zuul（服务网关）等，并可快速对接云平台资源。下图3为核心业务系统基于Spring Cloud框架的技术实现。

1.1服务注册与发现

以SpringClound中的Eureka注册中心为例，服务注册即微服务程序将服务信息注册至Eureka中心，服务信息主要包括微服务程序所在服务器主机的IP地址、服务端口号、访问协议及服务状态等，各个实例通过注册中心获取依赖服务，该方式与单体架构中通过IP地址访问服务的方式有很大的区别。服务发现即实例在注册中心中可得到其他服务实例并请求提供对应的服务。对于核心业务系统而言，我们可将承保、理赔、再保等微服务程序注册至服务注册中心，为保证各个微服务程序（功能模块）具备高可用性及灵活性，注册中心自带的心跳检测、健康監控排查等技术为其实现提供了技术保障。在整个注册中心中，由于微服务程序自身的一些问题，服务状态都是动态变化的，如何处理一些无效的微服务实例是需要思考的问题，而在Eureka中，实例与其通过心跳的方式保持联系，一旦发现心跳缺失，Eureka会主动将其从现有环境进行删除，保障了整个注册中心所有服务的可用性。这种服务注册与发现的软件架构设计模式是信息技术上的一次革新，它解决了诸如服务接口IP地址发生变化而导致其他应用无法调用等一系列原本需要花较大代价才能解决的问题。

1.2服务网关

服务网关的作用在微服务架构中主要体现在实现动态路由，监控，弹性以及安全性。它可以帮助我们实现以下一些功能：（1）网关的核心之一是过滤器，身份认证与安全可通过过滤器进行识别，同时可拒绝所有不满足的请求。（2）监控和审查边缘有意义的数据并对其进行跟踪和统计，从而形成各类精确的视图。（3）将各类服务请求动态的路由至微服务集群，保障了服务间的调用性能。（4）分配相应容量至各种类型的请求，当超出容量限制时，自动限制其请求。（5）建立静态响应处理机制，在边缘位置处直接生成部分响应，避免其转发至内部集群。而应用于系统的架构中，其一网关可以用来做接口聚合，可将多个请求结果进行合并并将其返回，这样外部只需要调用指定的接口就可以得到业务数据，大大降低了程序调用间的复杂性。其二通过网关可以标识当前访问者的身份和部分权限，较为合理的解耦大部分重复代码，而且系统中如果存在具体复杂的权限需求可以在应用中再次通过身份标识来获取权限。在Spring Cloud框架中，一般采用Zuul组件来实现服务网关，将Zuul作为从设备及UI到系统服务后端所有请求的前门。

1.3服务监控与保护

单体架构属于单块应用的结构，而微服务是多服务多应用的结构。在单体架构中，要掌握单块应用的运行情况，因其只会发生单一的故障点，要追踪问题的发生和修订问题相对来说比较容易和解决。而在微服务的结构中，由于其运行个体多、部署方式多样，问题点往往会出现在不同的地方，而且服务产生的日志非常多，因此要从大量且相互隔离的日志中找到问题所在就会变得非常困难，对于多服务的监控，获取服务的状态相对更加复杂。系统微服务之间一般通过REST API的方式进行相互调用，为了快速定位系统的问题所在，服务监控显得尤为重要，一般来说可以从硬件层面、网络层面、系统层面、应用层面、服务访问层面进行监控，从这些层面采集相应的状态数据，然后进行汇总、存储、并分析，一旦某项指标超出规定的阈值，则通过监控进行报警，在接收到报警通知之后做出及时应对以改变目前系统状态不健康的局面。架构中一般可以通过预置的调控开关来调整应用的状态，要么重启服务或者进行服务降级。例如在Spring Cloud微服务架构中，可采用Hystrix Turbine聚合监控等监控组件来达到监控服务正常运行的目的。另外，如果要对Spring Cloud中的微服务进行完备的监控，架构可以从内部以“白盒”的形式进行监控，也可以以外部服务访问者的视角来对微服务进行模拟访问（即“黑盒”的形式），从而内外兼修地构建一套针对微服务的应用监控体系，达到保护系统正常运行的目的。

二、架构面临的问题

随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型团队自治化、大型系统集群化等实践流行的背景下，微服务架构在软件架构设计中带来了一些传统单体架构无法实现的新技术，引领软件开发行业技术的新方向。但微服务架构在解决了该解决问题的同时，又带来了新的一些技术问题，例如服务间通信变得比单体架构复杂，系统运维的成本大幅提升，服务“微”化之后，服务的数量大大增加了。微服务程序间的操作一般是以API的方式进行相互间的调用，该方式在数据的传输时长和访问时间上相对单体架构要增加不少，而且调用方式更加复杂，对结构之间的调用效率存在不少问题，如何解决采用该架构带来的问题是在系统架构选型时需要慎重考虑的。目前，微服务架构需要关注的问题主要围绕以下几个方面：（1）微服务运行的可靠性：微服务间采用了远程调用的机制，如遇到网络问题或者其中的一个服务节点出现故障，会导致服务间调用失败，当微服务数量越来越多时，故障点也随之增加，为使系统稳定运行，就需要有一个较为充分的保障机制，否则，系统的可靠性就无法保证。（2）分布式的复杂性：微服务支持分布式部署，各服务间的调用存在网络延迟等问题，这些问题对系统部分功能来说往往是致命的，是需要提供解决方案的。（3）架构运维成本高：微服务架构是一个全新的架构，需要技术人员具备较高的知识储备，需深入了解微服务中注册与发现、网关、监控、负载均衡、自动化集成部署等一系列技术，提高了系统运维的成本。（4）性能方面的考虑：由于服务间采用了跨网络、基于进程的调用方式，性能部分依赖外部条件，例如网络带宽、服务器硬件等，造成微服务架构较单体架构存在一定的影响。（5）数据的同步问题：分布式事务管理在微服务架构中需要经过多个节点来保障数据的同步，技术实现相对单体架构要复杂很多，成本也会增加很多。

保险行业的核心业务系统与传统的软件应用系统在技术架构上存在许多共同之处，但在系统安全性、稳定性、数据一致性、系统持续性、可维护性等方面有着更高的要求，如何让微服务架构应用于保险行业的核心业务系统，架构自身存在的一些问题是需要去思考和解决的。

三、结束语

基于当前科技及互联网经济高速发展的时代背景下，计算机信息技术已深入广泛的应用于各行各业中，如何让新的信息技术更好地、及时地应用于传统行业，是我们一直需要研究和探讨的课题。而随着中国保险业务的兴起和迅猛发展，为了不断适应现代保险工作的需求，保险公司对于现代化核心业务系统的需求越来越迫切。保险公司必须借助先进的信息IT技术构建一套规范及健全的保险管理体系，从而提高保险公司的管理效率，降低公司运维的成本。保险行业核心业务系统是属于保险管理体系的其中一类系统，由于保险公司本身受到国家银保监会的监管，因此对核心业务建设的各项要求相比传统的应用软件系统更高。保险行业所在的公司在开发一套成熟的核心业务系统后，由于其复杂性，一般不会轻易地对系统进行技术架构上的更新。但信息技术的发展日新月异，早期的技术架构或已满足不了现代系统建设的要求。因此，如何让一套新的技術架构更新应用于原有行业系统的开发而又不带来新的风险是值得我们去权衡与探讨的。

参  考  文  献

[1] https：//spring.io/projects/spring-cloud.

[2] 方志朋. 深入理解Spring Cloud与微服务构建第2版 2020.3

[3] Sam Newman.微服务设计 2016.5