基于微服务架构的数字校园平台改造及持续集成*

邹伟

(云南师范大学，云南 昆明 650500)

1 引 言

国内高校信息化建设和发展主要经历了四个阶段.第一阶段是从20世纪90年代开始的校园网络建设，这一阶段以网络基础硬件设施和互联互通校园网络环境建设为重点.第二阶段是2000年左右，随着互联网和信息技术的发展，逐步建设协同办公系统、教务系统和财务系统等核心应用系统，初步构建了教学、科研和管理等方面的信息化模式.第三阶段是2010年左右，面对高校信息化建设过程中出现的数据孤岛问题，逐步开始构建以统一身份认证、统一数据中心和统一门户系统为核心的数字化校园平台.第四个阶段是2015年以后，以人工智能、大数据、云计算、智慧教室和VR虚拟仿真等技术构建智慧校园，实现教学和管理的智能化.智慧校园建设目前正处在探索阶段，数字校园建设仍然是重点，高校正逐步开始在数字校园基础上进行改造和持续集成，并基于教育大数据开展数据治理、数据服务和数据分析，充分释放教育大数据的价值.

对云南省20余所高校信息化建设现状进行了深入调研，这些高校目前开展数字校园应用集成主要通过两种方式：一种是利用ODI将应用系统基础数据抽取到中心数据库形成共享数据库架构；另一种是基于SOA架构将一个业务系统拆分成若干个粗粒度的服务，利用Web Service技术实现数据服务标准的统一，通过ESB企业服务总线实现服务间数据的相互调用，从而实现校园应用的集成.总体来看，经过多年的建设，高校业务系统不断完善，信息化应用水平和管理效率不断提升.但客观分析，还依然存在应用系统分散、管理复杂度高、决策分析困难和信息孤岛等问题.目前高校各个业务板块都在持续推进信息化建设，不断有新的业务系统接入数字校园体系，这种模式使得数字校园建设系统越来越庞大，持续接入或者升级改造的业务系统使得高校信息化体系更加错综复杂，传统数字校园统一身份认证、统一数据中心和统一门户“三大基础平台”的建设思路并不能有效支撑学校不断扩展的IT架构.基于以上现状，提出一种基于微服务架构的数字校园平台改造和持续集成框架，对现有应用软件进行微服务的封装和发布，对新的业务系统通过基于数据、流程和消息等基础服务进行重构，实现在数据层、业务流层和展示层的整合和封装，呈现给用户自治且完整的统一服务模式,解决不同厂家、不同数据标准、不同数据格式的数据整合，为数字校园的持续发展奠定基础.

2 微服务架构

2.1 微服务的概念

微服务是在传统的单体架构无法适应快速变化的IT架构的背景下，在虚拟化技术与DevOps文化快速发展的基础上诞生的，其主要功能是将单体应用系统拆分成多个独立的微小型服务，这些微小型服务都在各自独立的进程中运行，服务之间通过RESTful API进行协作[1-2].每一个微小型服务都围绕着系统中的某一项或某一些耦合度较高的业务功能进行构建，并且每个微小型服务都维护着自身的数据存储、业务开发、自动化测试以及独立部署机制[3].

2.2 微服务架构的演进过程

应用软件的服务架构一直处于不断演进过程中.随着高校办学规模的不断扩大和信息化需求的快速变化，高校应用服务架构也需要作出相应的改进来支撑数字化校园建设转型.图1通过对比4种比较主流的架构模式，展示应用软件服务微服务架构的演进过程.

图1 微服务架构演进过程

MVC架构：当业务规模很小时，将所有功能都部署在同一个MVC架构的应用系统中，通过前置负载均衡器或者部署集群等方式来实现负载分流，提高系统性能.

RPC架构：当集群中的应用越来越多，应用之间交互不可避免，此时将一个大项目拆分成一个个单体结构项目，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离，项目之间的接口多具有数据同步功能.此时，用于提高业务复用及拆分的 RPC 框架是关键.

SOA架构：随着业务发展，服务数量越来越多，服务生命周期管控和运行状态的治理成为瓶颈，因此，基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各系统提供服务，各子系统与服务之间通过WebService和RPC等方式进行通信[4]，ESB企业服务总线作为项目与服务之间通信的桥梁.

