一种基于微服务架构的业务系统设计与实现

洪华军 吴建波 冷文浩

（中国船舶科学研究中心软件工程技术中心 无锡 214082）

1 引言

随着企业信息化的发展，应用系统的数量、规模和复杂度不断增长，应用实现越来越复杂，代码规模越来越大，系统变得更加笨重和庞大，导致应用难以维护和更新。原有的单一应用架构，由于逻辑过于耦合已无法应对；垂直应用架构，由于应用之间交互越来越多，越来越复杂已不再适应；分布式服务架构，由于服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现。

针对当前企业信息化的现状，对系统的开发和部署提出了新的挑战，对企业应用架构的高效性和扩展性提出了更高的要求［1］。微服务架构的出现，有效解决了当前企业信息化面临的一系列问题。可以通过微服务架构将复杂应用进行服务化切分，把一个大而复杂的问题化解为多个小而简单的问题，使用一套小服务来开发单个应用，实现微小服务功能。服务之间以轻量级通信的协调机制，以业务为中心，通过契约来约定依赖，构建起独立的自动化运行机制，以实现集中式服务管理［2］。

2 微服务原理

2.1 微服务架构定义

微服务［3］是一些协同工作的小而自治的服务。它具有高内聚性和高自治性。微服务根据业务的边界来确定服务的边界。同时，它也是一个独立的实体，可以独立地部署在PaaS上，也可以作为一个操作系统进程存在。服务之间均通过网络调用进行通信，从而加强服务之间的隔离性，避免紧耦合［3］。

微服务架构是一种架构模式，它将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建［4］。

2.2 微服务架构优势

微服务架构模式有众多优势［4～5］。

1）组件化

微服务可以被认为是一种组件。它与传统组件方式最大的区别是，传统组件将应用模块化并为其构建相对独立的单元。隔离独立的部分或抽取公用的部分，构建共享库，达到解耦和复用的效果。而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务。

2）独立部署

由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用，大大缩短应用交付周期。微服务架构模式使得持续化部署成为可能。

3）降低复杂度

微服务架构通过分解单体式应用为多个服务方法，让复杂性可控，避免不必要的数据孤岛。在功能不变的情况下，应用被分解为多个可管理的服务，通过微服务架构模式，让复杂的功能，通过模块化的方式呈现，给采用单体应用编码方式难以实现的功能提供模块化的解决方案，让单个服务更容易开发和维护。

4）技术多元化

传统的开发模式一般是使用同类技术构建整个应用。微服务架构强调的是去中心化的软件组织架构，使每个服务根据自身服务的需求和行业发展状况做出自己的判断，选择适合的技术类型，提供接口服务。

5）降低维护风险

维护庞大且复杂的单块架构系统，工作量很大，容易出现牵一发动全身，风险很高。相较而言，微服务架构模式下，当某一组件发生故障时，不会发现单块架构系统的进程内扩散等弊端，故障会被隔离在单个服务中，从而降低维护和再开发的风险。

2.3 微服务架构不足及应对措施［6～7］

1）微服务边界

应用微服务过程中，容易出现无法很好地界定模块之间的界限，造成微服务过大或者过小。微服务过大，会出现同单块架构系统类似的不足，微服务过小，管理大量的服务也很复杂。

如何确定边界？采用业务领域模型驱动数据模型设计方法，建立并完善整套业务领域模型，包含上下文中关于边界的各项定义。这些明确的边界将是微服务的边界，或是微服务边界内组件。

2）分布式应用的复杂性

分布式应用相比单体式应用，具有固有的复杂性。需要在RPC或者消息传递之间选择并完成进程间的通讯。更需要处理消息传递中速度过慢或者不可用等局部失效问题。

充分考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等对微服务的影响，采用一整套完整的机制来保证各个服务可以正常运转。

3）分区的数据库架构

在微服务架构应用中，一个微服务对应一个数据库，需要更新不同服务所对应的不同数据库。才能够时刻确保分布式数据系统当中不同形式数据的一致性与并发性。

根据CAP定理，分布式系统中有三方面需要彼此权衡：C（一致性）、A（可用性）和P（分区容忍性），最多只能保证三个中的两个。做为一个系统整体，不需要全部是AP或者CP。如目录服务可以是AP，因为不关注历史信息，但是数据台帐信息一般需要CP，因为不能让用户看到修改前的记录信息。因此需要为每个服务调用做不同的权衡，来解决微服务架构应用中分布式数据问题。

4）部署复杂

