基于微服务架构的一体化科研管理平台设计与实现

赵 军，陈子晗，高子航

(1.中国电子科技集团公司第五十四研究所，河北 石家庄 050081；2.中国科学技术大学 数学科学学院，安徽 合肥 230026；3.华中科技大学，湖北 武汉 430074)

0 引言

目前企业采用SOA架构开发的应用系统，如合同、项目、物资、质量和售后等，均为传统单体架构模式构建，即每个系统的所有功能均为一个独立应用，系统是最小的交付和部署单元[1]。系统间信息的传递与共享采用企业服务总线(ESB)实现，系统中业务流程的改变、功能的拓展，均需对原系统及接口进行程序改造并部署[1]。随着企业应用系统数量、规模和复杂度的不断增长，传统开发模式在系统的开发、拓展、部署和维护等方面均面临新的挑战。

近几年，国内外越来越多的企业将系统从传统单体架构迁移到MSA，如国外的Netflix，Amazon，eBay，IBM Bluemix等，国内也有许多成功的实践案例，如阿里巴巴开源的MSA Dubbo、京东的MSA JSF等[1]。目前，基于MSA构建系统应用已成为一种新选择[2]。

前Netflix首席架构师Adrian Cockroft将微服务定义为细粒度的SOA[2]，核心是将传统单体架构应用划分成多个独立服务，服务之间采用轻量级通信进行相互协作和调用。该架构具有快速开发、部署独立、故障隔离以及技术多元化等特点，能缩短开发周期、快速交付应用[2]。

文献[1-8]给出了应用架构的演变过程，各应用架构的优缺点、MSA的定义及实现原理，文献[2-15]给出了MSA的优缺点及应用实践，文献[5-20]给出了MSA设计及编码实现方式。

本文在一体化科研管理平台的设计与实现中，对应用架构进行了对比、分析、研究，给出了采用MSA改造合同管理系统、项目管理系统的应用实践。

1 微服务原理

1.1 MSA

微服务是近几年出现的用于处理复杂应用的系统架构方法论，是SOA思想的一种实现，其核心理念在于，将复杂应用进行服务化切分，即把单一应用系统以独立业务单元的形式拆分为多个服务，每个服务可选择适合的技术实现特定业务功能，并以独立的进程部署、运行。服务之间功能边界清晰，采用REST/JSON等轻量级的通信机制相互沟通，相互配合实现完整应用[2]。

该架构旨在通过将功能分解到多个自治单元服务中以实现对复杂应用的快速开发，其本质是由一组可独立交付的微服务业务单元构成的分布式系统[2]。

1.2 微服务架构特点

主要特点如下[3]：

① 复杂度可控：微服务将复杂的应用系统按业务功能分解为功能单一、易于管理的多个服务，系统的复杂度取决于服务的划分；

② 架构灵活：对大型复杂应用，可将多个微服务采用负载均衡的分布式架构部署，最大程度地满足用户性能要求；

③ 技术多元化：每个微服务可根据业务功能特点及行业发展趋势选择适合的技术开发，使服务的开发和维护便捷、高效；

④ 功能易扩展：每个微服务功能单一，可独立扩展、变更服务下的业务功能，而不影响其他微服务；

⑤ 独立自治：每个微服务可独立封装业务逻辑，以独立进程运行，故可单独开发、测试、部署和维护。

1.3 MSA与SOA对比

SOA是一种粗粒度、松耦合的服务架构[1]，应用核心是业务逻辑，以服务封装业务流程，采用中间件集中式总线，即ESB对每个业务流程实施控制、跟踪、改进，并进行跨平台的多应用系统间集成，ESB具有数据转换、负载均衡、服务管理和服务监控等诸多功能，有效解决了应用系统的异构和复用问题，但其结构复杂，开发周期长，系统升级维护成本高，不利于业务功能的扩展和流程的变更[2]。

相比之下，MSA采用细粒度的服务，没有结构复杂的ESB，它将大型、复杂的应用构建为一组相互配合的服务，每个服务业务单一、功能明确，服务间采用轻量级通信进行接口调用，服务开发测试与部署相互独立，使系统具有良好的扩展性[5]。

SOA更倾向于是一种体系和指导思想，不是具体的实现方法。而MSA本质上可以说是面向服务应用级别的实现方式。

