校園移動應用集成模式研究

許曉東,聞 雷

(江蘇大學 計算機科學與通信工程學院，江蘇 鎮江 212013)

0 引言

高校信息化經過十幾年發展，已建成一系列包括教務、財務、圖書館、后勤等部門的線上管理系統，在教學、科研、管理、服務等各方面都取得了重要成果，為師生們的學習與生活提供了極大便利[1]。但這些系統通常由所屬部門統籌管理，存在各部門各自為政與數據流通不暢的情況[2]。隨著校園應用的不斷深化、部門業務數據以及多部門協同合作的增多，工作中面臨著許多亟待解決的問題，具體表現為以下幾點:

(1)服務缺乏統一渠道。各部門已有的PC端、移動端應用較為分散，開發平臺不一，且部分部門尚未開發移動端產品，造成管理效率低下、服務過程繁瑣[3]。如查詢課表與成績信息需要下載教務處的APP客戶端、完成圖書續借功能需要登錄圖書管理系統、新入職教師需要登錄若干系統進行入職手續辦理等。面對眾多線上服務，如何快速便捷地尋找到目標內容、及時獲取部門公告信息正成為困擾師生們的難題。

(2)數據缺乏統一架構管理。各部門的數十個應用系統面向師生提供大量應用服務，服務接口沒有統一標準，缺乏綜合治理已有業務調用的架構[4]。在傳統應用程序中，一般將數據接口IP與端口硬編碼到程序代碼中或提取到配置文件中[5]。該方式主要存在兩方面弊端：一是當服務提供者的網絡地址發生變化時，服務勢必受到影響；二是無法滿足線上部署多個實例以實現分流與負載均衡的需求。

(3)應用系統難以有效集成。高校應用系統基本上呈垂直分布狀態，由不同軟件服務商提供服務，能夠獨立工作，內部設計緊耦合，數據相對獨立[6]。隨著業務系統的不斷增加以及跨部門業務集成的增多，以上特點將表現得更加明顯，從而給開發人員集成、拓展及應用維護帶來阻力[7]。

綜上所述，本文引入微服務架構設計方法并結合移動互聯網技術尋求高校應用系統集成解決方案。對層出不窮的客戶端設備(手機、平板、電腦桌面等)建立一組架構約束條件與標準，基于微服務設計原則對高校各應用系統進行業務拆分，提供包括一卡通、財務、教務、師生基本信息等服務接口供開發人員使用，以滿足業務對技術快速迭代與橫向擴展的要求，從而提供更加便捷與高質量的服務，進一步提升應用開發水平與校園管理效率。

1 相關研究

1.1 ODI集成方式

在高校信息化建設初期，由于缺乏統籌規劃以及統一的標準規范體系，導致高校各部門應用系統呈現“巨無霸”、“煙囪”式的特點，各部門各自為政，數據流通不順暢[8]。若要集成諸如迎新、離校等跨部門應用，技術開發人員通常采用ODI集成方式，將分散在各應用系統內的數據通過ETL工具與組件抽取到目標數據庫，形成邏輯上的數據共享中心或數據交換中心。然后在此基礎上進行業務開發，其集成方式架構如圖1所示。

圖1 ODI集成方式架構

1.2 微服務集成方式

微服務集成方式按照業務需求對各部門應用進行拆分，對外提供清晰的數據服務接口，有助于打破各應用系統間數據相對獨立的格局，幫助各系統實現流程貫通與應用整合[9]。微服務集成架構如圖2所示。

圖2 微服務集成架構

微服務架構集成方式為采用ODI集成方式難以實現的功能提供了模塊化解決方案[10]。當高校出現新業務需求時，只需向軟件服務商購買數據服務接口，或者依靠信息技術部門自主研發即可，無需向軟件服務商購買整套應用系統或從各部門抽取數據，從而節省了大量預算且降低了工作量，并且單個服務更易于開發、理解與維護[11]。

1.3 開源微服務架構對比

目前主流的開源微服務開發框架有Spring Cloud、Akka、dubbo、Vert.x與華為的ReactiveX等，每個框架具有各自的特點以及適用場景[12]。以下對SpringCloud與阿里巴巴的Dubbo框架進行橫向比較，對比結果如表1所示。

表1 Dubbo與SpringCloud框架對比

從表1中可以看出，Dubbo框架只能為開發者提供微服務架構的基礎功能，對其它組件需要額外進行整合，在提供良好靈活性的同時，也增加了開發成本，而SpringCloud在Netfix強大后盾的支持與技術輸出下，減少了很多部署測試步驟，使開發者只需把精力集中在整合功能的業務邏輯上。

2 基于微服務的智慧校園平臺設計

將各部門應用系統中復雜的業務邏輯梳理抽象成可重復利用的微服務粒子，根據業務功能將各個微服務組織起來[13]，然后在數字化校園前期建設的基礎上進行集成開發。基于微服務的一站式服務平臺架構如圖3 所示。

圖3 基于微服務的一站式服務平臺架構

用戶通過手機、Pad等移動設備及瀏覽器向微信客戶端請求服務，請求首先經過平臺提供的相關安全策略[14]進行訪問過濾與攔截，通過驗證的請求會轉發到后端微服務進行處理。架構中負責系統運行、監測的模塊同樣也作為平臺中的一個微服務。

2.1 注冊與發現組件

微服務的注冊與發現組件是系統核心功能，包括服務端與客戶端兩部分，主要完成以下工作[15]：

(1)服務注冊表：在服務端記錄各個微服務實例信息，如微服務的名稱、IP、端口。

(2)注冊與發現：微服務在服務發現組件上進行信息注冊，并提供查詢與管理微服務實例的功能。如果微服務的網絡地址發生變化，則會到發現中心重新注冊。

