论微服务架构及其应用

论微服务架构及其应用

摘要

       2019年11月，我所在的软件公司承接了某保险集团下健康险服务实施管理系统的开发工作，本人有幸参与该项目，并担任系统架构师职务，主要负责软件架构设计和安全体系设计的工作。该项目是基于集团内网，为全国各省市地区分支机构的健康险专员提供7*24小时的不间断服务。本文结合作者的实践，以健康险服务实施管理系统为例，论述微服务架构及其应用。首先概述我参与管理和设计，并采用微服务架构开发的主要工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，介绍该系统是如何采用微服务架构模式，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。经过项目组9个多月的努力，本系统已顺利开发完成，于2020年7月投入生产环境使用。自上线以来未出现重大故障，取得客户和公司领导的一致好评。

正文

       近年来，随着互联网行业的迅猛发展，公司业务的不断扩张，需求的快速变化以及用户量的持续增加，传统的单块（Monolithic）软件架构面临着越来越大的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式(Microservice Architecture Pattern)逐渐流行。它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用HTTP等通信协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。

       2019年11月，我所在的公司承接了某保险集团下健康险服务实施管理系统的开发工作，本人有幸参与该项目，并担任系统架构师职务，主要负责软件架构和安全体系设计的工作。本文结合作者的实践，以健康险服务实施管理系统为例，论述微服务架构及其应用。首先概述我参与管理和设计，并采用微服务架构开发的主要工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，介绍该系统是如何采用微服务架构模式，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。

项目概述

       随着信息技术的蓬勃发展，保险行业使用传统的业务系统已无法满足日益增长的业务量，为集团中众多的健康险专员开发一个稳定、高效、便捷的线上办公的信息系统迫在眉睫。健康服务实施管理系统（Health Service Implementation Management System HSIMS），为企业健康险工作人员提供实时、高效、方便的线上办公服务，如此便利的2B业务系统间接的为健康险消费群体提供了更快更好的产品使用体验。HSIMS系统的建设，充分表现了健康险产品的整个生命周期，系统划分为产品管理、服务管理、协议管理、健康卡管理、供应商管理、服务实施管理、服务反馈管理等多个业务模块。在实际使用时，由健康险专员全程操作，根据岗位职能的不同各自负责不同的业务模块，从而达到高效稳健的业务协作，促进企业的进一步发展。限于篇幅，在此我们不再详细介绍各个模块的具体功能。

       微服务的目的是充分地分解应用程序以促进敏捷开发和部署。在HSIMS系统的开发和管理中，我们按照功能需求将系统划分为4个微服务，分别是：产品管理、协议管理、供应商管理和服务实施管理，同时将项目组团队划分为三个小组，根据功能的轻重缓急和工作量，安排各个微服务的研发。每个小组负责一个或多个组件完整的生命周期，最后各个服务组件通过HTTP协议和消息路由功能进行服务组装。

微服务架构的特点

       传统的单块软件架构在构建部署和扩展伸缩方面有很大的局限性，一般分为客户端用户界面、数据库、服务端应用程序三部分。系统中任何程序的改变都需要整个应用重新构建和部署新版本。另外，传统的单块软件架构在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。而微服务架构可以完美的解决统一风格架构所遇到的种种问题。微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立，单一功能的改变只需要重新构建部署相应的服务即可。与单块架构相比，微服务架构有如下的特点：

1) 通过服务实现应用的组件化(Componentization Via Services)，在应用架构设计中，通过将整体应用切分成可独立部署及升级的微服务方式，进行组件化设计。 

2) 围绕业务能力组织服务(Organized Around Business Capabilities)，微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大。 

3) 基础设施自动化(InfrastructureAutomation)，云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。 

4) 故障处理设计(Design For Failure)，微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此微服务非常重视建立架构及业务相关指标的实时监控和日志机制。 

5) 演进式的设计(EvolutionaryDesign)，微服务应用更注重快速更新，因此系统的计划会随时间不断变化及演进。

微服务架构应用

        HSIMS系统采用微服务架构、前后端分离、技术与业务分离、业务按功能分离的思想进行建设。同时，多个微服务共同组成一个应用程序。每个微服务都可独立部署、升级、扩展和替换，有利于持续集成和持续交付，提供横向扩展的能力。

整个系统基于SpringCloud + SpringBoot实现，主要核心组件如下：

Eureka服务注册与发现：服务之间需要创建一种服务发现机制，用于帮助服务之间互相感知彼此的存在。服务启动时会将自身的服务信息注册到注册中心，并订阅自己需要消费的服务。

Apollo配置中心：全局统一配置，提供配置文件统一管理的能力，实现各微服务的统一参数配置以及版本管理。

Ribbon客户端负载均衡：系统不再采用一般的增加负载均衡服务器的方式进行负载均衡，如F5、Nginx、LVS等，而是把负载均衡的功能以库的方式集成到服务消费方的进程内，这种方案称为软负载均衡（Soft Load Balancing）或者客户端负载均衡。

Zipkin链路跟踪：提供服务调用和数据库调用的链路跟踪，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样，从而达到每个请求的步骤清晰可见，出现问题时可以很快定位问题点。

Hystrix熔断管理组件：当请求有阻塞情况，多次调用无返回时会进行熔断处理。

遇到的问题及解决方案 

       在微服务实践中，我们主要遇到三个问题，一运维开销及成本增加，因为每个微服务需独立运行，还可能采用多种语言环境，这将导致资源开销大；二部分代码重复，某些底层功能需要被多个服务所用；第三个问题是难以可视化及全面测试，在动态环境下服务间的交互会产生非常微妙的行为。因此，首先服务划分应尽量合理，不要划分太细太多，其次采用公共模块的方式提供底层服务，最后微服务可通过可视化监控组件发现生产环境的异常，进而快速回滚，弥补可测性不足的问题。 

       通过项目实践证明，实施微服务架构收益会大于成本。在拥抱微服务之前，也需要认清它所带来的挑战。需要避免为了“微服务”而“微服务”。对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则，对已有系统进行改造或新建微服务应用，逐步探索积累微服务架构经验，而非冒险激进全盘实施微服务架构。