微服务架构：随着敏捷开发和持续交付理论的发展和实践，以及基于 Docker 等轻量级容器部署应用和服务的成熟，微服务架构逐渐成为应用软件架构的发展方向.通过服务的原子化拆分，将系统服务层完全独立出来，并将服务层抽取为多个独立微服务，微服务之间采用RESTful等轻量协议传输数据[4].

3 基于微服务架构的数字校园平台改造及持续集成模式

为了让数字校园架构更加灵活，具备更强的应对业务需求变化的能力，需要对数字校园现有业务系统按照微服务模式进行改造，使数字校园能够在有效整合现有业务系统的基础上，支持新的业务系统持续集成.图2为数字校园微服务架构.

图2 数字校园微服务架构

数字校园微服务架构包含三个主要方面：

(1)来源系统.接入数字校园的来源系统分为三类：一是原有开放应用系统通过ESB数据总线模式实现数据的共享、集成和整合.二是原有封闭系统通过爬虫技术和虚拟登录技术进行数据的主动和被动抓取.三是新接入的系统通过基于数据、流程和消息等基础服务重构成各类微服务接入.另外，系统架构中负责系统监控、系统安全和系统运维模块也作为微服务接入.

(2)接入网关.改造后基于微服务的轻应用将会大量存在，而一个轻应用可能需要访问多个微服务才能实现相应功能.例如教师中心需要访问用户认证、工资、课程表、图书借阅信息、一卡通余额信息等微服务实例完成请求，不同的微服务接口都有一套访问控制体系和安全体系，随着微服务规模和轻应用规模不断扩大，在客户端调用多个服务接口会急剧增加客户端复杂性，访问高峰容易出现性能瓶颈[5].因此，在前端访问和微服务实例之间设计接入网关，用以实现路由请求转发、校验过滤及负载均衡等功能，所有的访问终端只需要与网关交互，由接入网关进行统一调度和过滤.

(3)自动化构建和部署.对数字校园应用系统进行微服务改造后，原本独立的业务系统被划分为多个微服务，为了降低微服务之间的耦合度，通过Docker容器对不同微服务环境进行隔离，让微服务能够运行在独立的环境中.随着高校信息化建设规模的不断扩大，微服务之间的依赖关系会日益复杂，子系统模块也逐渐增多，很容易导致系统之间出现冲突无法启动，因此通过提前配置代码仓库、设置微服务模块构建顺序和构建命令，建立代码仓库版本异动监听机制，实现微服务的自动化构建和自动化部署.

基于微服务的架构为校园业务提供了更为灵活开放的服务构建能力，数据层面、业务流程层面及集成展现层面都进行了整合和封装.将各部门应用系统中复杂的业务功能抽象成可重复利用的微服务，根据业务功能将各个微服务组织起来，然后在数字化校园建设的基础上进行集成开发[6-7].师生用户通过不同的访问终端(PC端、手机端、平板端和穿戴设备)等发起访问请求，访问请求经过网关安全策略进行访问过滤与拦截，通过访问认证模块进行访问权限和安全性验证，并将通过验证的访问转发到后端进行处理，各服务之间通过微服务架构的相关组件进行沟通协作.

4 实例分析

以云南师范大学为例，学校从2010年开始数字校园的建设，经过近10年的建设，构建了人事系统、协同办公系统、财务管理系统、教务管理系统、科研管理系统、图书馆管理系统、学生管理系统、研究生管理系统、招生迎新信息系统、离校系统、校友系统和资产管理系统等业务系统，初步实现了教师数据流、学生数据流和资产数据流的流转，构建了统一数据中心、统一认证平台、统一门户平台以及统一消息平台，学校信息化管理水平得到了提升.但是随着信息化建设的发展和学校业务需求的持续变化，现有数字校园建设模式在一定程度上制约了学校信息化发展水平.下面对如何通过微服务架构模式开展数字校园改造进行分析.

第一步：构建基础支撑设施.基于微服务的数字校园平台在开发、部署、测试、治理和运维过程中涉及的基础支撑设施包含基础硬件资源、数据治理平台、服务管控平台、接口管理平台和自动化部署平台等.基础硬件资源主要包含云平台、虚拟主机和存储资源等；数据治理平台主要从管理制度、数据标准和数据监控等方面提供支持；服务管控平台承担微服务的部署和运营管理等；接口管理平台负责提供对内对外的标准API服务；自动化部署平台主要进行微服务应用的管理，实现全面持续集成和持续交付等功能[6].

