一、行業背景

各高校信息化建設重視程度、發展先后、投資規模不同，大致正處于以下四個階段：

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網關起到的作用就是微服務治理平臺。