相比于单体式应用，一个微服务应用一般由大批服务构成，且是多实例化的。这需要整个应用有众多的配置、部署、扩展和监控功能。

通过使用PaaS服务实现部署自动化，PaaS提供一个部署和管理微服务的简单方法，它把所有这些问题都打包内置。并使用一个集群化方案，比如配合Docker容器技术使用Mesos，在微服务层面提供缓存、权限控制、API统计和监控。

3 基于微服务架构的设计

针对当前开发和维护的综合业务管理系统应用过程中出现的单体结构应用无法解决的问题，对其核心架构进行设计。

综合业务管理系统是一种两级业务系统，分为一个集团级系统和20个所级系统，每个系统包含合同管理子系统，计划管理子系统，项目管理子系统，财务管理子系统，成果管理子系统，质量管理子系统，器材管理子系统等20个子系统。从职能上讲，集团级系统对所级系统有计划下发，项目监管，财务预算等宏观总体上的把控，每个所级系统更关注对计划执行，项目执行，财务结算，质量过程管理等具体执行过程进行管理。集团级和所级系统既有共性，又有区别。不同的所级系统由于独立运作，组织结构和具体执行情况也有所区别。

3.1 微服务划分

根据当前系统建设的实际情况，将微服务分为共享微服务和定制微服务。共享微服务又分为基础平台共享微服务和业务共享微服务，都提供集团级、所级系统相同的微服务。定制微服务是对共享微服务无法满足单位实际业务需求的情况下的扩展。表1列出系统部分微服务。

表1 微服务列表

各微服务都定义成独立的服务接口，相比于原来单体结构的难以维护的情况，新的系统由实现不同功能的微服务组成，每个微服务只关注单一的业务功能。

3.2 微服务框架的选择

通过对主流开源微服务框架的比对，和现有系统的实际情况：使用Spring作为容器框架、SpringMVC作为模型控制器框架。故选择Spring Cloud作为本系统的微服务应用框架，它能够与当前系统无缝集成。

Spring Cloud［8］是一套完整的分布式系统解决方案，从网关服务Zuul，到服务发现Eureka，再到Hystrix熔断机制，它的子项目涵盖所有实现分布式系统所需要的基础软件设施。基于Spring Boot，使得开发部署变为简单，通过加依赖和注解，就能运行。

3.3 微服务应用总体架构设计

微服务应用总体架构［6，9］如图1所示。

图1 微服务应用总体架构图

由Spring Cloud组件和构建的微服务组成。通过Zuul实现服务网关，统一向外系统提供REST API；Ribbon实现服务的消费以及均衡负载；Eureka实现服务注册中心以及服务注册与发现；Spring Cloud Config实现应用多环境的外部化配置以及版本管理；Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

定制微服务、业务共享微服务、基础平台共享微服务都注册与订阅微服务到Eureka，并通过均衡负载向外提供微服务调用。各微服务都有对应的独立业务数据子库。

3.4 系统功能结构设计

提供一套完整的平台，由基础平台、业务共享微服务共同构成，供集团、所两级使用。集团总部将一套完整平台派发到20个所级单位。各所级单位根据自身的实际业务情况，对完整平台的子系统进行选配，构成本单位的综合管理业务系统。当实际业务与完整平台不一致的情况，通过业务定制微服务的方式，进行个性化定制开发，满足各单位的实际需要。系统功能结构图，如下图2所示。

图2 系统功能结构图

4 基于微服务架构的程序实现

4.1 创建spring cloud配置服务器

1）配置依赖 pom.xml［10］

4.2 微服务注册

使用eureka作为Spring cloud的微服务注册及发现。所有的服务端及访问微服务的客户端都需要连接到eureka。通过创建ywgl-eureka-server作为eureka的服务端，提供注册服务［11］。

4.3 微服务发现和微服务应用

通过添加@EnableDiscoveryClient注解，微服务在启动时，将自动注册到ywgl-eureka-server注册中心［13］。

5）前端html页面

前端html页面，使用AngularJS，绑定模型数据到页面变量［12］。planList.html核心代码展示如下：

3）4）5）展示了计划管理中获取计划列表的微服务程序实现，其他微服务按此方式进行创建。

5 结语

实现了一种基于微服务框架的业务系统设计和实现。微服务具有高内聚性和高自治性。并有组件化、独立部署、降低复杂度、技术多元化、降低维护风险等优势。特别适合既有共性，又有区别的集团、所两级的复杂业务系统的建设。为企业信息化建设过程中遇到的问题提出了一种解决途径。