基于微服務架構的智慧校園公共軟件平臺建設

0 引言

智慧校園公共軟件平臺主要包括統一認證、統一門戶、數據管理平臺三大部分，其中統一門戶與新興的網上辦事大廳呈現融合態勢，發展形成融合服務門戶，并具備移動端服務能力。隨著智慧校園上述平臺的功能不斷豐富，軟件架構也愈加復雜，傳統的單體服務架構在快速響應業務變更、獨立維護升級、高效部署擴容方面的不足逐漸顯現。微服務架構是近幾年新興的一種軟件設計架構，由傳統的單體架構基于服務化理念發展而來，其核心思想是將整個業務系統拆分為相對獨立的業務模塊，各個微服務都可以獨立開發、獨立測試、獨立部署、獨立運行、獨立運維[；能夠快速響應業務需求變化，從而提升運維質量，降低運維成本，提高資源利用率，實現能力共享[2]。其架構示意圖如圖1所示。

1技術發展趨勢

1.1 微服務架構

微服務架構是2015年左右隨著互聯網應用的蓬勃發展逐漸興起的。傳統的單體架構在系統升級時需要中斷業務部署服務器端應用程序的新版本。微服務通過標準化的業務API實現功能，采用松耦合的設計原則，允許服務的所有者自由實現并更改基于API的數據處理或者組合服務系統，消費者不會受到服務內部實現變化的影響[3]。同時，微服務架構可以根據應用的需求動態擴充服務資源，具有很強的伸縮性[4]；由于各模塊之間相互獨立，當架構中某些模塊產生故障時，其他模塊仍可正常運行，具有很高的容錯性[5]。目前主要的微服務開發框架包括Dubbo 和 Spring Cloud 等，Spring Cloud以豐富的組件工具和更完善的生態體系成為了業界主流，能方便地構建健壯的分布式應用，處理服務注冊發現、配置管理、負載均衡、熔斷等常見問題。SpringCloud支撐了微服務應用的開發，容器技術則很好地適配了微服務應用的部署。容器可以把應用及其依賴封裝到一個輕量級、可移植的鏡像文件中，鏡像保存著容器運行所需的運行環境及其配置信息[6]。Docker是目前主流的開源容器引擎，具有良好的輕量化、隔離性和高資源利用率的特征。在大規模復雜應用場景下，容器的管理工作也會變得更加困難，可以依靠Kubernetes（簡稱K8S）進行容器管理，K8S是一種容器編排工具，可以快速進行容器部署調度和節點集群擴展。另外還可以使用Rancher快速搭建K8S集群并實現K8S的圖形化界面操作，進一步降低微服務系統的運維管理難度。

圖1微服務架構示意圖

1.2智慧校園公共軟件平臺

智慧校園公共軟件平臺主要包括三項。

1）統一認證平臺。統一認證平臺可實現用戶在系統間的單點登錄功能，解決的是傳統模式下多個應用采用不同界面和用戶信息進行登錄的問題，主流的技術手段是通過CAS、LDAP、OAuth等協議使各系統均通過統一認證服務器進行身份校驗，同時為不同用戶分配相應的信息服務權限，既可以保證智慧校園的整體安全性，又凸顯了智慧校園精細化服務的特點[7]。

2）統一門戶。統一門戶是第三方應用的匯聚平臺，使得用戶通過一個入口即可快速訪問所有應用。近幾年隨著政務數字化建設逐漸發展起來的網上辦事大廳也在高校中逐漸普及，主要技術路線是通過Activity、Flowable等流程引擎，基于BPMN等國際標準，通過圖形化操作界面快速構建流程類的線上服務。網上辦事大廳在發展過程中逐漸和統一門戶融合，形成新形態的融合服務門戶，方便了用戶的訪問。

3）數據管理平臺。數據管理平臺是實現數據共享和數據分析的基礎工具軟件，主要功能是實現數據的采集、清洗、管理、開放、分析等功能，依托數據管理平臺，通過數據治理活動，最終構建學校的數據資源體系。

2系統架構設計

2. 1 設計思路

基于微服務架構的軟件設計核心是做好服務的拆分，將復雜的應用系統按照功能點拆分為一組獨立的小型服務，服務之間通過標準接口互相調用。在服務拆分過程中應當遵循如下原則。

1）高內聚每個微服務應當聚焦完成單一功能，服務之間應當有清晰的任務邊界，小型化的功能單元有利于加快開發速度。

2）低耦合：服務之間通過輕量化接口（如HTTP接口）進行互相調用，單一服務功能的變更不影響其他服務，有利于后期獨立進行迭代和維護。

3）獨立自治：每個服務都可以獨立進行開發、測試和部署，不同服務可以基于不同的技術路線來實現，從而進一步提高開發工作效率。

基于上述原則，在智慧校園公共軟件平臺的功能解耦規劃方面按照如下思路進行。

1）進行“管服分離”，即將面向后臺管理和面向用戶服務的功能進行拆分，分別進行規劃設計。

2）按照功能要素或業務流程進行拆分。在面向后臺管理的功能方面，可以按照管理內容、管理權限和管理安全三個維度分別進行規劃設計；在面向用戶服務的功能方面，可以按照內容展示、檢索查詢、集成對接等不同的要素進行獨立設計。

3）可以按照功能執行模式進行拆分，比如數據庫初始化等一次性執行任務或周期性執行的同步任務可獨立規劃。在軟件開發環節，各微服務交由不同的開發團隊進行開發測試。在部署環節，應當采用集群方式進行高可用部署。

2.2 總體架構

系統總體架構如圖2所示，自下而上共包括六層，分別是基礎資源層、容器平臺層、業務服務層、服務治理層、網關層和用戶接入層。其中基礎資源層是指系統依托的基礎網信資源，在高校場景下多為校園私有云，所依賴的資源主要包括基礎計算存儲資源和數據資源，本系統建設時采用了CentOS7.6操作系統和MySQL8數據庫。需要說明的是在微服務架構環境下，輕量化服務可以自身集成數據存儲，但在重型業務系統中還是推薦使用更加穩定的集中存儲，也更有利于實現微服務的無狀態。用戶接入層是學校師生最終使用系統的訪問入口，包括PC端的Web、移動端的H5、原生App和依托第三方平臺的小程序與服務號等。除上述兩層外，其余四層為核心設計部分，下文詳細闡述。

2.2.1 容器平臺層

容器平臺層是在數據中心提供的計算資源之上構建容器運行環境，以承載上層各項微服務，本系統設計中選擇了主流的容器環境構建工具，包括容器引擎、編排工具、管理平臺和鏡像倉庫四個組件。容器引擎Docker是將宿主機的資源進行虛擬化，包括CPU、內存和磁盤等，為每個容器的運行提供隔離環境，包括擁有獨立的進程空間和文件系統等，從而實現高度的可移植性。容器編排工具K8S主要有兩項功能：一是實現容器的自動化部署，并可在線進行升級和回滾等操作，可在集群中動態調度容器；二是能夠根據應用的負載情況彈性擴展或者收縮容器副本數量，從而靈活地應對應用負載的變化。管理平臺Rancher主要實現三項功能：一是提供K8S集群的Web界面管理，通過圖形化界面進行容器的操作；二是實現多集群的管理，包括生產集群和測試集群的統一管理；三是提供身份認證和監控功能，確保合法用戶訪問K8S集群，同時對集群的狀態變更提供日志記錄等功能。鏡像倉庫Harbor是容器鏡像的管理平臺，雖然可以使用公有云中的鏡像托管服務，但是自建企業級鏡像倉庫是更加安全和通用的做法，Harbor支持對鏡像進行統一的存儲分發、復制刪除等操作。

2.2.2 業務服務層

業務服務層是智慧校園公共軟件平臺的功能實現層，可拆分為兩部分，分別是公共基礎服務和業務功能服務。公共基礎服務包括消息隊列RabbitMQ、數據緩存Redis、文件存儲NFS（NetworkFileSystem）和對象存儲Minio，其中RabbitMQ和Redis也以微服務的形式通過容器運行。消息隊列是為各微服務間通信提供基礎能力，支持異步處理和高并發場景，本系統中用戶認證信息的處理、用戶信息的變更、用戶消息的發送等服務都通過消息隊列形式在相關服務間進行通信。數據緩存Redis是內存數據存儲技術，通過將常用數據存儲于內存中從而減少磁盤讀取，提高數據處理效率，本系統中用戶的在線狀態和基本信息、融合門戶中的應用服務列表、第三方應用的身份令牌信息等高頻使用數據都依賴Redis的存儲。NFS和Minio都是非結構化數據存儲，其中文件存儲NFS主要用于存儲容量較大、訪問速度要求不高的文件，包括視頻、數據標準、數據文檔等內容；對象存儲Minio主要用來存儲低延遲、高吞吐的非結構化數據，本系統中主要存儲人臉數據，用于支撐移動端登錄、門禁、考勤等高并發場景下的人臉識別服務。

業務功能服務是三大平臺的核心功能按照微服務思路進行的功能單元規劃，需要說明的是由于篇幅限制，本文僅闡述功能的一級拆分思路，在實際開發過程中基于本系統設計原則進行進一步的細化拆分，以實現原子化的功能開發和部署。

統一認證平臺功能從以下四個方面規劃。1）后臺的用戶和權限管理，也包括日志和報表的管理;2）對接第三方提供的統一認證服務，包括CAS、OAuth、LDAP等常見協議和認證方式的支持，以及應用的管理和鑒權等；3）認證安全服務，包括認證安全策略設置和異常告警；4）消息服務，支撐用戶通過驗證碼方式登錄，同時面向第三方系統提供消息發送能力。融合服務門戶功能從以下四個方面規劃。1）門戶的前端服務，包括首頁、服務中心、日程中心、資訊中心等功能；2）門戶的移動端服務，包括H5、小程序、App等;3）統一流程服務，包括表單設計、流程設計、監控統計等；4）門戶后臺管理，包括應用發布和主題管理等。數據管理平臺功能從以下四個方面規劃。1）數據采集，包括交換作業設計、管理和監控;

2）數據治理，包括數據確權、模型管理、質量管理等；

3）標準管理，包括數據標準和數據代碼的管理

4）數據共享，包括面向用戶的數據門戶、數據接口管理、權限管理等。

2.2.3 服務治理層

服務治理層負責各微服務的有序協調組織，本系統設計中選用目前最流行的SpringCloud作為服務治理框架，SpringCloud 涵蓋了微服務架構的完整技術棧，在服務注冊發現、限流降級、配置管理等方面均提供了多種可選技術。本系統在服務注冊方面采用Eureka，服務提供者將自身服務信息（IP地址、端口、服務名等）注冊到EurekaServer中，并通過心跳報文維持服務的存活狀態，服務消費者向Eureka查詢服務列表并以一定的負載均衡策略選擇服務提供者。在服務限流降級方面采用Hystrix，當服務多次調用失敗時，Hystrix即啟動斷路器，為后續調用快速返回失敗狀態，避免資源的浪費和故障的蔓延，同時還可以啟用備選方案實現服務降級，保障系統基本功能的可用性。在服務配置管理方面采用Spring Cloud Config，基于微服務架構的軟件由于服務數量非常多，配置項復雜且難以管理，使用配置中心可以集中對各服務的配置進行版本控制和歷史追蹤等，方便后續統一的容器升級等操作，使得容器僅專注于代碼實現。

2.2.4 網關層

網關層是客戶端和微服務集群的連接橋梁，作用是將用戶的訪問請求經過路由轉發至相應的業務功能微服務中去，通過網關可以對用戶屏蔽不同的微服務地址，對外提供統一的入口，并可以在路由轉發過程中完成負載均衡、身份驗證和日志記錄等工作。根據不同技術組件的特點，本系統在網關層使用Nginx作為反向代理面向用戶提供服務，將用戶請求轉發至微服務網關Zuul進行路由轉發。Zuul核心技術原理是依靠Filter（過濾器）實現訪問請求到微服務的路由轉發，提供了PRE、ROUTING、POST、ERROR四種標準的過濾器分別在訪問被路由前、中、后和出錯時調用。

3系統部署實施過程

3.1 計算資源規劃

本系統建設時計算資源的規劃以學校2萬用戶規模、2000并發量為基準進行測算，充分采用高可用模式進行部署：采用1臺應用服務網關作為對外統一的服務地址；采用3臺服務器搭建K8S集群管理節點，6臺服務器作為K8S集群工作節點，集群中只要有半數以上的服務器狀態正常即可維持系統正常服務，極大地提高了可用性；采用1臺服務器作為鏡像倉庫，存放打包好的容器鏡像；分別采用1臺服務器作為MySQL8數據庫和NFS存儲服務器，向整個集群提供基礎的結構化和文件存儲；采用4臺服務器組成高性能對象存儲集群Minio；在管理層面，采用3臺服務器搭建Rancher管理集群，并通過1臺網關服務器向運維人員提供Web端的管理界面。整個集群共21臺服務器，具體見表1，邏輯連接關系見圖3。

表1計算資源規劃

3.2基本部署流程

本系統部署主要包括五個步驟：服務器環境準備、域名規劃及解析、基礎服務搭建、Rancher和K8S集群部署、應用服務部署。服務器環境準備的工作包括配置服務器網絡、啟動NTP服務確保集群時間同步、按照K8S官方文檔要求修改主機名并創建新的用戶用于后續集群的安裝、關閉防火墻或按照官方文檔說明在集群內部開放所需的端□。域名規劃及解析主要是將面向用戶的服務域名與Rancher和Harbor的管理域名通過DNS服務器解析到對應的地址。基礎服務搭建的工作是將集群外的鏡像倉庫Harbor、數據庫MySQL8、文件存儲NFS、對象存儲Minio和網關Nginx進行獨立搭建部署。Rancher和K8S集群部署是本系統部署的核心環節，主要步驟如表2所示。應用服務部署是在前序所有步驟完成后，由開發人員將所有服務的鏡像打包發布到鏡像倉庫Harbor，然后由實施人員通過Rancher按照部署順序逐一拉取并啟動鏡像。

圖4搭建完畢的Rancher顯示管理集群的資源使用情況

部署完畢后即可通過Rancher管理工具提供的圖形化界面對K8S集群進行管理（見圖4）。

4系統運維管理要點

采用微服務架構的智慧校園公共軟件平臺在日常運維管理方面相較于傳統的單體架構也有不同之處，主要體現在以下四個方面。

1）關注集群中工作節點的CPU、內存資源使用情況，合理設置集群預留的資源比例，必要時手動調整容器所處的宿主機以平衡集群資源使用率（圖5）。2）發現系統故障后首先由運維人員根據業務功能逐一排查相關微服務的日志輸出，定位故障容器后反饋至對應的開發團隊進行處理，最后在線升級更新后的容器。3）根據業務開展情況靈活調整相關服務的容器副本數量以應對可能的高并發場景，例如，在選課業務期間擴充認證服務的副本數量。4）同步觀察數據庫的負載情況，特別是在大規模擴充容器副本數量的情況下，留意由于副本數量增加導致的數據庫負載增加。

5 結束語

空軍軍醫大學采用微服務架構建設的智慧校園公共軟件平臺自2021年3月投入使用以來已穩定運行四年多，其間所有的系統升級采用在線升級方式進行，未出現業務中斷。空軍軍醫大學的實踐充分證明，采用微服務架構顯著提高了系統的可用性和可擴展性，可以實現負載快速擴容，降低運維管理工作難度，同時可以針對不同的功能進行獨立升級；開發人員可以靈活選用不同的技術棧提高開發效率。基于微服務架構的靈活性，后續可以進一步探索更多校園微應用的建設。

6 參考文獻

[1]蔣彪.Docker微服務架構實戰[M].北京：電子工業出版社，2018.

[2]蒲偉．基于微服務的軟件開發框架的探索與思考［J].科技創新與應用，2021，11（19）：56-58.

[3]巢晟盛.基于SpringBoot微服務架構下前后端分離的MVVM模型淺析[J].電腦知識與技術，2021，17（23）：128-129，141.

[4]韓立峰，元雪冬.基于微服務的高校網上訂餐系統設計[J]．微型電腦應用，2021，37（9）：155-157，165.

[5］倪小璐，王旭英，邊俊凱，等．微服務軟件架構設計模式及其應用［J].杭州師范大學學報（自然科學版），2021，20（4）：442-448.

[6]張濤，劉彩云，汪翔．基于Docker的智慧教學平臺研究與實踐［J].牡丹江大學學報，2021，30（7）：88-95.

[7]陳文沛，王小金，趙守凱．基于中臺技術的高職高專院校智慧校園設計研究[J].中國教育技術裝備，2023（9）：61-64.