精彩报告 | 中山大学何海涛：微服务架构下的教务管理服务建设分享

何海涛（中山大学 网络与信息技术中心主任）

尊敬的信息化建设同行们，大家好！

我今天要分享的是中山大学如何用微服务这种新的技术架构去改造教务管理系统。

我的报告分为三个部分。

第一，我们是怎么看待这件事情，怎么选择这条道路；

第二，前进的过程中，我们遇到了什么问题；

最后，目前取得的一些效果。

进化之路上的关键词，我的理解就是Transform，也就是变革。

其实每个学校都有教务管理系统，应该说在整个校务系统中，教务管理系统是我们信息化部门心中的一个痛点。

中山大学最早从1998年开始使用教务管理系统；

2003年我们在做数字化校园一期项目时选用了希尔的系统；

2010年，因为学分制等一些新的业务需求，我们开始使用东软的系统；

2015年，我们借着学校要在管理学院做全学分制试点的机会，重新打造教务系统。在这个节点上，我记得当时和联奕是有合作机会的，却因为各种原因失之交臂，但现在看来，当时的失之交臂反而换来了今天的回头一眸；

2017年，我们和联奕合作，开发基于微服务架构的完全学分制本科教务管理系统。

从这里我们可以看出，中山大学教务系统的整个发展历程，基本是七年一个换代。2015年这个节点其实是做一个试点，当时我们尝试将选课这个痛点剥离出来，变成一个外挂的形式，也取得了良好的效果。

总的来说，教务管理系统对学校来讲，是衡量信息化管理水平的一个标尺。

随着学校教务的发展，业务在不断变化，需要把需求调查清楚，才能开始做信息系统。实际情况是，我们的技术架构在适应业务发展的时候遇到很多矛盾，所以才会出现在七年就发生一个大的升级，推倒重来，要不就是苟延残喘勉强维持，不断打补丁，使得最后的体系架构越来越庞大，直到实在没办法还是推倒重来。

传统的架构都是紧耦合，每个功能的业务和数据都是紧耦合的，任何一个业务功能出了问题，就导致数据服务产生问题，从而牵一发动全身，教务系统整个出问题。

教务系统的痛点大家都能感受到，比如从用户的角度来讲，操作体验差，因为架构太老，一个系统用了七年后怎么可能会适应现在用户的要求。从老师的角度来讲，系统架构太老，成绩录入时经常丢失数据，还有选课宕机，业务变更频繁，工作效率低等。

如何解决这些问题？我们必须要进行体系化的、系统化的全局的变革。

非常幸运，2016年在酝酿这件事情的时候，经过研判，我们觉得在这个时机用微服务这种新技术新方法论来支撑教务系统的重构，这个探索是非常有价值的，成功的概率也会比较高。我记得当时跟联奕做过一个简单的沟通，大家取得了很多共识，于是就决定从学校最难的教务系统开始干，我觉得这样更具有挑战性或者示范意义。假如这个实践能够取得一点成果，也是中山大学对教育信息化行业所做的一点贡献。

我们从开发流程、应用架构、部署技术、基础设施等方面进行全面探讨，来朝着微服务化去迁移。技术和服务的“超融合”，其实这个“超融合”，“融合”非“耦合”，从另一个角度来讲，是业务和业务之间、业务和数据之间充分解耦才能实现的。

从整体的设计层面来讲，我们在反思为什么以前的教务管理系统做不好。

首先是因为教务系统的体量特别大，但从信息化部门来讲呢，我们认为顶层设计做得不是很好。传统的做法，需求谈得很多，但是设计方面一直没有一个很好的方法论和实践。所以我们当时在做教务系统的顶层设计时，开始引入基于信息资源规划、技术架构规划、环境保障规划的思路，另外在技术层面，运用原生云架构设计，以及微服务架构设计。