(3)服務檢查：服務端定時進行服務檢查，如果長時間接收不到某個微服務實例，注冊組件則會將該實例從服務發現中心剔除。

(4)客戶端與服務端交互：Client主要用于簡化與Server的交互行為。默認情況下客戶端同時也是服務端，會通過緩存注冊表中的信息減輕服務端壓力。

2.2 微服務網關組件

由于一站式服務平臺采用微服務架構理念進行設計，一個輕應用可能由多個模塊組成，則需要訪問多個微服務實例完成請求[16]。例如：個人中心需要請求一卡通消費流水、課程提醒、待辦事務等服務實例，而這些接口都需要一套校驗邏輯認證用戶訪問權限，如果每個實例都各自進行實現，隨著微服務規模的擴大，在客戶端調用多個服務接口顯然會增加客戶端復雜性，從而造成訪問困難。

為解決上述架構中的問題，本系統在介于客戶端與服務端的中間層架設一個微服務網關組件，以封裝應用程序內部結構，客戶端只需要與網關交互，而不需要與每一個服務接口關聯。所有外部訪問都需要經過其調度與過濾，主要實現路由請求、校驗過濾、負載均衡以及熔斷等功能，發揮類似小區保安的作用[17]。

3 微服務集成案例

校園一站式服務平臺最終以輕應用形式發布在微信企業號上，面向師生提供覆蓋辦公、教務、人事、財務等多個領域的個性化服務[18]。本節通過涉及多部門數據交互的掃碼迎新應用設計一個微服務架構。依照微服務架構原則，抽取各部門的相應功能并進行模塊化，每個模塊實現一個獨立的微服務功能，可單獨部署，模塊之間松耦合，通過rest或其它協議進行通信[19]。系統主要業務需求如圖4所示。

圖4 掃碼迎新應用業務需求

根據需求，應用主要包括以下微服務實例：組織部的志愿者服務、招生辦的新生基本信息查詢服務(含銀行卡余額信息)、財務處的扣款服務、宿管科的新生宿舍信息以及報到狀態查詢、更改等服務。本文以新生報到過程中的繳納費用為例，在進行扣款業務操作之前，財務扣款服務需要調用新生基本信息微服務接口，查詢該生銀行卡余額是否符合扣費標準等。在該場景下，新生基本信息微服務是一個服務提供者，而財務扣款微服務則是一個服務消費者。

3.1 服務提供者與服務消費者

3.1.1 服務提供者

創建一個項目工程，命名為microservice-provider-student, 在配置文件中引入項目所需依賴，并將服務提供者端口設置為7074，然后依次創建學生實體類、dao、controller和啟動類。

根據http://localhost:7074/student/1 , 獲得信息：

{

"status": "ok",

"result": {

"id": 1,

"name": "韓梅梅",

"age": 26,

"sex": "女",

"balance": 10000

}

}

3.1.2 服務消費者

服務消費者與服務提供者的創建過程基本類似，創建一個項目工程，命名為microservice-consumer-payment ,將服務消費者的端口設置為7076，然后依次創建學生實體pojo類、controller(在其中使用RestTemplate調用學生微服務的API)與啟動類。

在postman工具中進行測試，獲得信息：

{

"status": "ok",

"result": {

"id": 1,

"name": "韓梅梅",

"age": 26,

"sex": "女",

"balance": 10000

}

}

說明扣款服務能夠正常調用學生信息微服務的API。

3.2 微服務注冊與發現

上述案例在代碼中硬編碼了服務的網絡地址，在項目初期服務較少的情況下可以采用該方法完成服務調用。但隨著項目的發展、業務規模的擴大，硬編碼與靜態配置方式已無法滿足項目需求。因此，架構采用Netflix開源服務發現組件Eureka實現微服務的注冊與發現，以對所有校園微服務實例進行有效管理。

SpringCloud編寫Eureka Server的服務比較簡單，首先創建一個新的項目工程，命名為microservice-discovery-eureka, 在項目中添加相關依賴，然后在啟動類上添加@EnableEurekaServer注解即可。本節中的兩個微服務實例需要添加依賴以及啟動類注解@EnableDiscoveryClient , 然后在配置文件中添加需要交互的Eureka Server地址，將實例注冊到Eureka Server上。

圖5 微服務注冊與發現

由圖5可以看出，學生信息服務與扣費服務已被成功注冊到Eureka Server上。

3.3 微服務網關構建

本項目集成Netflix開源服務網關組件Zuul，配合注冊組件Eureka、負載均衡組件Ribbon以及容錯組件Hystrix。

創建一個服務網關項目，命名為microservice-gateway-zuul，在配置文件中添加Zuul依賴，端口號設置為8040，并將Zuul注冊到Eureka上，即可完成簡單的微服務網關編寫。

啟動microservice-provider-student 、microservice-consumer-payment、microservice-gateway-zuul 3個實例，訪問http://localhost:8040/microservice-consumer-payment/student/1,請求會被轉發到http://localhost:7076/payment/1。如果訪問http://localhost:8040/microservice-provider-student/student/1,請求會被轉發到http://localhost:7074/student/1 ,說明Zuul會代理注冊到Eureka上。

4 結語

本文分析了現階段高校信息化建設過程中存在的問題，提出基于Spring Cloud的微服務架構解決方案，將高度耦合在各部門應用系統中的業務拆分為可注冊的微服務，從而達到統一管理數據接口及業務功能復用的目的。介紹了微服務設計過程中涵蓋的關鍵組件[20]，最后以掃碼迎新應用案例為例進行剖析，簡述如何進行業務拆分，以及數據接口在微服務架構中是如何開發、發現與注冊的。