基于微服务架构的

成天龙 许维胜

摘   要：面对新形势下高校教学业务改革以及本研一体化教务融合趋势，传统教务系统采用的单块架构已无法应对日益增长且快速变化的新需求。本文提出一种基于微服务架构的一体化教务系统架构并研究其关键问题，结合一体化教务理念，分析单块架构运行缺陷，给出教务系统向微服务架构转型的方案，研究微服务粒度与划分原则，并对新老教务系统迁移过程提出平滑过渡方法。最后通过同济大学教务系统实际案例，具体展示微服务架构转型实践中的实施方案。

关键词：一体化教务系统;微服务架构;微服务粒度和服务划分;平滑过渡

中图分类号：TP311.5 文献标志码：A 文章编号：1673-8454（2019）05-0073-05

一、引言

围绕创建世界一流大学的目标，高校教学改革日新月异，如：人才分类培养模式、本科新生导师制、本研课程互选、拔尖学生培养实验计划、大类招生改革、国际交流合作创新等。同时，目前高校的本科生、研究生教务管理仍处于相对分散独立的状态，且相应的教务管理系统大多采用传统的单块架构或SOA架构。这导致教务管理系统的需求响应速度已赶不上高校业务需求变化速度，且无法支撑实现充分的教育资源共享。

微服务（Microservices）架构作为当下流行的一种云原生的软件架构风格，能够以更加灵活、轻便、松耦合的方式来构建复杂的应用[3]，为传统教务系统单块架构的转型，提供了可行的技术路线。本文基于微服务架构对传统单块型教务系统的架构转型进行研究，按照微服务架构思想，拆分一体化教务系统为多个小而自治、协同工作的服务实体，化大而复杂为小而简单，有效降低系统业务逻辑之间的耦合，提升系统的灵活性与扩展性，使其能够有效支撑本研业务融合与一体化教务系统建设工作。

二、一体化教务理念

1.理念思想

一体化教务理念涵盖对本科生、研究生的统一教务管理思想，追求本、硕、博教学资源的统一调配与共享。整体规划本研教学业务，以一体化教学模型和数据为基础，一体化服务和管理为导向，以稳定开放的平台为运行支撑，借助弹性灵活的系统架构，搭建柔性伸缩应用，打通高校各部门业务，实现跨部门业务融合与数据共享，构建一体化教学服务平台，实现本研教育贯通式培养[1]。

2.具体表现形式

（1）模型数据一体化。整体构建教学业务模型数据，综合设计本研学生的一体化数据结构，利用数据交换引擎实现数据集成、共享，构建统一教学数据库。采用连续信息模型，实现数据分段式管理，按需组装，能够展现学生教学信息全貌与全生命周期下的教学事件节点等。划分业务模型，包含资源类与功能类。资源类模型包含教学业务实体，相对独立，不相互依赖，属于下层模型，包括人员全生命周期、课程等;功能类模型依赖于资源类模型，属于上层模型，其与教务业务紧密结合，包括学籍管理、培养方案、排课、选课、考试、成绩等。

（2）服务管理一体化。基于一体化教务整体规划，突出学生培养模式和教学管理个性化特点，对本研教务从顶层设计角度进行业务融合，形成整套一体化教学管理与服务系统。采用灵活的微服务架构，建设服务中心，实现教学服务注册、管理、发布、监控等。构建优质、稳定、高效的信息化教学服务体系，为教职工、学生提供“一站式”的教学服务，提供服务搜索、收藏、定制功能以及跨终端的服务体验。

（3）教学资源一体化。统一管理本、硕、博的课程、教师、教室、设备等教学资源，合理调配师生教学业务运行过程中的资源流转，实现资源共享与资源利用率最优化。

（4）应用开发一体化。构建校园教学服务应用的基础支撑平台，打造应用开发生态圈，提供应用服务全生命周期管理。面向校内应用开发者、体验者全面开放平台，提供标准接口。支持与公共数据平台、校园卡等其它业务系统无缝对接。

（5）界面入口一体化。提供统一的本科生、研究生访问入口，集成高校内部统一身份认证，支持和其它校内系统之间的SSO单点登录，面向不同身份用户提供风格一致的界面效果和使用体验。

（6）报表统计一体化。提供一体化的报表统计功能，对本、硕、博学生和教职工等各项评价、监控指标提供丰富的报表统计功能，提供师生学习效果和教学质量等信息，为学校调整人才培养方案提供决策支持。[2]

三、微服务架构简介

1.微服务架构定义