MSA与SOA在许多方面不同，主要区别如表1所示。

表1 SOA与MSA比较

指标SOAMSA 适用系统静态、企业级大型应用快速迭代、快速交付应用服务粒度服务粒度大、功能较多 服务粒度细、功能单一架构模式集中式架构分布式架构通信机制SOAP,ESB等服务总线,重量级基于HTTP的RESTful、轻量级实现方式J2EE/EJB/WebServiceDocker/RESTful部署方式统一的平台独立进程、可不同平台

2 系统设计与实现

2.1 业务现状与问题

企业在科研管理领域已建成了合同、项目等系统，对合同收付款、项目执行等相关业务过程进行了有效管理，但系统建设之初，均基于某一业务部门内部的管理需求，随着应用的深入，现有的系统在运行中暴露出以下问题：

① 仅对合同的基本信息及收付款情况进行登记，全流程、系统化的业务梳理不够，相关部门需求覆盖不全，缺乏有效的合同管控手段及风险预警能力；

② 收款业务与项目系统存在业务交叉、合同信息多源头录入等问题，致使合同信息不准确；

③ 收款计划与项目执行计划缺乏关联，使合同收款节点状态不能准确掌控；

④ 付款计划与采购业务缺乏一体化管控手段，依靠人工跟踪，工作量大、效率低下，准确性差；

⑤ 合同管理与财务支付缺乏有效集成，无法获取合同的结算信息；

⑥ 收款、付款毫无关联，无法做到准确的资金预测，导致合同履约过程中难以进行统一监督、跟踪；

⑦ 缺乏往来单位收款付款全过程数据的统一管理，无法满足各级领导对合同多维分析需要。

为解决上述问题，满足企业不断发展的业务需要及当前形势对科研管理精细化的要求，迫切需要利用先进信息技术手段，对现有合同、项目系统进行功能扩展和改造，实现合同收付款计划与业务执行的一体化管控，促进信息系统业务的连续性。

2.2 系统实现原理

一体化科研管理平台，涉及合同、项目、采购、质量和财务等多个业务领域，实现原理如图1所示，其核心思想是打破现有多个业务系统间的界限，重构系统功能，将目前各领域的业务系统进行补充、分解、重构成独立的业务功能模块，进一步构建一体化科研业务模型，以向用户提供连续的跨领域的管理平台，促进信息系统之间业务流程的连续性；使用户对同一事项或任务的处理无需在不同系统或领域模块间切换。

具体方式为：将企业现有合同管理、项目管理、采购管理、质量管理、财务管理和成本管理等多个单体应用系统的业务功能、流程进行梳理，补充、分解、重构现有功能，依据业务功能及业务之间的关联关系程度构建一体化科研业务模型，如合同信息管理、合同收款管理、项目立项管理等多个功能模块，采用MSA，将每个功能模块微服务化，如合同服务、项目服务和采购服务等，从而为使用人员提供良好的用户体验。

图1 一体化科研管理平台工作原理

2.3 总体架构设计

一体化科研管理平台采用多层架构进行设计，如图2所示，分别为应用层、服务层、数据层、监控层和安全层。其中，应用层“以用户为中心”，为用户提供个性化功能服务，主要关注用户体验与业务功能；服务层是MSA的核心，采用服务化方式，通过“去中心化”的服务组合调用与重组来满足不同用户的功能需求；监控层、安全层对整个系统进行统一的运维和安全管理。

图2 一体化科研管理平台总体架构设计

API服务网关：一体化科研管理平台的统一访问入口，具有负载均衡、服务路由和请求过滤等功能，它对一体化科研管理平台内部的所有服务进行了封装，对外部公共的API与内部服务进行了隔离，有效保障了平台的安全性。

服务层：依据服务的作用又分为基础平台微服务、业务共享微服务和定制微服务。基础平台微服务如元数据管理微服务、工作流引擎微服务等为其他业务服务提供技术支撑；共享业务微服务对共性业务服务进行抽取，为其他业务提供服务；定制微服务实现特定领域功能。

数据层：通过数据总线为服务层应用提供数据访问接口。

2.4 微服务设计