从业务的框架设计上来讲，我们开始分职能域、业务大类、业务过程、业务活动等，当然了，在传统的教务系统设计过程中这个也会去做。另一方面，传统的教务系统在设计的时候，通常是从教务管理人员的角度去看问题，并没有从用户角度去看问题，所以这次我们从用户视角，将用户分为教务管理员、院系管理员、教师、学生这么几个角色，落到具体的域中，他们所做的工作，从而来做用户模型的设计。这种设计就使开发人员更有全局眼光。

在具体的技术方面，微服务、Docker，DevOps都已经落地了。

从整个中山大学的教务系统来讲，我们是计划分成三期来建设，2017,2018,2019三年来完成。今年是第一年，第一阶段我们总体上还是打基础为主，包括做基础数据、学业预警、学籍管理（大部分）、系统管理、系统框架及过渡方案设计等。最难的是明年第二阶段，相当于攻坚阶段；后年第三阶段我们希望是优化阶段。整体按照数据-模块-服务的步骤来走。

这张图就充分体现了微服务解耦的过程，任何一个服务都是独立的。

由于大家都是从传统的开发方式转向微服务，我们的设计人员、开发人员在这个过程中都犯了一些看起来很低级的错误，但也为我们积累了很宝贵的经验，那么这些坑，希望别的学校再去实施的时候不会再遇到了。比如说，开始设计时，我们每一个职能部门每一个服务都有一个独立的数据服务和接口，后来在做的过程中发现这样太复杂了，于是又专门分出来一个外部接口支撑领域，使得新系统无需依赖旧系统数据，只需调用外部接口服务，就可以解决新旧系统数据耦合的问题。从传统的去中心化，从集中式变成分布式，对技术架构的要求更高。

从目前我们所看到的效果来讲，对学生来说，选课和成绩查询是最重要的，但我们希望学生在进入大学时，就能看到自己的课程地图，来帮助他对自己的学业路径进行规划。另外在过程中提供可视化信息，方便学生实时掌握学业情况。而当学生在学业上出现状况时，及时预警学生，并同时反馈给家长。

我作为一个技术人员，实际上我们网络信息中心更多的是做一些技术支持，比如说运维，技术架构这一块。传统的信息系统在开发的时候往往只考虑了开发，而开发和运维之间是相互脱节的，导致了很多信息系统在设计时看上去很美好，但是一上线，就带来性能和服务方面的问题。那我们基于DevOps框架理念下，开发和运维可以说是同步进行考虑的。

我们采用容器的方法之后，基于K8S的容器调度，有弹性伸缩特性，解决了很多人力问题。最典型的就是负载均衡，正常情况下负载很低的，那我们看怎么伸缩，当业务量变大的时候，两个实例顶不住了，这时候自动地就有新的实例起来，去分担业务压力。这都是架构和框架所支持的，不需要人工干预。当选课人少了，自动会缩减实例。这就是弹性伸缩。

如果某一个业务宕掉了，那么这个业务会自动地迁移到别的机器上去，动态迁移完全不是靠人力去做的。

微服务架构在教务信息化这个领域的实践还非常少，我们在开发过程中也遇到过很多问题。

比如领域拆分，这个服务到底拆得颗粒度有多大，是蛮难的一个问题，也是一个反复试错的过程，但是这个弹性的敏捷的架构，使得我们试错的成本会比较低；

第二个困难就是综合查询，因为很多数据以前是集中的，现在开始分布化的，分布化之后就带来分库分表查询效率的问题；

第三个就是数据不一致的问题。这也是从集中式变为分布式之后所带来的一些必然的问题。对业务来讲，到底“大本科”是什么样子，业务在不断变化，对技术来讲，微服务和容器，如何实现业务和技术的融合，如何通过适度的解耦来实现“超融合”，这也是一个很难的话题。但我希望能通过我们大胆的尝试，改变大型信息系统总是要推倒重来的现状，使得不断“拆了吧”的状态一去不复返。

谢谢大家！

（以上内容为现场实录）