从构筑大系统，到编写小应用

文/李凌

从构筑大系统，到编写小应用

文/李凌

编者按：

教育信息化诞生的历史并不长，成长的过程中有很多新鲜的理念，回过头来看，有的是顺应潮流的，有的又是理想化的。本文观点来自一位从事教育信息化实践多年的业内人士，他认为，大系统的理念并不符合 IT 界的实际情况，应用系统中小型化将成为趋势。关于本文内容，欢迎您与我们探讨，您可发邮件至 media@cernet.com。

李凌北京理工大学网络信息技术中心副主任

我刚到学校网络服务中心工作的时候，对于学校信息化应该做什么，以及应该如何做，并没有太多的概念。记得有一次去参加高校信息化学会的会议，听来自某知名学府的老师介绍 URP，瞬间觉得那真是一个很高大上又极其复杂的概念。想想我们信息化部门只有区区几个人，远远无法实现这一构想。

后来在学校里和同事聊起来，有同事说，你们网络中心应该做一个大系统，我们各个单位用。对于此，有些我非常认同，譬如学校信息化的确应该一盘棋，不能乱来。但一个包罗万象的大系统，要投入很多时间很多经费，也许光需求调研就需要几个月，研发起来也许要几年，然后再投入使用……不敢想象。

当时，开发一个大系统的思路在高校信息化界时常被提起。也有企业的宣传朝着这个方向努力。于是也就真的有厂商找上门，推销一体化学生管理系统等产品，把教务、学工、宿管等各个部门的需求，凝聚在一个庞大的软件里。他们认为这样的系统最大的优势，就是天生没有数据孤岛。面对这样的说辞，还真说不定有人会很心动，做个大系统一下子把信息化推上一个台阶，那真的是大功一件，再加上没有数据孤岛，岂不是非常先进？

一个大系统真的现实吗？

作为一个每周都要写几行代码的程序员，对于这种大系统之类的说辞，我还是有一点天生的警惕的：

首先，软件开发是一项非常复杂的工作，软件项目从出现的第一天开始，其失败率就远高于其他行业。譬如，我们很少听说盖房子刚盖好就塌了，但软件到期做不出来以及上线第一天就崩溃可不是什么新鲜事。并且，一个软件系统的复杂性，会随着功能的增加而呈指数级增加，量变导致质变，用来形容一个系统功能不断增加和该系统的稳定性不断下降之间的关系，再合适不过了。

其次，大系统的工期无法控制。单一软件项目的工期，通常应该控制在六个月以内，如果工期过长，无论是承包商还是相关部门的业务人员可能会因为长时间没有效果而陷入一种疲劳状态，同时软件自身的需求也可能因为业务的变化而不断发生变化，直接导致软件的工期更长，进而陷入一种恶性循环。

再次，按照当今高校信息化行业对软件价格的普遍认识，很多人都认为一套软件系统四五十万元就已经是很高的花费了。但四五十万元如果扣掉相关税款，扣除销售成本，在如今也就相当于一两个普通程序员一年的工资，而他们挣的钱不吃不喝合起来在北京这样的一线城市也就能买个厕所。这样的投入，能找得到做出大系统的人吗？

最后，即便是在 2010 年，人事、财务、教务、图书馆、卡务、网络中心等各个部门就已经建立了自己的管理信息系统，做一个大系统是要把它们各个部门的系统都放弃然后合在一起，这些完全属于不同管理领域的事情，真的有一个公司能都弄明白吗？

数字校园的架构

在软件工程领域，人们一直寻找着控制软件复杂性的方法，而其中最经典的一句话，就是 UNIX 所奉行的设计哲学： K.I.S.S. = Keep It Simple, Stupid!

Unix 系统，就是一个典型的简单系统，系统中的每一个命令行工具，都只完成一个单一的任务，譬如 ls 就只能列目录、wc 就是用来统计单词个数，若想知道一个目录中有多少个文件，就需要用 ls | wc 这样的组合了。

数字校园，作为一个涉及不同领域，既要支撑教学、管理，又要服务学习、生活的庞大 IT 设施，其必然由各种大大小小的组件构成，但这些组件之间又必须建立联系，否则就会形成数据孤岛。在经过长时间的调研、实践和思考之后，我们心中数字校园的整体结构和建设方式开始慢慢清晰，基本上可以用“大平台、中系统、小应用”来描述。

