基于微服务架构的智慧校园系统平台建设研究

张广鑫

（大连职业技术学院，辽宁 大连 116035）

随着信息技术在教育领域的发展和变革，校园信息化建设经历了从网络化校园到数字化校园再到智慧校园的演进,教育信息化正逐渐呈现出智能化、开放化、个性化和社交化等特征[1]。通过网络化和数字化校园建设，大部分学校已完成了学校基础网络环境铺设和信息系统数据统一标准化制定，以及以管理和服务为驱动的业务系统构建工作，消除了各信息系统之间无法关联、相对孤立的“信息孤岛”，打通了各业务部门之间数据的流通和共享，提升了学校信息化水平，为师生的办公、教学和生活带来了极大便利。

近几年，云计算、大数据、物联网和人工智能等信息技术的发展突飞猛进，为国家教育事业现代化的建设提供了新动力，注入了新血液，“智慧校园”的概念由此应运而生。以智慧校园为载体的智慧课堂、智慧办公、智能校园管理和大数据分析等智慧应用，也如雨后春笋般涌现出来。然而面对新环境下的业务需求和应用场景，在数字校园建设阶段信息系统平台所广泛采用的单体架构和SOA（面向服务）架构已无法满足系统快速更新迭代、海量业务数据传输存储、人与物或物与物的互联互通等复杂环境。微服务架构具有扩展性强、配置灵活、协议简单、服务组件化和高内聚低耦合等特点，应用系统采用微服务设计，能够更好地支持智慧校园系统平台建设。

一、智慧校园

（一）智慧校园概述

智慧校园是指以校园信息化建设为契机，以校园基础网络（包括有线网、无线网和物联网）为载体，利用云计算、大数据和物联网技术实现从教学场景、教学资源到应用服务等校园信息和服务全部智能化、智慧化。它能够促进空间和时间的有机结合，使任何人、任何时间、任何地点都能方便快捷地获取到有价值的资源和服务。智慧校园是数字校园的进一步的发展和提升，是教育信息化的更高级形态[2]。

（二）智慧校园整体架构

2018年6月，国家市场监督管理总局和国家标准化管理委员会联合公布了《智慧校园总体框架》国家标准文件，文件中对什么是“智慧校园”进行了定义和说明，对相关的术语约定、技术要求、总体架构等进行了解释。它将智慧校园整体划分为四层，分别为基础设施层、支撑平台层、应用平台层和应用终端。通过建立标准清晰的数据规范、技术规范，使各个层之间具有良好的数据通信、相互协作和互联感知的能力。信息安全策略贯穿智慧校园建设体系的各个环节，在整个生命周期内，保障通信安全、数据安全和身份安全等。智慧校园整体架构图如图1所示。

基础设施层是构建智慧校园整体架构的重要组成部分和业务基础保障，能提供多种网络通信服务架构（如有线网、无线网和物联网等）、大范围布局的物与物感知和人与物感知设备、安全可靠的海量数据存储、灵活分配的高性能计算资源等，为智慧校园的各类应用服务提供基础支持和业务支撑。它包括网络通信设备、物联感知设备、存储设备与服务器等。

图1 智慧校园整体架构图

支撑平台层与应用平台层两者一同组成了智慧校园建设体系的核心层，是连接控制应用终端与基础设施进行沟通协作的“大脑”和“桥梁”，是校园信息化建设能够体现“智慧”的灵魂的所在。支撑平台层为智慧校园的各类应用和程序提供服务和支撑，它包括统一标准接口、数据交换、数据服务、数据处理和数据监控等功能性的工具单元。应用平台层是智慧校园各类应用程序的集合体，是智慧服务的具体展现。在支撑平台层的基础上，构建了智慧校园的管理、教学、生活和服务等应用，为学校的管理者和师生提供全方位的智能服务。它包括智慧校园、智慧教室、智慧教学、智慧办公、智慧生活等各类管理服务。

应用终端层是智慧校园各类信息和应用的访问者与使用者，通过各种终端设备（如PC端、手机端等各类移动终端设备）和互联网应用服务设备，不受时间和空间所限制，能够随时随地访问各类平台资源和服务，它主要包括不同角色的用户和接入访问的设备等。

二、微服务

（一）微服务概述