微服务架构是当下流行的软件架构风格。[3]該架构将复杂的单块应用分解成一组小而专一、耦合度低、高度自治的服务;每个服务围绕各自业务功能确定服务边界，独立开发、测试、部署;每个服务都是单独的应用，运行于独立进程中;使用和语言无关的轻量级通信机制，相互协同工作实现完整系统功能;每个服务仅关注和完成某个特定功能，一个功能代表一个小的业务能力。

2.微服务架构优势

微服务架构通过有效拆分复杂单块应用，降低系统耦合度，从而实现应用敏捷开发和灵活扩展。越是在规模庞大的软件项目中，微服务架构优势就越明显。[4]首先体现在独立性方面，每个服务都是松散耦合的，有明确的业务边界，低耦拆分的服务在开发、测试、部署阶段都能带来更高效率，使业务变更成本与风险更低。其次是技术选择更为灵活，由于微服务采用语言无关的API进行相互通信，因而不同服务可以针对业务特性和团队技能使用不同语言框架进行开发，使得技术转型成本降低。再次是系统复用性和伸缩性更强，微服务能将已有代码、对象和模块的复用转变为服务的复用，降低项目成本，并可针对特定服务独立伸缩。最后是服务容错性更高，微服务通常使用Docker容器独立部署，进程隔离，每个服务独立运行，某个服务出现故障也不会影响其它服务正常工作。[5]

四、微服务架构在一体化教务系统中的应用

1.传统教务系统架构与缺陷

高校传统教务系统由于架构形成时期较早，因此大多采用单块架构，如图1所示。系统仅以实现业务功能为目的，将所有功能集中在同一工程内部，业务逻辑耦合紧密。随着教学业务改革，单块架构下的教务系统缺点也愈发明显：①需求变更困难。无法满足新业务需求快速上线，难以在原有复杂工程上开发新功能。②扩展性差。只能基于整个系统扩展，无法针对特定功能模块按需扩展。③可靠性差。某个模块故障会导致整个系统宕机，影响其它正常模块运行。④维护成本高。只有原开发者才理解工程结构和实现，新成员难以维护工程。

2.微服务架构转型方式

单块架构无法应对本研一体化教务融合所带来的复杂性，为此采用微服务对其进行架构转型。如图2所示，左侧为传统教务系统单块架构，所有功能模块均运行于单个进程内，紧耦合，不易扩展，灵活性差;右侧为转型后的教务系统微服务架构，不同业务作为服务分散于不同进程中，每个服务进程功能完整且独立自治，能够单独输出业务能力，松耦合，易于扩展且更为灵活。随着一体化教务理念带来的系统重组与业务融合，教务系统业务复杂度将不断增大，此时采用微服务架构所带来的松耦合优势将愈发明显。

3.微服务架构平滑过渡

微服务架构转型需要注意新老系统之间的平滑过渡，保证业务流程协同，最终实现新老系统完全替换。老系统迁移过渡可参考下述步骤：①定义范围。明确业务改造范围，选取业务范围影响较小、非关键功能进行业务试点，明确成员责任范围，确保改造目标清晰。②功能剥离。将功能从原系统拆分出来，并构建新服务，在原系统前端使用代理机制，使用遗留系统和新服务组合为用户提供服务。③数据解耦。从原有单块架构数据库中剥离相关业务数据，尽量满足对于每个服务有独立、隔离的业务数据库。④数据同步。对于复杂业务逻辑，改造时间和成本较大，可能在较长时间内，由于新服务独立出来导致无法同其它现有系统协作，此时可采用将新服务中的业务数据同步回原系统数据库中，保障原有功能可继续使用。

五、微服务粒度与服务划分原则

1.微服务粒度

服务划分是微服务架构实施的重要一步，良好的服务拆分能使系统保持松耦合、高内聚。服务划分旨在“按照业务领域组件创建服务，使服务独立开发、管理和扩展”，即对业务领域功能按照组件形式进行拆分，其关键是业务领域组件所含业务边界大小，即服务粒度。

合理的服务粒度是保证微服务架构高效运行的重要因素。粒度过细会导致服务数量过多，交互关系复杂，系统集成效率和可用性降低，后期难以维护;反之，粒度太粗，会导致解耦不足，多个服务逻辑相互耦合，无法满足上层对某个细分服务的使用需求，缺乏灵活性。因此，服务粒度太细或太粗均不合理，原则上应根据业务需求，能够满足上层对所划分服务自由编排从而获得更多业务能力。

