精彩報告 | 中山大學何海濤：微服務架構下的教務管理服務建設分享

何海濤（中山大學 網絡與信息技術中心主任）

尊敬的信息化建設同行們，大家好！

我今天要分享的是中山大學如何用微服務這種新的技術架構去改造教務管理系統。

我的報告分為三個部分。

第一，我們是怎麼看待這件事情，怎麼選擇這條道路；

第二，前進的過程中，我們遇到了什麼問題；

最後，目前取得的一些效果。

進化之路上的關鍵詞，我的理解就是Transform，也就是變革。

其實每個學校都有教務管理系統，應該說在整個校務系統中，教務管理系統是我們信息化部門心中的一個痛點。

中山大學最早從1998年開始使用教務管理系統；

2003年我們在做數字化校園一期項目時選用了希爾的系統；

2010年，因為學分制等一些新的業務需求，我們開始使用東軟的系統；

2015年，我們借着學校要在管理學院做全學分制試點的機會，重新打造教務系統。在這個節點上，我記得當時和聯奕是有合作機會的，卻因為各種原因失之交臂，但現在看來，當時的失之交臂反而換來了今天的回頭一眸；

2017年，我們和聯奕合作，開發基于微服務架構的完全學分制本科教務管理系統。

從這裡我們可以看出，中山大學教務系統的整個發展曆程，基本是七年一個換代。2015年這個節點其實是做一個試點，當時我們嘗試将選課這個痛點剝離出來，變成一個外挂的形式，也取得了良好的效果。

總的來說，教務管理系統對學校來講，是衡量信息化管理水平的一個标尺。

随着學校教務的發展，業務在不斷變化，需要把需求調查清楚，才能開始做信息系統。實際情況是，我們的技術架構在适應業務發展的時候遇到很多矛盾，所以才會出現在七年就發生一個大的升級，推倒重來，要不就是苟延殘喘勉強維持，不斷打補丁，使得最後的體系架構越來越龐大，直到實在沒辦法還是推倒重來。

傳統的架構都是緊耦合，每個功能的業務和數據都是緊耦合的，任何一個業務功能出了問題，就導緻數據服務産生問題，從而牽一發動全身，教務系統整個出問題。

教務系統的痛點大家都能感受到，比如從用戶的角度來講，操作體驗差，因為架構太老，一個系統用了七年後怎麼可能會适應現在用戶的要求。從老師的角度來講，系統架構太老，成績錄入時經常丢失數據，還有選課宕機，業務變更頻繁，工作效率低等。

如何解決這些問題？我們必須要進行體系化的、系統化的全局的變革。

非常幸運，2016年在醞釀這件事情的時候，經過研判，我們覺得在這個時機用微服務這種新技術新方法論來支撐教務系統的重構，這個探索是非常有價值的，成功的概率也會比較高。我記得當時跟聯奕做過一個簡單的溝通，大家取得了很多共識，于是就決定從學校最難的教務系統開始幹，我覺得這樣更具有挑戰性或者示範意義。假如這個實踐能夠取得一點成果，也是中山大學對教育信息化行業所做的一點貢獻。

我們從開發流程、應用架構、部署技術、基礎設施等方面進行全面探讨，來朝着微服務化去遷移。技術和服務的“超融合”，其實這個“超融合”，“融合”非“耦合”，從另一個角度來講，是業務和業務之間、業務和數據之間充分解耦才能實現的。

從整體的設計層面來講，我們在反思為什麼以前的教務管理系統做不好。

首先是因為教務系統的體量特别大，但從信息化部門來講呢，我們認為頂層設計做得不是很好。傳統的做法，需求談得很多，但是設計方面一直沒有一個很好的方法論和實踐。所以我們當時在做教務系統的頂層設計時，開始引入基于信息資源規劃、技術架構規劃、環境保障規劃的思路，另外在技術層面，運用原生雲架構設計，以及微服務架構設計。