微服务架构最早是由国际著名面向对象开发专家、“敏捷开发”创始人之一的马丁·福勒于2014年提出的一种全新软件开发设计模式。微服务架构本质上是由一组可独立交付业务单元构成的分布式系统[3]，通过对业务和结构复杂的大型系统进行合理划分，分解成一系列微小的独立应用服务。每一个微服务都是只与其具体负责业务紧密联系的单一功能体。在系统层面，每一个微服务都可以认为是一个独立的进程，每个微服务仅关注于完成一件小任务[4]。它可以运用不同类型的开发语言和工具来实现。每个微服务都可以通过轻量级的通信协议进行相互沟通协作，具有容易扩展变更、快速开发部署和结构相对简单等特点。

（二）微服务架构

1．微服务架构的演进过程

伴随着互联网信息技术的不断发展，为了适应互联网信息技术的发展浪潮，信息技术应用架构经历了从单体架构到面向服务架构SOA（Service-Oriented Architecture），再到微服务架构的演进和迭代过程（如图2所示）。

单体架构是指把所有的功能模块都放在一个独立运行的程序中，图2中程序1和程序2都是单独的个体，所有业务功能组件都耦合在自己的开发框架内，没有任何的交集。当程序各自完成系统开发和发布后，只能配置和运行在一个进程中，程序1和程序2的业务数据都是相对独立，无法关联，造成数据“孤岛”的现象。

面向服务架构SOA（Service-Oriented Architecture）[5]是一种粗粒度、松耦合的服务架构，它将程序1和程序2的不同业务功能组件（在SOA架构中通常称其为服务）通过定义标准化的接口和良好的契约关联起来。接口的定义是不站在任何一方的立场下完成，与其所依托的硬件环境、操作系统和开发语言等无关。SOA架构比较主流的实现方式是ESB服务总线。在程序1和程序2的内部或两者之间的服务可以通过统一的规则进行数据通信和业务访问，具有服务简单、耦合度低、易于扩展等优点。但随着程序数量的增多和访问业务量的增大，SOA架构存在的问题也突显出来。各个服务都是依赖中心化的管理模式，中心端本身就是一个过重的服务，服务中心内部的复杂性问题依然存在，当服务中心产生变更时，会影响其管理的程序。

2．微服务架构的核心组件及实现原理

微服务架构也称微服务[6]是将应用程序设计成多个可以独立开发、维护、配置和运行的微小服务，各类微服务通过轻量级的协议进行数据通信和协调调度，每个服务都比较简单[7]，都能够独立完成某一项特定任务和功能。通过提供微服务框架，解决微服务的各类注册、发现、服务、调度、容错等各类通用性服务功能[8]。微服务架构的核心组件及实现原理如图3所示。

图2 应用技术架构演进图

图3 微服务架构的核心组件及实现原理图

API网关是微服务架构中用户调用服务的统一入口，可以根据用户终端类型的不同设置不同的访问网关。当用户需要访问服务时，API网关首先识别用户的身份信息，根据角色访问权限进行调用控制和路由转发，将用户请求数据定向发送给服务端。当服务端完成业务处理后，不仅可以将独立的计算结果进行输出，还可以将不同服务产生的结果进行合并后再统一输出。API网关还可以实现跨语言、跨平台的元数据转换、数据防篡改、协议转换和流量计量计费等功能。

注册中心是微服务架构的重要基础组件之一。当服务之间需要进行协同合作完成用户的请求时，需要通过注册中心组件找到服务和服务地址之间的对应映射关系目录，然后调用相应服务的实现类完成所需要操作。它主要包括“服务注册”和“服务发现”两个方面，负责服务的注册和管理工作。服务在保持正常运行时，需要进行服务注册。注册中心会对所有注册通过后的服务进行管理，获取服务的相关信息。服务发现是指当用户需要访问某一服务时，通过识别服务名称从注册中心内发现与服务实例相匹配的服务通信地址，从而保证服务对用户请求的正常响应。

负载均衡是微服务架构稳定运行的重要保障，它可以对从用户发起的访问流量进行管控，按照不同的均衡策略把流量合理地分配到具有相同服务内容的不同系统上，使服务能够分担负载和保证业务访问的稳定性和高可用。负载均衡是处理高并发、缓解网络压力和进行服务端扩容的重要手段之一[9]。按照实现方式可以分为服务端负载均衡和客户端负载均衡；按照均衡策略可以分为随机分配、遍历轮询、地址哈希和权重响应等。在实际生产环境中，可以根据实际的基础网络环境、服务器性能、用户数量和优先级等综合因素考虑，选择合适的负载均衡部署方法和技术架构。