基于MSA的一体化科研管理平台依据服务的性质和作用将服务分为3大类：基础平台微服务、业务共享微服务和业务定制微服务，每类下又包含若干微服务，如表2所示。其中，与业务相关的微服务划分一方面依据业务功能特点及业务之间的关系，另一方面跟开发所需技术相关，同一业务实现技术不同将被划分为不同的服务。

在一体化科研管理平台的合同系统、项目系统的微服务改造中，将项目任命、项目计划等作为业务共享微服务，为合同信息管理、合同收款计划提供服务；而将只与自身业务相关的功能，如合同信息管理作为业务定制微服务。

表2 一体化科研管理平台微服务列表

服务类型微服务名称基础平台微服务元数据管理微服务工作流引擎微服务报表工具微服务备份管理微服务权限管理微服务业务共享微服务项目立项微服务项目任命微服务项目计划微服务项目监控微服务业务定制微服务合同信息管理微服务合同收款管理微服务收款任务管理微服务拨款管理微服务项目变更微服务……

2.5 系统开发实现技术

一体化科研管理平台开发采用以下关键技术：

① 基于Spring Boot技术：采用Spring Cloud为本系统的微服务技术应用框架。具体技术是使用Eureka作为服务的注册与发现中心，使用Ribbon实现客户端负载均衡，使用Zuul实现智能网关、动态路由，对外提供RESR API，使用Hystrix服务断路器进行服务保护等，Spring Cloudk框架既考虑Web应用，也考虑今后手机APP应用。

② 服务调用：采用基于AMQP协议的开源消息中间件RabbitMQ进行服务间的异步调用，降低服务间的耦合度。

③ 服务监控：使用Zipkin进行服务链路的调用监控，利用Kibana对运维数据进行分析并提供可视化展示。

④ 安全防护：采用基于云平台的安全措施进行安全防护。

⑤ 服务部署：采用Docker虚拟化技术进行自动化部署。

微服务开发主要步骤如下：

① 创建Spring Cloud 配置服务器：首先创建项目，激活配置服务器，配置访问路径，然后对该项目下的所有服务实施配置管理。

② 微服务注册：使用Eureka作为客户端的连接组件，作为注册中心，为微服务提供注册服务。

③ 微服务发现与应用：通过添加@EnableDicoveryClient注解，使微服务启动时能自动注册至注册中心。

④ 配置断路器：使微服务启动后依赖于注册中心，对微服务实施保护。

⑤ 配置前端HTML页面：使用AngularJS技术，将业务数据模型绑定到页面变量，为用户提供Web页面访问。

⑥ 微服务测试。

⑦ 微服务部署运行。

3 应用结果与分析

通过将MSA应用于一体化科研管理平台的合同系统、项目系统改造中，将大而复杂的一体化科研管控问题分解为相对独立的合同管理、项目管理等问题，使用一组小服务来开发单个复杂应用，在企业的实际应用中效果良好，达到预期目标，开发周期由原先预计的6个月，缩短为4.5个月，开发效率提高25%。实践证明，采用MSA，在业务需求渐清晰的情况下，可实现业务功能快速迭代及敏捷开发。传统开发方式与采用微服务架构开发方式的比较如表3所示。

表3 2种开发方式开发周期对比 天

4 结束语

针对企业目前收款合同与项目执行的业务现状，在一体化科研管理平台的设计与实现中，引入了MSA，通过对传统单体架构的合同管理系统与项目管理系统实施微服务改造，实现了收款合同、项目执行的微服务化，促进了信息系统业务流程的连续性，满足了企业收款计划与项目执行计划一体化管控需要。目前，系统已上线运行，实践证明，采用微服务改造后，可快速应对企业组织及管理变化带来的业务调整及需求变化，提高了一体化科研管理平台的适用性和扩展性，对后续其他系统的功能扩展以及重构提供了重要的指导意义。

微服务平台建设是个不断迭代完善的过程，在后续系统建设中，一方面要优化和补充基础平台微服务功能，如完善调用服务，除监控服务运行状态外，还要对服务的安全性、日志和流量控制等方面进行管理，以确保服务的高可靠性；另一方面，要结合业务需求不断抽取、沉淀共享业务微服务，使之为更多的定制业务提供服务。另外，随着后续一体化科研管理平台中质量、采购等系统的不断改造，微服务数量会逐渐增加，服务的运维工作会变得十分繁重，还要考虑采取轻量级Docker容器技术进行自动化部署。