從業務的框架設計上來講，我們開始分職能域、業務大類、業務過程、業務活動等，當然了，在傳統的教務系統設計過程中這個也會去做。另一方面，傳統的教務系統在設計的時候，通常是從教務管理人員的角度去看問題，并沒有從用戶角度去看問題，所以這次我們從用戶視角，将用戶分為教務管理員、院系管理員、教師、學生這麼幾個角色，落到具體的域中，他們所做的工作，從而來做用戶模型的設計。這種設計就使開發人員更有全局眼光。

在具體的技術方面，微服務、Docker，DevOps都已經落地了。

從整個中山大學的教務系統來講，我們是計劃分成三期來建設，2017,2018,2019三年來完成。今年是第一年，第一階段我們總體上還是打基礎為主，包括做基礎數據、學業預警、學籍管理（大部分）、系統管理、系統框架及過渡方案設計等。最難的是明年第二階段，相當于攻堅階段；後年第三階段我們希望是優化階段。整體按照數據-模塊-服務的步驟來走。

這張圖就充分體現了微服務解耦的過程，任何一個服務都是獨立的。

由于大家都是從傳統的開發方式轉向微服務，我們的設計人員、開發人員在這個過程中都犯了一些看起來很低級的錯誤，但也為我們積累了很寶貴的經驗，那麼這些坑，希望别的學校再去實施的時候不會再遇到了。比如說，開始設計時，我們每一個職能部門每一個服務都有一個獨立的數據服務和接口，後來在做的過程中發現這樣太複雜了，于是又專門分出來一個外部接口支撐領域，使得新系統無需依賴舊系統數據，隻需調用外部接口服務，就可以解決新舊系統數據耦合的問題。從傳統的去中心化，從集中式變成分布式，對技術架構的要求更高。

從目前我們所看到的效果來講，對學生來說，選課和成績查詢是最重要的，但我們希望學生在進入大學時，就能看到自己的課程地圖，來幫助他對自己的學業路徑進行規劃。另外在過程中提供可視化信息，方便學生實時掌握學業情況。而當學生在學業上出現狀況時，及時預警學生，并同時反饋給家長。

我作為一個技術人員，實際上我們網絡信息中心更多的是做一些技術支持，比如說運維，技術架構這一塊。傳統的信息系統在開發的時候往往隻考慮了開發，而開發和運維之間是相互脫節的，導緻了很多信息系統在設計時看上去很美好，但是一上線，就帶來性能和服務方面的問題。那我們基于DevOps框架理念下，開發和運維可以說是同步進行考慮的。

我們采用容器的方法之後，基于K8S的容器調度，有彈性伸縮特性，解決了很多人力問題。最典型的就是負載均衡，正常情況下負載很低的，那我們看怎麼伸縮，當業務量變大的時候，兩個實例頂不住了，這時候自動地就有新的實例起來，去分擔業務壓力。這都是架構和框架所支持的，不需要人工幹預。當選課人少了，自動會縮減實例。這就是彈性伸縮。

如果某一個業務宕掉了，那麼這個業務會自動地遷移到别的機器上去，動态遷移完全不是靠人力去做的。

微服務架構在教務信息化這個領域的實踐還非常少，我們在開發過程中也遇到過很多問題。

比如領域拆分，這個服務到底拆得顆粒度有多大，是蠻難的一個問題，也是一個反複試錯的過程，但是這個彈性的敏捷的架構，使得我們試錯的成本會比較低；

第二個困難就是綜合查詢，因為很多數據以前是集中的，現在開始分布化的，分布化之後就帶來分庫分表查詢效率的問題；

第三個就是數據不一緻的問題。這也是從集中式變為分布式之後所帶來的一些必然的問題。對業務來講，到底“大本科”是什麼樣子，業務在不斷變化，對技術來講，微服務和容器，如何實現業務和技術的融合，如何通過适度的解耦來實現“超融合”，這也是一個很難的話題。但我希望能通過我們大膽的嘗試，改變大型信息系統總是要推倒重來的現狀，使得不斷“拆了吧”的狀态一去不複返。

謝謝大家！

（以上内容為現場實錄）