微服务和高校信息化建设
2019年9月份我和同事刘燕文在《中国教育信息化》杂志发表了一篇论文《基于微服务的高校信息化系统研究和实现》。
这实际上是我们在中国高等教育学会2016年度教育信息化专项课题的一个成果，在论文里面，摘要如下：
高校信息化系统基于传统三层BS架构设计，随着信息化系统的增加，运维难度加大，数据共享变得困难。本文分析了高校信息化系统存在的问题，认为在教育信息化2.0时代高校信息化下一代应当尽快进入基于API的微服务时代。本文介绍了开源API网关的选择和在高校使用场景下的配置细节，给出了API开发者应当遵循的最佳实践，并且对开源API网关缺失的统计和监控功能进行了补充。通过基于微服务的开发理念，使用自动化部署手段结合开源软件和少量编程搭建API网关，编写示例应用验证了通过解决微服务全生命周期管理问题，高校的信息化开发、运维将更加透明和高效，数据共享将更为安全。
随着课题完成，论文发表，玩过了，我对微服务从入门到放弃。说放弃太难听，暂停吧。为什么暂停？
为什么暂停
因为在目前高校的信息化环境，API网关实施难度较大。
在论文里，我们对高校信息化系统分成了2类。
高校信息化系统可分为两种类型，一种是类似教务系统、学工系统、人事系统、科研系统、财务系统等，这些业务系统业务较为复杂，业务大部分功能由业务部门管理员使用。另一种是网盘、即时通讯、自助打印等业务系统，这些业务系统定制化程度不高，功能较为简单，普通师生使用较多，有移动端，起步较晚。所以第一种系统一般采取高内聚的开发模式，由于管理员需要频繁查询调用数据，所以系统架构必须直接对数据库进行操作，数据在系统内流转，只有少部分结果数据需要共享给其他系统。而第二种相对独立，一般会采用技术更先进的API架构开发，同时支持多个不同客户端。
我们的建议是：
所以较为可行的方案应当是逐步迁移。对于第二种的系统，应当采购技术较为先进，有API开放功能的系统。对于第一种系统，如果无法整体迁移到API架构，也应当尝试对部分业务功能开发API。高校目前在广泛开展一站式服务门户网站建设[10]，一站式服务门户不再以业务来区分系统，而是以角色或服务来开发不同颗粒度的功能。通过管理功能和服务功能分开，面向管理人员的可采取原有模式，而面对受众较广的师生员工的功能开发出API，在一站式服务门户对外提供。
对于业务沉淀的数据，我们提出：
高校内数据可分为三种，第一种是公开的数据，诸如组织机构名称和代码，任何人应当均可通过API访问，第二种为需要权限获取的代码，诸如教务系统某位教师的任课信息，应当可授权比如人事系统调用。第三种为师生员工的个人隐私数据，诸如消费记录，成绩等，应当可通过师生员工显式授权后开放给第三方调用。通过API和OAuth2（Open Authorization v2，开放式授权第二版）的授权模式可以解决这些问题，促进高校内应用生态环境的健康发展。在提供API数据共享模式后，原有的包括离线传递、数据库视图开放、共享库同步也不会消失，以上三种共享方法也会存在一定的使用场景，因为API倾向于传递较小的数据量，对于需要获取大量数据进行实时或离线分析不存在优势。
道理大家都懂，但是真正要落地，还受高校的信息化模式限制。
高校信息化部门
最大的问题在于，高校的信息系统很多都是由不同外包公司开发的，他不像互联网公司，有一个非常大的基础部门提供各种能力，提供包装成中台的能力，直通内部开发者，有非常强的将各个业务纳入到微服务架构的能力。
很多高校走过一条路，不能说是弯路，就像你吃10个馒头饱了以后，你说我能不能只吃那第10个馒头？不行，前面的坑你也必须踩过。
最最开始，很多高校的业务系统都是业务部门自己开发或者买的。
后来，很多高校对所有信息系统大包大揽，上线信息化一期项目，包括多个业务系统，统一招投标，由信息中心部署实施，跟踪进度，参与业务调研。业务部门只需使用，其他都不用管。这保障了系统部署和技术质量，然而也存在问题。
- 业务部门没有专业的计算机技术人员。业务部门只有行政人员，就算有，也只是行政编制做技术的活，人员会流动，对该人员的上升空间造成一定影响。
- 业务部门参与度不高，使用系统意愿不高。系统不是由最终使用者选型。业务部门验收没有压力，导致验收困难，系统实施进度很慢。
- 信息中心工作量大。一个人负责多个业务系统，部署和协调，导致每个都不精。安全压力大，安全遵循“谁主管谁负责，谁使用谁负责，谁运维谁负责”，安全责任不清。
于是很多高校的信息部门开始使用另外一种模式，分成信息办和网络中心，信息办负责统筹整个学校的信息化建设，网络中心和业务部门平级（平级？），由各个部门向信息办提系统建设需求，信息办负责专家评审，明确系统建设缓急程度和预算分配。
网络中心变成提供支撑能力，提供虚拟化环境，提供统一身份认证，提供数据库，提供共享数据，提供数据标准，提供平台，提供基础安全能力，提供安全规范，提供技术支持，提供安全扫描通告和管理，回收业务数据。
技术支持的意思是，我知道怎么做，我可以告诉你怎么做，但是你得自己做，你得躬身入局。
这种模式可以快速建立信息系统，业务部门如无技术人员，可以在采购合同将系统维护外包给公司，安全责任清晰，使得业务系统遍地开花。然后这也存在一些问题。
- 部署质量不高。
- 技术先进性和安全较弱。
- 信息部门对业务的把控能力减低，体现在标准不一定采纳，拿数据有壁垒。
天下大势，分久必合，合久必分，不存在一定哪个模式最优的情况，只有最适合自己学校的情况。
在这种情况下你希望各个业务部门都以微服务架构构建信息系统，纳入整个学校的微服务网关，很难。
外包公司
对于学校来说，主要目的是以信息化助推学校业务开展，至于这个业务系统是由外部公司还是内部信息化部门人员自行开发的不太关注。实际上自行开发存在较多问题，业务不熟悉，看得不够多，也存在安全问题，独立开发者，轮子从头建，没有开发学习氛围，其他事情多，都会影响开发质量。而且成本也高，因为信息系统开发完，如果不去复制，是很难摊薄成本的。所以学校自行配备开发人员成本是非常高的，而且效果不佳。
所以高校很多都是买产品，引入教育大厂，外包公司，行业内就那么几家，大厂大了以后，转身就很难，需要考虑很多东西，历史包袱太重。（题外话，有些大厂，为了提高开发速度，自行开发了快速构建中间层，然后发现框架存在较大安全漏洞，很悲剧，到目前还有很多学校在用这些有很大安全隐患的产品。）
如果有一家外包公司，以DevOps开发，以k8s操作系统，引入容器，要进入高校，他也会遇到问题。
很多高校的机房数据中心只有虚拟化架构，还未建立容器云，如果他们要部署，需要自己从头建立k8s，自己运维。每个外包公司的容器云，变成了类似信息系统一样的孤岛。
DevOps掺和进来后，理论上开发者是要直接参与到学校机房数据中心内部署的。使用微服务后，服务运行过程的数据量大大增加，可监控项增加，对运维能力的要求更高，人员需求更多，很多学校的信息中心人员数量和技术能力无法满足。
基于API的微服务架构可以改变传统烟囱式架构在部署和扩展方面的局限性。微服务各个服务可以独立部署，服务可以使用不同的语言和数据库开发，对外隐藏实现细节并独立的演化。然而新技术也会带来新问题，微服务服务数量增加，服务之间关系复杂。从微服务的开发、测试、部署、接入服务平台、验证、授权、访问频率控制、缓存、状态、监控、熔断、日志、版本化、服务终止等一系列全生命周期管理问题需要研究。
这是一个鸡生蛋还是蛋生鸡的问题，高校机房数据中心发现没有容器云的需求，就不会投入技术储备来研究和实施，而外包公司发现高校没有容器云，也不会基于容器来开发，还不如自己独立一个高内聚的部署架构。导致容器技术很难落地。
大连海事大学将大部分业务打包成容器发布，这是一个很好的尝试。
未来一定是微服务的天下
虽然说了这么多现状，但是未来一定是微服务的天下，是软件开发进化的必然结果。
微服务的好处大家都知道，微服务实际上将软件开发从宏观进入了微观领域，纳米级。
《Ant Man》, 2015
以前我们调试单体应用，必须起类似gdb的调试，非常繁琐，而且无法事后追踪。或者使用控制反转或依赖注入到处使用埋点。但是微服务依托Web等架构，有日志留下，开发和调试运维过程有更标准化的通用工具。
微服务将共享范围大大扩大，使得软件分层和分工越来越细。基于API的操作，将对共享数据的操作更加规范和可控。仿佛这个世界的软件开发本来应当就是这样子的。
上海海事大学王玉平，说了《云原生宣讲：再议云原生在高校的应用 》，华东师范大学冯骐和沈富可发表了《高校能力开放平台中的API网关设计与实现》，2014年我发布的论文，谈到了数据中心代码化的实践，2017年我在武汉大学分享了《DevOps在重大活动网站安全保障中的应用》，这些的前提都是，你是开发者，受制于运维的繁琐，想要自动化，对底层更可控，你需要做些改变，把触角往外伸。如果你只是采购一个产品，除非产品本身进化完成，否则你只能接受，使用他。
所以微服务，目前看起来要在高校落地，还有一定难度。