基于微服务架构的一体化教务系统研究
微服务粒度与软件代码行数无关,“微”并不是限定服务的代码工程规模,而是限定服务所包含的业务功能范围。每个服务包含的业务逻辑需满足“单一且完整”规则[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.
特别声明:本站注明稿件来源为其他媒体的文/图等稿件均为转载稿,本站转载出于非商业性质的教育和科研之目的,并不意味着赞同其观点或者证实其内容的真实性。如转载稿涉及版权等问题,请作者在两周内速来电或来函联系。