所谓“大平台”，有时不简简单单的是一组堆砌的程序，而是一种软件架构的设计理念，更是这种理念在其每个组件上得以贯彻。
看的见的问题
过去，每一个系统都必须是完整功能的集合体，除了要解决好自身的业务问题，还要解决好很多跟系统运行关系并不密切的问题：
- 要开发一套完整的用户认证，并要向用户发放密码；
- 如果需要向使用者发送通知，就要直接对接各种短信网关；
- 想获取另一个系统的数据，就要直接在系统间做数据对接。
这些不仅仅是技术性工作，也会给系统的管理者带来巨大的管理成本。在数字校园建设的初期类似的问题并不明显，但随着系统和应用的增加，就慢慢表现出来了。现实中，应用系统建设者的大量时间和精力，都耗费在了这些毫无意义的事情上面。
统一身份认证
记得我还在计算机学院工作的时候，一直在做网络教学相关的工作，我们碰到的最大的问题，就是每年新生来的时候，我们必须要手工导入学生的信息，然后再给学生设定好默认密码，如果有学生密码忘了，就要帮他们修改。当然，除了学生，还有每一个使用网络教学系统的老师。其实这样的问题，并不仅仅在学校里面的一个单位出现。每一个曾经经历过信息化前期建设阶段的人，都会遇到类似的问题。同样，作为信息系统的用户，也不断被忘记密码的问题折磨着。
统一身份认证技术本身，在很多年前就已经成熟了。目前国内高校所普遍采用的 CAS 协议，是由耶鲁大学设计并在国外高校推广的。相关的开放源代码项目，也一直由社区维护着。最初我们直接利用社区版本搭建了服务，后来考虑到长期维护的工作量，就把这个事情外包出去了。
要让学校各个系统接入统一身份认证，就不是那么简单的事情了。最初给我们巨大支持的就是人事处，新人事系统上线直接使用了统一身份认证；但当时学校里面很多已经使用了很长时间的系统，想要修改认证方式是非常麻烦的。在努力无果后，我们开始换一种新的思路，一方面把住新系统上线必须接统一身份认证的底线，另一方面通过包括乐学、迎新、离校在内的一系列我们可以掌控的应用，来普及统一身份认证。
经过了长时间的努力，统一身份认证的模式开始得到用户和业务部门的认可，统一提供的基础认证服务，不仅仅让用户使用系统更加方便，也实实在在地减轻了业务部门系统上线的压力。譬如学校的实设处，主动在其业务系统升级改版的过程中，逐步将每一个小系统进行了接入，而这些新系统的加入，也使得统一身份认证本身被更多人熟悉并了解。
时至今日，学校尚未接入统一身份认证的系统已经屈指可数，并且这几个系统相关部分的改造工作都已经提上了议事日程。在不远的将来，“登录不同系统要用不同密码实在太土了”这样的教代会提案，就不会再出现了。
短信转发网关
在微信还没有出现之前，发送短信，是一种非常方便且流行的通知方式。那时，很多学校都在购买短信网关产品，但多数时候这些产品都是给人用的，在应用对接方面也可以提供接口，却并非产品的主要功能。
我们最初碰到短信网关的问题，是在做找回密码功能的时候，需要通过短信发送验证码。那时我们找了一家互联网上的提供短信发送接口的公司，然后就把程序与其接口进行了对接。刚刚开始的时候，没有问题，但不久之后，悲催的事情发生了。这家公司由于自身经营不善，要关门歇业。于是我们又找了一家，按照新的接口写好了程序，没过多久，由于工信部整治垃圾短信，很多服务商的通道都被关停，而我们使用的这家也未能幸免。于是只好再换！
也正是在这个时候，我们意识到，外部有些东西是我们无法掌控的，如果今后类似的事情不断发生，而我们的每个系统中，都已经把相关的接口写死了，再出现问题时将会措手不及。于是，我们开始编写自己的短信转发网关，所有的应用都对接到我们自己的短信转发网关上，再由它利用外部通道将短信转发出去。
2013 至 2014 年中间的相当长的时间，外部短信通道一直处于非常不稳定的状态。由于工信部的整治，中国移动提供的 DIY 09 网关，只能把短信发送到提前手工预置的白名单中，而发验证码这种事情，怎么可能有白名单呢？我们也尝试了用安卓手机把接到的短信转发出去，虽然手机的无线网很不稳定，经常掉线需要人工干预，但至少大部分时候验证码能发出去了。
为了适应这种混乱的外部环境，我们在短信转发网关中加入了通道选择功能，就是当某个应用要发送短信时，首先利用高优先级的通道发送，如果不成功，就逐步向低优先级的通道切换。后来，互联网上重新出现了相对稳定的能够提供短信发送接口的服务商，我们的安卓手机就退役了。
到了 2015 年迎新的时候，由于统一身份认证账号注册要验证手机号，很多新生反映验证码接收到的速度太慢。为了解决这一问题，我们火速申请并开通了“云通讯”的相关服务功能，然后将短信转发网关与“云通讯”的接口进行了对接。云通讯是要求短信模板提前备案的，因此当时我们只用其发送验证码类短信，将其设为高优先级通道，再通过正则表达式判断是否符合其发送规则，符合的发出去，不符合的留给低优先级通道。
时至今日，利用云通讯之类的优秀的云服务已经可以稳定地发送短信了，但由于前面被折腾怕了，也因为短信转发网关上已经对接了不同业务部门的大量业务系统，我们就把这种模式保留了下来。
数据查询 API
2013 年的时候，随着门户系统建设的需要，我们开始梳理并建立共享数据库。最初的时候，只是在数据库里面建一些表，把一些业务系统中重要的数据利用 Kettle 抽取出来并进行清洗或转换，再存入我们设计的共享数据表格中。但当要利用这些数据的时候，问题来了，难道每个系统使用数据的时候，我们都要把所有的数据下发下去吗？
当时研究生院正在上线新的成绩打印机，我们在跟厂商讨论的过程中发现，他们的方案是在一台成绩打印机的控制机中，装上数据库，再用其它的成绩打印机连接这个数据库，打出成绩单。可这种实现方式，最大的问题就是我们需要把一套非常重要的数据，下发到一台平时无人看管的电脑中。如果这台电脑出现漏洞，或者被人拆卸抱走，那么数据也就随之彻底泄露了。
数据泄露与网站被篡改不同，网站被篡改最简单的解决办法就是拔网线、写检讨、承认自己很二，其恶劣影响总会慢慢消失。但数据一旦泄露，会在网络上产生无数个副本，甚至被放入黑市交易，其造成的影响将永远无法消除。在研究生院同事的大力支持下，厂商同意了只使用我们提供的数据查询接口做授权数据查询，并定制了打印程序。
利用这种方式，我们设计了一组简单的数据查询接口，接口本身并未使用 SOAP 协议，而是选择了直接使用 JSON 来表达，从而避免客户端对各种第三方程序包的依赖，也能降低开发人员调试程度的难度。各种应用在运行时，可以随时通过接口获得相关数据，从而避免了不少数据下发的实施工作。
核心数据的副本越少，相对而言也越容易保障其安全性。
规范化
经过数年的努力，随着数字校园建设的不断开展，学校的统一身份认证、短信转发网关、数据查询 API、校园支付网关等基础服务也逐步被开发并完善，从而无形中形成了一个相对稳定的基础服务层。与一般的应用建设思路不同，基础服务层所提供的数据和接口，必须经过仔细的设计，保证其可以适应绝大多数业务的需要。同时一旦接口发布，就不能再进行语义上的修改，否则应用系统必然面临大量的返工。即便前期设计不尽合理，也不能在原接口上进行修改，只能增加新的接口，并在原有应用下线后逐步下线旧接口。
为了能够让更多的合作厂商在开发应用时能够更方便地与学校的系统进行对接，也逐步规范我们自身的工作，我们整理了之前较为零散的文档，编写了《信息化方案：基础服务与 API》手册，并将随着系统的演进，不断丰富、完善其内容。
写在最后
与直接面向用户的应用开发相比，基础服务层的建设工作，是完全看不见的。有人会在意短信发出去了，却不会有人在意短信是如何发出去的。但也正是因为做了这些看不见的工作，应用系统的建设才能更简单，故障才能更少，运维才能更轻松。
应用系统，由于其数量众多，需求各异，想要做好的复杂程度并不比平台本身低。在看到行业内各个厂商所设计的水平参差不齐，问题层出不穷的应用系统之后，我们也开始摸索，有没有一种方式，能够让我们这样只有三四个人的小团队快速开发出业务部门需要的小系统呢？
数字校园实践系列
- 之一 《从构筑大系统，到编写小应用》
- 之二 《从虚拟化向容器化迈进》
- 之三 《看不见的基础服务层》
- 之四 《采购加自研的选择》
