微服務的概念由Martin Fowler和James Lewis於2014年共同提出，它是一種軟體架構思想，將單一應用程式拆分為眾多的小型服務組件進行開發，其中每個服務組件擁有自己的進程和通信機制，可實現自動化輕量級獨立部署，且各個服務可通過不同的程式語言實現並使用不同的數據存儲技術。
高校信息化發展已進入智慧校園建設階段，但制約其快速發展的一個重要因素即是數據，部分高校已經建設了統一的中心化數據平臺並提供數據服務，然而效果並不明顯，主要表現為以下幾個方面：1.信息系統分散，核心業務數據同步至中間庫（共享庫）滯後或者無法獲取；2.數據質量不高，數據更新不及時，形成斷層現象，導致數據不一致；3.業務部門缺乏安全意識，數據洩漏或線下傳遞現象頻發；4.重複的硬體成本投入；這種中心化的建設方式在數據準確性、及時性及系統的擴展性和易維護性等方面均難以滿足智慧校園建設對數據服務的要求。
本文從高校信息化建設自身特徵出發，基於微服務架構思想，採用分而治之，集中監控管理的方法，構建分布式數據服務平臺（DaaS），規範數據接口和數據來源，為應用系統、移動應用等提供權威的數據保障，助力智慧校園快速發展。
平臺設計方案
服務劃分原則
要實施微服務治理，首先面對的問題如何劃分業務從而實現服務化，基本的解決思路是拆分和分層。拆分的策略有兩種即橫向拆分和縱向拆分，橫向是指根據業務域進行，從而形成獨立的業務微服務集群。縱向是指針對某一模塊或組件拆分形成獨立的原子服務。分層是指梳理、抽取核心或者公共的原子服務下沉至核心或公共服務層，逐步形成穩定的底層服務。其次是拆分的粒度，這是服務拆分的難點，微服務架構也是循序演進的過程，可參考以下原則：1.功能完整，職責單一；2.API版本兼容性優先；3.迭代演進，團隊可接受。
業務梳理
高校業務系統的建設質量參差不齊，大部分業務系統管理嚴謹，數據完整，接口規範，能獨立向外提供數據服務。相反，部分業務系統在數據和對外接口方面均不完善，形成了數據孤島。針對高校業務系統的現狀和數據的提供源，本文將微服務數據平臺的服務分為兩類：原生型和代理型。原生型是指業務系統本身不對外提供數據接口服務，基於微服務技術進行開發集成，數據源直接取自（非）關係型資料庫。而代理型是指業務系統已有基於SOAP協議的WebService服務，將其封裝註冊至微服務組件中。
架構設計
如圖1所示，本文構建的微服務分布式數據平臺主要包括三個部分：數據源、微服務組件、數據管理平臺。
數據源是微服務事實的實際數據提供者，從資料庫種類上分，既有關係型資料庫，也有非關係型資料庫。從來源上分，既有實際的業務資料庫，也有基於數據同步機制的傳統共享庫。實際業務庫主要提供實時的數據來源，如統一認證庫、人事資料庫、一卡通帳戶等，而共享庫主要提供離線的數據分析，將分析結果對外提供數據服務，如科研成果、一卡通歷史消費、論文數量等。
在微服務架構設計中，需要核心組件作為技術支撐，包括：1.服務註冊中心，主要實現服務的註冊與發現，微服務之間通過註冊中心彼此感知，同時從註冊中心訂閱自己需要引用的服務。2.服務網關，它是外部調用數據的唯一入口，對外屏蔽系統內部結構，提供動態路由、監控、授權等功能。3.容錯機制，每個微服務一般會有多個實例服務提供服務，為保證服務高可用，需要提供負載均衡及熔斷機制。4.統一的配置管理，提供集群中心化的統一集中配置，簡化開發和運維的繁瑣。5.日誌和監控管理，微服務是獨立的服務組件，種類和數量繁多，需要通過日誌和統一管理界面監控各項指標及出錯的鏈路跟蹤。
數據管理平臺主要負責對平臺的界面化統一管理，包括微服務節點狀態監控、應用授權、開發者帳號授權、標準化文檔維護等。
技術實現方案
通信協議
本文設計的微服務平臺採用輕量級的通信規範，微服務之間的通信遵循REST風格，而數據交換格式採用JSON。對於REST及JSON的相關概念，本文不再贅述。基於這種風格的通訊機制，與傳統的基於SOAP和WSDL的服務相比更簡潔。
技術框架
目前實施微服務架構可供選擇的方案有Dubbo和SpringCloud，前者是開源的服務治理框架，服務調用方式採用RPC，是實現微服務的基礎組件，對於微服務涉及的其他必要組件未必提供。而SpringCloud是由Spring開源社區提供，整合了現有的服務治理的主流技術，包括服務註冊中心（Eureka）、網關（Zuul）、配置管理（Spring CloudConfig）、消息總線（Spring CloudBus）、負載均衡（Ribbon/Feign）、熔斷器（Hystrix）及一些工具包，比如數據流操作工具（Spring CloudStream）、安全工具包（Spring CloudSecurity）等，覆蓋微服務實施的方方面面，底層基於SpringBoot技術，天然的支持RESTful風格。
平臺實現
基於SpringCloud微服務框架可方便的構建出數據平臺的原型，如圖2所示。每個獨立的微服務均提前註冊至註冊中心（EUREKA），客戶端的請求通過網關（ZULL）分發，根據請求接口路由至相應的微服務，對於每個微服務一般會有多個節點，採用Ribbon做負載均衡保證服務可用，而Hystrix做熔斷器來避免服務調用的雪崩現象，集群的統一配置文件通過配置中心及時更新實現。
為保證微服務之間接口調用的安全，需要進行服務之間的身份認證。簡單的做法可以使用IP位址段隔離來保護被拆分的服務，適合於短時間內迅速遷移服務的場景。從長遠來看，此種方式存在局限性，對網絡架構存在依賴性，故本文設計的架構中採用JWT（JSON Web Token）方式進行身份認證，客戶端的請求經過網關時會向授權中心（AUTH）請求JWT，當實際請求到達某個微服務的時候，微服務會向授權中心獲取JWT驗證是否是合法的請求。同時授權中心還承擔給應用授權的任務，一般新申請的應用授權中心會分配一組App ID和App Secret，通過數字籤名和驗籤的過程來校驗應用的合法性。
根據實際業務出發，本文設計的微服務分為兩種，一種是公開信息類服務，另一種是受限類服務。前者是指無需數據擁有者授權即可使用，此時只需申請的應用在授權中心註冊即可，比如通知公告類，本身新聞數據是對外公開的，為防止接口的惡意調用，只需對應用進行授權驗證即可。後者指的是私人敏感數據，需要數據擁有者授權後方可使用，比如課程、成績等，該服務基於Oauth 2.0協議，配合學校統一身份認證平臺實現，用戶一卡通號和密碼經過統一身份認證後，授權給第三方應用使用數據。
數據安全管理
數據安全是高校信息化建設過程中一直面臨的問題，主要原因在於業務系統分散管理，業務部門對數據的安全性重視程度不夠，作為私有財產保護的同時缺乏技術手段進行管理。數據安全管理需要技術和行政手段共同發揮作用，本文構建的分布式數據平臺從技術層面進行統一規範管理，基於授權認證機制保證數據的相對安全。在業務系統作為微服務接入數據平臺的過程中，對資料庫帳戶密碼安全性、授權範圍、防火牆配置等方面進行規範，而對於使用數據的開發者，平臺通過註冊授權方式指定特定數據接口的使用範圍、使用期限，遵守接口文檔的使用規範，開發調試期間數據經過脫敏處理。而行政管理手段，首先是健全數據管理隊伍，學校層面大力支持，信息化部門和二級單位積極配合，明確實行數據共享的意義。其次對數據使用者而言，按照「誰使用，誰負責」的原則，在嚴格履行數據使用申請、審批、籤署保密協議的基礎上，信息化部門還要加強數據的使用監督和安全風險提示，對存在安全隱患的使用方式停止數據提供。
微服務數據平臺不是對原有數據倉庫或共享庫的顛覆，而是有效補充，原有的數據中心或者數據倉庫是離線數據挖掘和分析的重要數據源，是微服務數據平臺重要的數據支撐。從實踐效果來看，平臺服務鬆耦合，易擴展，數據共享靈活，運維方便，是構建統一數據平臺強有力的技術手段。（責編：楊燕婷）
（作者單位為江蘇大學信息化處網際網路與計算技術研究所）
本文刊載於《中國教育網絡》雜誌2018年6月刊