趙世浡　陶槊　董芳　鄒濤

摘要：文章分析了智慧高校建設中出現的各類問題及業務需求，并提出了整合校內現有各類數據與系統的解決方案。隨后，根據微服務系統架構與大數據分析的要求，重新整合共享數據中心，以適應高校業務系統的開發與應用。最后，通過具體開發案例說明了綜合平臺在高校自助一站式服務系統中的作用。

關鍵詞：微服務；云平臺；數據中心；Spark

中圖分類號：TP312 文獻標識碼：A

文章編號：1009-3044（2024）14-0060-03 開放科學（資源服務）標識碼（OSID） ：

0 緒論

當前世界各發達國家與機構都在深入研究教育智慧化，例如日本的“Society5.0”計劃旨在將虛擬空間與現實空間高度融合，實現學習系統的發展[1]；韓國的“智慧教育”項目MasterI-V也是如此[2]。歐盟在2018 年1月提出了“數字挑戰”，該計劃旨在推動教育系統智能化[3]。我國教育部頒發的《教育信息化2.0行動計劃》（教技〔2018〕6號）以及中國國家標準化管理委員會于2018 年6 月出臺的《智慧校園總體框架（GBT36342-2018） 》[4]規劃，都推動著各地高校積極推進智慧校園項目。本文基于高校智慧化建設中遇到的實際問題和建設經驗，進行了以下工作：1） 分析了高校信息系統存在的問題與制約因素，并尋求解決途徑。2） 在集中式數據中心部署高校核心業務，并基于云平臺架構實現數據與資源的整合與利用。3） 根據Spark系統，采用微服務架構，開發部署，聯通高校一站自助式綜合信息服務，實現智慧高校的業務智能服務與高效運營。

1 存在問題

1.1 通信障礙

1） 高校業務量呈爆發式增長，導致數據分析難度增加。存在“信息孤島”，缺乏統一指標和明確的技術發展路線，不利于深度利用信息。由于系統間接口的授權、標準、技術限制，教學教務、學工、移動支付/一卡通、后勤生活、安保監控信息無法真正打通。

2） 校際、區域間的信息管理與再利用仍處于隔絕狀態。

1.2 技術瓶頸

1） 信息利用質量不一，大數據分析范圍狹窄，尤其是在學工、教務方面的數據分析能力不足，導致許多高校開發的校情分析系統應用范圍有限，軟件生命周期短。

2） 5G移動應用場景不足，高校信息系統跟不上5G網絡帶來的高流量、多并發的業務流。

3） 大數據分析應用帶來了高校與個人信息隱私保護同高校教學與管理工作提升的沖突。

4） 在云環境、多節點分布式背景下，傳統的軟件開發模式或架構已無法適應多業務集成的應用模式，導致開發成本難以控制，代碼再利用率低下。

5） 復雜多變的高校業務導致各信息系統之間服務配套存在障礙，如在學工系統中，學生行為畫像不僅涉及校內教務、后勤安保、網上社群，還包括通信軌跡、消費等一系列數據處理。數據增多導致系統開發難度與響應時間增加，判定規則的漏洞和不確定性使得難以生成直觀結論。

6） 智慧化系統應用周期縮短，一站式服務難以對動態性外界環境或使用者形成“智適應”能力，需要不斷人為介入。主要問題包括校情分析、輔助系統的預測分析，掌握規則后很快被推翻；人臉識別被各種方式破解[5]。

1.3 關聯制約

智慧校園信息系統建設受到規模、技術框架、應用深度與廣度、后續變化等內外關聯因素的影響和制約，導致整個智慧校園建設與完善工作受到重重阻力。高校信息化系統與高校運作情況強關聯圖如圖1所示。

2 解決策略

2.1 數據整合

1） 數據與資源。在設施完善的基礎上，智慧校園建設必須實現校園信息的標準化與開放化，確保數據采集通識、通用和安全，實現特定標準格式對結構化、半結構化與非結構化數據進行收集整合與信息共享，從而提供接口保證數據的分布處理與流通，減少數據冗余，提高各類系統的處理效率。

2） 業務管理控制平臺。為配合高校業務時效性和多樣化，必須建立統一的高校信息業務管理與控制平臺。

2.2 基礎工具

目前市面上有開源與商業化產品，技術上有離線/批量處理、實時/流式、算法與人工智能共3 類路線，需根據單位的自身條件、業務需要和財力等進行綜合選擇。

根據高校業務分類的模式，選擇合適的開發工具。例如，根據一般院校的特點，采用openstack云平臺核心組件swift API，實現對異構數據的拓展功能管理與控制。其配套數據庫工具HBase用于HDFS分布式處理（如圖2所示），符合高校數據分析要求，通過row key檢索原始數據，實現高校集成業務系統的快速查詢、變更操作。

3 架構模型

通過建立適用于高校通用的數據模型，幫助院校進行信息化需求分析、方案論證、產品選項與維護管理。在實施過程中，大數據處理架構一般分為3個階段：概念構建、邏輯框架、物理表述，用戶可參照總體架構圖（圖2） 進行項目設計。

1） 概念構建。參考業務模型選擇數據模型組件，標準化區間，明確建設內容。

2） 邏輯構建。項目詳細設計階段，能推導出開發業務模塊對應的流程、業務條線、功能塊、場景模式等系統需求組合。

3） 物理表征。從代碼編制到系統的測試維護，可以直接以標準的物理標識來評估系統的運行情況，便于第三方接手。