微服务粒度与软件代码行数无关，“微”并不是限定服务的代码工程规模，而是限定服务所包含的业务功能范围。每个服务包含的业务逻辑需满足“单一且完整”规则[6]：①“单一”规则。强调业务功能原子性。单个服务中不应存在两部分完全无关或互不影响的逻辑，否则应把这两部分逻辑拆开，也就是说只要与实现某单一业务功能无关的逻辑，则应将其分离到它应该属于的服务中去。“单一”规则用于限定微服务粒度的上限。②“完整”规则。强调业务功能完备性。如果说合适粒度的服务完成一项“任务”，则不应将该服务持续细分而使得更小粒度服务演变为完成这项“任务”所需的一个“步骤”，也就是说只要是实现某单一业务功能所需的逻辑，则都应放在同一服务内，而不应放在其它服务中被调用。“完整”规则用于限定微服务粒度的下限。

2.服务划分原则

服务划分没有普适的方法，而是根据实际业务综合考虑多个因素。按照业务领域组件思想，服务首先要根据业务功能拆分，直到每个服务满足功能“单一且完整”要求。具体来说，首先通过系统交互流程分析，将业务系统内部流程分解到具体业务功能组件，识别出最细粒度的业务功能单元，再按照高内聚、松耦合原则，从底向上进行服务聚合，尽量保证各个服务之间交互最少，最后根据各个服务模块功能特性，多次迭代调整得到最佳的满足高内聚、松耦合条件的服务划分。对于公共基础数据和系统通用模块，采用共性下沉的策略单独划分。

实际开发中，为了项目前期快速进行服务识别，一个有价值的服务划分方法是：首先分析该业务系统承载的主体业务流程是什么，然后分析这个业务流程可以横向划分为哪几个独立阶段，将这些独立阶段划分为不同的服务，再根据每个服务自有特性进行分析修正。以一体化教务系统为例，其承载主体业务流程为学生的全生命周期教学管理，大致可以横向划分为迎新报到、学籍注册、培养方案、排课、选课、考试、成绩、实践、学位等阶段，因此可先按上述阶段进行服务划分，再对每个服务独自调整。对于公共基础数据，如学生、教师、课程、教学资源等，按照共性下沉策略单独拆分微服务。同理，系统通用模块，如会话管理、流程管理等，也需独立划分。

总体来讲，服务划分不能只从技术角度出发，而要面向业务、分而治之，综合考虑以下各方面因素。

（1）业务因素。首先从业务角度确定划分方案。服务边界要充分考虑业务独立性和专业性，比如教务系统中的课程管理、选课等服务，按照业务对象和业务行为合理拆分服务边界。

（2）自给自足。明确服务分工，确保每个服务仅包含自身所需处理逻辑，包括数据存储、业务逻辑、消息发送接收等。保障服务运行自给自足，相对独立，减少对外界依赖，提升服务独立运行、升级和灵活拼装能力。

（3）系统扩展。服务解耦拆分最重要的作用之一是提高系统扩展性。不同服务有不同的扩展性要求，把具有不同扩展性要求的服务单独划分处理，能够提高系统扩展效率。比如教务系统中的选课服务要求较高并发性能，把选课服务分离，单独考虑其性能扩展需求，确保不會因选课服务负载过高而导致整个系统不可用。

（4）数据一致。微服务架构如果需要跨服务改变业务数据状态，则需要处理复杂的分布式事务与数据一致性问题，对系统性能有较大影响。相比之下，只在同一服务内部保证事务性更加简单且高效。尽量把有数据强一致要求的事务性逻辑放在一个服务内，服务边界满足非事务性、数据最终一致性即可。

（5）信息安全。不同服务有不同的信息安全要求。对于信息安全要求高的服务可以单独划分并特殊部署，比如运行在防火墙后，也可以根据服务特点针对性地满足信息安全需求。

（6）服务组合。在底层服务之上，可能会有服务能力组合层，实现组合服务。如果存在这种情况，最好也以独立的服务模块实现。组合服务本身可能并不对应具体数据库，而是将下层服务进行组合，形成新的接口服务能力。

六、同济大学教务系统微服务架构转型实践

1.原有教务系统问题

同济大学原有教务系统有三套：本科生教务系统、研究生管理系统、本研一体化教务管理系统。前两套系统分别用于管理本科生和研究生教务，建设年代较早，技术架构落后;后一套系统首次尝试本研业务融合，但由于其仍为单块架构，未采用微服务架构，最终由于业务复杂性及单块架构局限性，未能将本研教学业务真正融合。三套系统目前各自管理部分教学业务，在数据与业务层面均未进行全面融合，且系统均为单块架构，耦合紧密，难以持续演进，已无法响应新时代高校教学改革需求，为此急需通过微服务架构来构建一体化教务系统，支撑本研业务融合应用建设。