服务容错是微服务架构的故障隔离和容错处理机制。我们将庞大的业务系统拆分成若干个独立运行的微服务单元后，各个服务之间相互依赖，通过API网关调用执行。当用户的并发访问量过大时，会导致服务崩溃，与服务相互依赖的其他服务也会无法正常访问，导致整个业务层面的瘫痪，出现雪崩效应。为了防止业务系统出现雪崩效应的情况，微服务架构引入了服务容错机制，它包括流量限制、线程隔离和熔断降级等容错手段。

配置中心是微服务架构用于所有关联服务配置的集中管理。在实际生产场景中，每个微服务都可能包含多个不同类型的配置项，如属性配置、驱动配置、环境变量配置、业务依赖配置、系统参数配置等。配置项中的参数纷繁复杂，当某一参数需要修改时，往往需要停止服务，对配置修改完成后要对程序重新打包发布，增加运维人员工作量，造成管理混乱，容易出错等。通过配置中心组件，可以把各个服务中的各种配置，各类参数等全部统一集中到一个地方进行管理，建立完善标准的接口对外提供支持。当某一服务需要修改配置时，首先来配置中心获取服务本身的配置信息，修改完成后将更新后的配置推送到配置中心，与配置中心关联的其他服务可以动态获取最新的配置信息，确保数据的一致性。

消息总线是在微服务架构中各个服务实例之间进行消息推送和接收的管控中心。服务之间要想实现消息通信，首先服务要在消息总线上建立独立的通信隧道，服务生产者推送一条消息到消息总线上，服务消费者在订阅服务生产者的情况下，可以通过消息总线接收到信息。消息总线在两者之间充当一个“中间人”的角色，实现了服务之间的解耦和服务性能的提升等。

三、基于微服务架构的智慧校园系统平台构建

目前，高校信息化建设正处于从“数字校园”向“智慧校园”发展的转型期。对于信息化建设来说，基础应用系统和业务支撑平台的建设可以统称为系统平台建设。系统平台建设是智慧校园建设的重要组成部分。基于微服务架构构建布局合理、设计灵活和易于扩展的系统平台，能够为智慧校园整体稳定运行提供有力保障。微服务架构下的系统平台建设主要包含两个方面：一是以微服务架构的体系标准为依托，对学校现有业务系统进行升级改造；二是对于未来要建立的系统，严格按照面向微服务的设计模式进行顶层设计，统筹安排，合理规划。

以大连职业技术学院信息化建设为例，学校在数字校园建设阶段，现已完成了人事系统、OA办公系统、学生系统、资源管理系统和基础数据平台等系统平台的建设。业务系统相对独立，系统之间通过数据交换平台实现数据的共享流通，但业务功能模块无法相互调用。通过对各系统进行结构性分析得出，系统除了有跟自身业务相关性比较高的功能模块外，还有如身份认证、权限分配、安全监控和报表统计等具备相同业务逻辑需求处理的组件。充分分析原系统建设背景后，为了降低系统拆分重构的复杂度，做到风险可控。对原系统的业务功能模块的整体作为一个微服务进行管理，将具有相同业务逻辑的功能模块进行独立拆分提供服务（如图4所示）。

对于人事系统、OA系统、学生系统、基础数据平台等主要业务系统，面向业务层面，按照功能特点进行服务拆分，各服务之间要实现解耦，保障服务的健壮性和稳定性。系统拆分后可划分为身份认证服务、权限分配服务、报表统计服务、安全监控服务和与原系统业务关联程度高的人事服务、OA服务等。教职员工和学生可以通过服务平台对需要的服务进行访问，各服务之间通过微服务架构的相关组件进行沟通协作。对于新建或拟建系统，在业务需求分析阶段，不再以构建大而全的业务系统为目的，而是采用遵循微服务架构的标准和规则，明确服务的边界和范围，以服务为驱动来进行业务结构设计，与其他身份认证服务、权限分配服务等微服务相互调用协作，为智慧校园的学校、老师和学生等最终用户提供业务支持。

图4 智慧校园系统平台

四、结论

基于微服务架构构建的智慧校园应用服务，具有完善的信息交互接口、灵活的策略配置和容错的运行机制，与业务开发所使用的开发语言、运行环境和中间件等条件无关。微服务架构是技术发展的必然结果，它能够解决传统的单体式架构软件系统面临的更新迭代慢、影响程度深等复杂问题[10]。每个服务都有明确的功能目标，业务边界明确清晰，采用轻量级通信协议实现服务的请求响应交互，服务内部逻辑联系紧密，外部耦合度低。微服务架构作为系统设计方法的出现，为智慧校园系统平台的设计建设提供了优秀的解决方案，提升了系统构建的灵活性和开发效率，降低了系统软件的开发成本。