第二步：现有业务系统梳理.目前大部分业务系统数据库设计规范且接口规范，能够对外提供良好的数据服务.但是也存在少数业务系统在数据服务和接口方面不够完善，导致数据孤岛.针对学校业务系统的现状和数据源开放程度，可以将业务系统细分为四类：第一类是业务系统本身不提供数据接口服务，可以基于微服务模式进行集成开发；第二类是业务系统本身不提供数据接口服务，软件提供商不愿意配合进行数据接口开发，同时系统也短期无法被替代，可以通过爬虫技术和虚拟登录技术，主动或被动的方式爬取核心数据再进行数据接口开发；第三类是业务系统已经有基于SOAP协议的WebService服务，可以将其封装注册至微服务组件中；第四类是目前正计划接入的应用系统，要求其严格按照微服务模式提供数据和服务.

第三步：微服务改造.对数字校园通过微服务模式进行改造，首先需要对现有业务进行划分，基本的思路是进行业务拆分和业务分层.业务拆分分为横向拆分和纵向拆分，横向拆分是指根据不同的业务域进行拆分，形成独立的业务微服务群.纵向拆分是指将某一业务系统或者某一功能组件拆分成若干个微服务.业务分层是指将核心的公共服务进行抽取和整合，形成稳定的底层服务.在微服务的拆分粒度上，首先保证微服务具有业务的独立性与完整性，尽量减少服务依赖[8].因此，在改造之初，可以将微服务的粒度设计的相对较大，并根据业务的发展进行动态的拆分.改造过程可以细分为三个步骤：

(1)提取基础组件.通过对现有“三大基础平台”和业务系统进行分析，首先提取每个应用系统都需要的基础公共组件.通过业务分层思路进行划分，可以将组织架构服务、人员服务、日志服务、监控服务、告警服务、统计服务、工作流服务、流程监控服务、信息发布服务、权限服务和身份认证服务等非业务性功能进行抽取和整合，形成稳定的底层服务，作为微服务数字校园建设的基础.另外，对业务性功能服务如数据标准转化服务和数据字典服务等进行提取[9-10].通过对基础组件服务进行提取，可以有助于快速的构建其他微服务，敏捷的推进微服务架构改造.

(2)进行业务系统拆分改造.为了降低系统拆分复杂度，做到风险可控.按照纵向拆分原则对原系统的业务功能模块进行微服务改造，将具有相同业务逻辑的功能模块进行独立拆分提供服务[10-11].改造和业务系统迭代的过程大致可以细分为四个阶段，一是构建功能服务接口，将系统核心的功能分离出来；二是利用功能服务接口作为代理，解耦原业务系统及其调用者之间的依赖；三是在核心功能服务基础上，逐渐将原有业务系统改造成多个独立服务；四是使用全新微服务模式替代原有业务系统.

(3)持续优化改造.业务数据量的变化、数据物理存储模型的变化、微服务协同机制的变化以及实际需求的变化都会导致微服务实例的调整，因此微服务改造不是一步到位的，它是一个持续构建和持续优化的迭代过程.随着新的业务需求的不断提出，选择合适的原子微服务或业务微服务，通过流程配置快速的发布部署，真正实现对业务需求的敏捷响应.

改造完成后，传统数字校园和基于微服务的数字校园架构对比如图3所示.

图3 传统数字校园架构和基于微服务的数字校园架构对比图

对于新建系统，在业务需求分析阶段，不再以构建大而全的业务系统为目的，而是采用遵循微服务架构的标准和规则，明确服务的边界和范围，以服务为驱动来进行业务结构设计，与组织架构、认证服务、身份认证服务及权限服务等基础组件微服务相互调用协作，不断为师生提供丰富的轻应用服务.

5 小 结

提出了一种基于微服务架构的数字校园平台改造及持续集成框架，并以云南师范大学数字校园建设改造为例，分析了从传统数字校园架构改造成基于微服务架构数字校园的过程.开展基于微服务架构的数字化校园改造是一个非常复杂的过程，需要加强顶层设计，分步实施，在推进业务系统改造过程中，要以师生员工和管理人员的实际需求为切入点，以点带面，用建设成效来推动项目，不断提升数字校园服务学校教学、科研和管理的质量和水平.