一、行业背景

各高校信息化建设重视程度、发展先后、投资规模不同，大致正处于以下四个阶段：

u  业务系统建设期：业务管理信息化和教学手段信息化，教务系统、学工系统、财务系统、人事系统、科研系统、资产系统、MOOC平台、实验实训平台等。

u  数字校园建设期：面对业务系统建设期出现的信息孤岛推行的三大平台解决方案，统一身份认证，统一数据中心，统一信息门户。

u  数据校园建设期：在数字化校园基础上，开始思考如何释放数据的价值，开展的工作包括数据治理、数据服务、数据分析等。

u 智慧校园建设期：人工智能、大数据、物联网、云计算、智慧教室、VR虚拟仿真等，利用新一代技术实现教学和管理的智能化，目前正在探索阶段。

二、行业痛点

高校信息化发展至今，普通的问题是缺乏顶层设计，业务部门各自为政，信息部门相对弱势，系统建设没有可执行的数据标准，数据不互通，管理成本高，师生重复填报数据现象严重；

高校的非常典型的特点是涉及的业务范围广，业务系统庞大复杂，升级困难，导致系统得不到充分使用，造成数据不全面且质量差的普遍现象；

关于传统数字化校园思想，通过三大平台整合数据实施难度大，治标不治本，成果不明显，投资回报率低；

时刻面对网络安全和数据安全的重大压力，事故频发。

三、战略转型

在移动互联网、云计算、大数据等新一代IT技术的推动下，包括零售、金融、生产制造等各个行业的IT架构都在转型，高等教育行业自然也不例外。目前，很多学校已经开始了新一轮的信息化建设，针对以往的经验和痛点，对校园信息化的支持平台提出了新的要求，必须具备更加灵活敏捷的响应能力、要求具备更强的弹性和可靠性、要求更加安全可控、要求具备在飞行的飞机上更换引擎的能力，这种能力的源泉，就是微服务。

四、微生态系统的定义

实践证明，传统数字化校园三大平台的建设思路并不能有效支撑整个学校的IT基础架构，一个符合未来发展的信息化建设模式不应该是先放任再整合，而是引领自我生长、动态更新、绵延不断、可持续发展的生态。

微生态系统由众多的、弹性扩展的微服务构成，新的IT架构如何支撑起微生态系统的可持续发展，我们的实现手段是搭建基于API网关管理模式的微服务开发平台，对于学校各个应用系统的开发者，不仅能够快速调用其它系统API，自己也可轻松创建、发布、维护、监控和保护任意规模的API，使所有开发者受益。

对于学校信息管理部门，通过API网关可以保障系统间相互调用得到有效治理，降低运维成本，同时可以将越来越多的公共服务作为平台的接入标准，例如组织机构、人员信息、身份认证、权限配置、文件管理、流程审批等，逐步消除信息孤岛，同时实现应用的敏捷开发和快速迭代。

作为入口级平台，必须统一解决认证、鉴权、安全、流量管控、缓存、服务路由，协议转换、服务编排、熔断、灰度发布、监控报警等问题，实现高效率和高可用。

高校上云是必然趋势，5g必将颠覆传统意义的校园网，用户不能容忍为了安全而强行屏蔽外网访问校内资源，微服务开发平台可以作为一切校内敏感数据的坚强盾牌。

五、突破口

构建微生态一个重要的突破口就是移动应用，就如同微信的崛起是移动互联网背景下的必然产物，甚至夸张点说智慧校园应从智能手机开始。通过移动应用抓住用户，控制流量入口，增强用户与信息系统的粘性，在此基础上孵化开发各种校园应用服务，而这些各式各样、不断迭代的校园应用服务中各种纬度、鲜活实时的数据天然成为校园大数据的养分，由此校园信息化建设将进入良性循环的发展快车道。

从顶层设计角度，必须重新布局学校IT整体架构，学校领导以及各业务部门统一思想和深度协同，共同建设智慧校园新区。

六、卓云微生态系统架构

u  关于微服务

微服务是一种IT架构，或者叫设计思想。微服务架构在SOA面向服务架构的基础上，进一步消除了中心节点的耦合，采用完全去中心化的思想进行服务设计。简单的说：微服务就是一些协同工作的小而自治的服务。微服务的“小”，主要针对的是开发团队的规模，微服务更适合小团队，更便于组织和管理，降低软件开发过程失控的风险。微服务的“自治”体现在服务内部实现上，微服务之间完全通过服务接口通讯，服务之间完全解耦合，一个微服务的实现技术、采用的资源完全和其他服务无关，采用微服务架构更有利于选择最适合的技术和资源承载平台。采用微服务，不仅可以加速新业务的上线和迭代速度，还可以采取“绞杀榕”的方式安全的更新老应用、遗留系统，通过在旧系统前增加微服务，拦截并重新路由服务请求可以在不影响正常业务使用的情况下将老应用逐步使用一组微服务进行替换，当老应用的全部功能均由微服务覆盖之后，老应用即可安全下线，从而实现不间断服务引擎更换。

u  关于容器

容器不是微服务，但是容器和微服务是完美的一对，当你只管理5支程序怎么部署都可以，但数十支上百支呢，就需要一个运维管理解决方案。

容器最大的价值在于部署运维效率高。当业务微服务化后，势必部署运维更多的程序实例，容器解决的是服务的部署和资源的抽象问题，实现了微服务的自治性。Docker容器可以在物理服务之上部署，也可以在虚拟化服务器之上部署、也可以在公有云之上部署，借助于Docker容器，是否使用公有云资源将在微服务内部决定，与外部无关。

容器还有一个适合微服务的特点是支持服务发现和服务代理，不同容器之间可以通过注册服务表进行互相访问资源，这也满足微服务高复用的思想。

 u  关于API网关

容器是在部署运维上管理微服务，而API网关则是统一监控管理每个微服务的API以及调用关系，微服务化后，服务和服务之间一定会非常频繁地通信（而且是实时的），这就需要可监控可管理可调度，对管理者透明，在宕机时可以快速找到原因。在API网关中，认为微服务网关和API服务治理平台在实现层面上是一致的。如果系统层面将拆成了一个一个的微服务，那个API网关起到的就是微服务的作用；如果系统层面还是大的系统粒度，而系统间有一个API进行暴露和互相调用，那么API网关起到的作用就是微服务治理平台。