4 微服務（Microservice）

隨著智慧校園自主一站式信息服務的流行，平臺上線的幾十個應用也造成了另一個困難，即多樣化的業務交互伴隨的自感知能力的不足，造成了終端用戶選擇的困惑或耗時。微服務可以幫助高校實現統一服務流程、門戶平臺，快速移動辦公和高校業務系統的貫通。

4.1 微服務模型

微服務是由一系列 API 驅動，在異構系統下運行不同語言開發的小型應用程序組，支持不同業務模塊互通。然后實現智能化識別與接入端點/服務模塊，包括與物聯網的信號同步與控制，自主學習運用工具/控件提煉處理離散化數據，最后實現彈性部署與便捷運維（DevOps[6]） 。它能實現多主體回路服務的關系模型，簡化了傳統信息系統的分層模式。

微服務有多種架構，如 Dubbo、SOFAStack、Heli?don、gRPC 等各有優劣[7]，目前高校因所有的業務系統還做不到全部用 Java 開發接口，所以還不能統一用Spring Cloud 架構來實現微服務業務整合，同時還要面對不同業務模塊之間的調用與互聯，只有考慮微服務網格（Service Mesh） 架構[8]，即將所有業務按服務單元實現分子化，統一 J2EE 架構各自開發，并支持PHP/C++/Python 等各類工具，所以可部署于網絡各個節點，彼此通過代理（Envoy Proxy） 實現交互，因此保證了整個系統的分散開放性與穩定性。

鑒于多數高校業務系統只需要在中小型機上部署，Docker 作為輕量級開源的容器（container） 框架與引擎[9]，既接受 VM 軟件管理，又可以讓 container 封裝高校各自開發、擴展或刪除信息系統；在 container 內既能實現多種開發程序并存，易于在各類云平臺上部署，也能支持異構系統移植，因此特別適合高校微服務應用開發環境。

4.2 高校微服務平臺設計

從圖3可以看出，在一站式微服務平臺的設計中，所有系統根據功能單元自動獲得任務，然后通知相應模塊完成流程。以學生入學為例，最基本的入住階段以BPMN（Business Processing Model Notation） 開始程序設計（如圖4） ，這樣就可以將復雜的系統設計分解成單任務模塊在各個子單元的實現，體現了微服務在云平臺設計中的作用。根據這一模式，分別完成整個校園一站式微服務平臺的全部結構設計與關聯（見圖5） 。

但在整個微服務系統設計部署中，需要面對各類數據、進程、事務的調用與同步，追蹤與檢驗。因此為簡化開發難度，可以考慮直接部署 Spark 系統實現整個微服務的協調工作（見圖5） 。即首先在數據中心HDFS 環境下搭建數據倉庫（Hive） 。在微服務集群根據 Zookeeper 同步分布進程間的 API 調用與消息發布。使用 MapReduce 從數據倉庫實現數據調用。通過 Azkaban 實現各服務間的部署，工作流的同步。在控制層上完成身份驗證，YARN 實現綜合管理控制，用 Sqoop 對數據庫實現遷移與轉換。具體到某個業務，利用 MapReduce 進行 MapTask 劃分緩沖區，Re?duceTask 收集/轉發，完成微服務。對自主服務后期使用 MLlib/Mahout 中間件直接應用智能開發。

5 結束語

智慧化校園的目的是為高校提供多樣化、便捷化、智能化的軟硬設施。然而，在實施過程中，必須根據高校特點選擇適用的服務架構與數據處理模式。在此基礎上，整合現有的資源平臺，通過微服務與Spark 架構的組合，完善技術和標準，特別是異構系統間的互聯，才能順利開發各高校自主一站式綜合服務系統，推動高校信息基礎建設的全面升級與創新。

參考文獻：

[1] 柴山昌彥.Society5.0時代的人才培養[DB/OL].（2020-08-07）[2021-02-15].https：//www5.cao.go.jp/keizai-shimon/kaigi/min?utes/2019/0327/shiryo_02.pdf.

[2] 吁佩.韓國教育信息化發展的經驗及啟示[J].科教文匯，2017（23）：59-61.

[3] European Commission. A Concept Paper on Digitization， Em?ployability and Inclusiveness： The role of Europe（2018-01-17）[2020-07-19] [EB/OL]. http：//ec. europa. eu. newsroom/docu?ment.cfm？doc_id=44515.

[4] 國家市場監督管理總局，國家標準化管理委員會.智慧校園總體框架：GB/T 36342—2018[S]. 北京：中國標準出版社，2018.

[5] 趙麗，韓朝陽 開通知網號“. 人臉識別” 的安全問題已經來了[N].法制日報，2017-09-19（5）.

[6] 耿泉峰，李曦，葛維，等.基于DevOps的軟件開發管理模式[J].軟件，2019，40（1）：93-96.

[7] 韓丹.基于DevOps的云平臺微服務架構可靠性分析[J].電子技術與軟件工程，2020（19）：174-175.

[8] YIN J， DENG S， WU J， et al. Research on Shared Service based on Loop-type relationship Model[J]. Communications of theCCF，2017，13（2）：18-23.

[9] 趙然，朱小勇.微服務架構評述[J].網絡新媒體技術，2019，8（1）：58-61.

【通聯編輯：唐一東】

項目基金：安徽省教育廳 繼續教育教學改革項目（2021jxjy054） 和安徽省高校教學實訓基地項目（2021jyxm1532） 和安徽省教育廳自然科學研究重點項目（2022AH052979）