由于今天平台、系统、应用这些词语有着广泛的含义，因此有必要对其明确一下定义。平台，本身并不完成特定的业务工作，它的存在就是为了支撑系统和应用的正常运行，最典型的应该被称之为平台的就是基础服务层的如统一身份认证、展示层的如门户；系统，也就是管理信息系统，管理着某个领域的一组特定数据，并且支撑某个领域的日常工作，譬如人们熟知的教务系统、财务系统；应用，基于平台和系统中的数据，为用户提供某项特定的服务功能，门户平台中集成的成绩查询、网费充值，都可以称之为一种小应用。

大平台和小应用的概念今天已经被很多人理解并认同，那么“中系统”指的是什么呢？

中等规模的业务数据管理系统

业务系统是数字校园中不可或缺的一部分，通常是数字校园建设过程中最早启动的那一部分，但也经常成为被吐槽最多、失败率最高的部分。如今已经有很多原本做业务系统的公司在高校领域都活不下去，这是为什么呢？

1.预期错误：很多人认为做业务系统就是做软件，必须好看、功能全面、高大上，做个系统就要一切事情摒弃手工操作、不用 Excel。其实，信息化的根本任务在于对数据的管理，管理信息系统，就是帮助业务人员管理数据的工具。建设管理信息系统的根本，是梳理数据、优化管理，软件只要不出错、基本好用，可以保证主干业务正常运行就足够。

2.边界模糊：以高校中使用最为广泛的教务管理系统为例，在 10多年前大家刚刚开始做教务系统的时候，教务系统本身的功能还是很明确的，主要为了支撑学校最基本的教务运行。但随着教务处业务的不断增加，很多人觉得诸如计算机等级考试报名等各种各样的功能都应该增加到教务系统中来。各个软件厂商迎合这些不合理需求，在自己的产品中加入了越来越多的功能，活生生把学校的“教务系统”做成了“教务处系统”。

3.需求泛滥：在高校做业务软件，需求调研的过程往往非常奇葩，一种最常见的做法，就是业务部门的领导会把部门内所有的工作人员聚集在一起，开动员会，让每个岗位上的具体工作人员向厂商提出软件修改需求。这种方式，极易导致需求的泛滥和不可控。银行做软件会把所有柜台的服务人员都聚在一起跟承包商谈需求吗？正确的软件需求采集方式，应当是由部门中管理经验丰富、全面掌握业务的一两个人跟软件开发方的专家共同商讨制定。而一般的工作人员，作为软件的普通使用者，则应当按照既定的管理模式工作。

上述问题，都会使业务系统不断膨胀。正如前文所说，随着功能的增加，软件的复杂性也会不断增加。因此，我们强调业务系统，应该是“中等规模的业务数据管理系统”，一个业务系统应该只负责处理关联极其紧密的、重要的、成熟的、频繁发生的业务，其管理模型应当是业内普遍采用的。业务系统应该更多地强调数据准确性和及时性，易变的流程审批性内容则应当向学校统一建设的 BPM 流程平台迁移。

譬如教务系统，就应该只包含学籍、培养方案、排课、选课、成绩、毕业设计管理等最基本功能和相关的学生、教师服务界面。如果教务处还有其他的需求，都可以做成基于学校数字校园平台和教务系统基础数据而运行的独立应用。以这种模式构筑的教务系统，由于其需求稳定、数据清晰，如果再加上合理的软件架构设计和精心的实现，就可以用很久。

应用小型化和微服务

幸运的是，今天已经有越来越多的人认识到了系统中小型化的必要性和必然性，并且在实践中按照这种方式构建系统。在互联网领域，其实也有一种应用中小型化的趋势，也就是今天很多人所说的“微服务”模型。

互联网领域所使用的“微服务”模型，实际上是将过去一套代码、一套数据库的单体软件结构，分解为每个模块一套代码，每个模块一套数据的结构，这样，不同的模块可以根据自身的需要选择合适的语言编写，也可以根据实际应用的需要选择横向扩展方式。而模块与模块之间，则通过消息队列或是 API 接口等方式进行连接。

如果我们把数字校园看成一个大的互联网平台，那么今天数字校园的应用小型化趋势和互联网领域的微服务架构其实如出一辙，只不过在模块划分的粒度、实现方式的把握上，有着不太一样的标准罢了。

（责编：王左利）