2.一体化教务系统服务划分

基于一体化教务理念，结合微服务划分原则，一体化教务系统服务划分如图3所示，主要分为三个层次。

（1）上层业务服务：面向具体业务行为的上层服务。基于高校教学流程，按照学生培养过程中的业务环节划分服务。考虑本研业务融合，构建本研模型、数据一体的教学流程，每个流程负责学生培养过程中单一完整的一个教学环节，包括从学生入学的迎新报到、学籍管理，直到学生毕业时的学位管理，同时涵盖培养过程中间的各个教学环节管理，比如选课、考务等。

（2）基础数据服务：底层公共的基础资源类服务，偏向业务领域模型，包括学生、教师、课程、教学资源等基础信息管理服务。

（3）系统支撑服务：系统级公共服务，支撑业务系统运行的通用服务，如会话、前端Web、单点登录等管理系统必备的基础功能服务。

3.一体化教务系统技术架构实现

微服务架构实施要求多项复杂技术支撑，为此借助业界主流的微服务PaaS平台，减少前期基础设施自动化工具建设所带来的成本和复杂性，便于快速进行业务开发。通过对各大平台的功能完整性和可靠性调研对比，一体化教务系统最终选用华为ServiceStage微服务平台，系统技术架构如图4所示，主要包含以下层次。

（1）资源层：负责数据持久化存储，主要包含MySQL数据库、Redis分布式缓存、文件存储以及学校内部数据仓库。

（2）平台框架层：使用ServiceStage微服务平台，借助CSE微服务引擎，通过Docker容器部署服务，提高系统资源利用率。服务注册、发现等治理功能由平台提供。由于每个服务均以独立进程运行，服务间通信需要通过网络调用完成，而网络调用无法保证完全可靠，因此平台层提供重试、降级、熔断等容错机制来保证服务间调用的可靠性。

（3）服务层：借助微服务平台，开发只需关注服務层。根据系统服务划分方案，主要包括上层业务服务、基础数据服务和系统支撑服务三个层次，每个层次包含各自具体服务模块，实现业务能力输出。此外，微服务平台提供服务通信和服务管理能力，保障服务的相互通信和监控运维。

（4）网关层：服务访问入口。Web层对服务的访问都需要通过API网关来实现请求传递。在微服务架构中，API网关也称作边缘服务（Edge Service），通常采用Nginx、Zuul等反向代理实现。此处采用平台特有的NodeJs+ServiceMesh实现，NodeJs负责接收外部请求，ServiceMesh又称服务网格，可理解为轻量级网络代理，ServiceMesh通过与服务注册中心保持长连接获取每个服务实例信息，从而将不同服务的外部请求路由至相应服务。

4.一体化教务系统建设成果

目前一体化教务系统已实现服务如图5所示，包括大部分系统支撑服务和基础数据服务，以及部分上层业务服务。图中每个圆圈及其下方服务名和版本号唯一确定一个微服务，箭头代表服务间调用关系，实际开发中会不断对服务进行迭代从而升级版本号。

七、结束语

一体化教务理念是高校实现创新人才培养、开展教学改革的关键与核心。为了更好地推进本研业务融合，加速一体化教务系统建设，本文采用微服务架构替代传统教务系统单块架构，研究系统转型方案及服务粒度划分，提出新老系统平滑过渡方式，并通过实际案例，展示转型实践中的系统技术架构等具体实施方案。基于微服务架构的一体化教务系统能够灵活应对持续增加的系统复杂性，快速响应新形势下的一体化教务融合需求，为高校实现本研贯通式培养奠定基础。

参考文献：

[1]宣华，张秋芳.本—硕—博一体化教务管理的探索与实践——以清华大学注册中心为例[J].教育理论与实践，2013（3）：9-11.

[2]宣华，张秋芳，郭大勇.高校教学信息统计分析的研究与实践[J].实验技术与管理，2012，29（1）：171-173.

[3]王磊.微服务架构与实践[M].北京：电子工业出版社，2016.

[4]邓杰文，曹彩凤.微服务若干关键问题研究[J].五邑大学学报（自然科学版），2016，30（2）：49-54.

[5]张向祺.基于微服务的企业移动办公平台规划设计[J].信息技术与标准化，2016（3）：13-15.

[6]蔡凯.恒丰银行微服务化理论探索——服务粒度和服务划分原则[J].金融电子化，2017（9）：74-75.

（编辑：王晓明）