許曉東,聞 雷

(江蘇大學(xué) 計(jì)算機(jī)科學(xué)與通信工程學(xué)院，江蘇 鎮(zhèn)江 212013)

0 引言

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

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

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

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

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

1 相關(guān)研究

1.1 ODI集成方式

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

圖1 ODI集成方式架構(gòu)

1.2 微服務(wù)集成方式

微服務(wù)集成方式按照業(yè)務(wù)需求對(duì)各部門應(yīng)用進(jìn)行拆分，對(duì)外提供清晰的數(shù)據(jù)服務(wù)接口，有助于打破各應(yīng)用系統(tǒng)間數(shù)據(jù)相對(duì)獨(dú)立的格局，幫助各系統(tǒng)實(shí)現(xiàn)流程貫通與應(yīng)用整合[9]。微服務(wù)集成架構(gòu)如圖2所示。

圖2 微服務(wù)集成架構(gòu)

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

1.3 開源微服務(wù)架構(gòu)對(duì)比

目前主流的開源微服務(wù)開發(fā)框架有Spring Cloud、Akka、dubbo、Vert.x與華為的ReactiveX等，每個(gè)框架具有各自的特點(diǎn)以及適用場(chǎng)景[12]。以下對(duì)SpringCloud與阿里巴巴的Dubbo框架進(jìn)行橫向比較，對(duì)比結(jié)果如表1所示。

表1 Dubbo與SpringCloud框架對(duì)比

從表1中可以看出，Dubbo框架只能為開發(fā)者提供微服務(wù)架構(gòu)的基礎(chǔ)功能，對(duì)其它組件需要額外進(jìn)行整合，在提供良好靈活性的同時(shí)，也增加了開發(fā)成本，而SpringCloud在Netfix強(qiáng)大后盾的支持與技術(shù)輸出下，減少了很多部署測(cè)試步驟，使開發(fā)者只需把精力集中在整合功能的業(yè)務(wù)邏輯上。

2 基于微服務(wù)的智慧校園平臺(tái)設(shè)計(jì)

將各部門應(yīng)用系統(tǒng)中復(fù)雜的業(yè)務(wù)邏輯梳理抽象成可重復(fù)利用的微服務(wù)粒子，根據(jù)業(yè)務(wù)功能將各個(gè)微服務(wù)組織起來[13]，然后在數(shù)字化校園前期建設(shè)的基礎(chǔ)上進(jìn)行集成開發(fā)?；谖⒎?wù)的一站式服務(wù)平臺(tái)架構(gòu)如圖3 所示。

圖3 基于微服務(wù)的一站式服務(wù)平臺(tái)架構(gòu)

用戶通過手機(jī)、Pad等移動(dòng)設(shè)備及瀏覽器向微信客戶端請(qǐng)求服務(wù)，請(qǐng)求首先經(jīng)過平臺(tái)提供的相關(guān)安全策略[14]進(jìn)行訪問過濾與攔截，通過驗(yàn)證的請(qǐng)求會(huì)轉(zhuǎn)發(fā)到后端微服務(wù)進(jìn)行處理。架構(gòu)中負(fù)責(zé)系統(tǒng)運(yùn)行、監(jiān)測(cè)的模塊同樣也作為平臺(tái)中的一個(gè)微服務(wù)。

2.1 注冊(cè)與發(fā)現(xiàn)組件

微服務(wù)的注冊(cè)與發(fā)現(xiàn)組件是系統(tǒng)核心功能，包括服務(wù)端與客戶端兩部分，主要完成以下工作[15]：

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

(2)注冊(cè)與發(fā)現(xiàn)：微服務(wù)在服務(wù)發(fā)現(xiàn)組件上進(jìn)行信息注冊(cè)，并提供查詢與管理微服務(wù)實(shí)例的功能。如果微服務(wù)的網(wǎng)絡(luò)地址發(fā)生變化，則會(huì)到發(fā)現(xiàn)中心重新注冊(cè)。

(3)服務(wù)檢查：服務(wù)端定時(shí)進(jìn)行服務(wù)檢查，如果長時(shí)間接收不到某個(gè)微服務(wù)實(shí)例，注冊(cè)組件則會(huì)將該實(shí)例從服務(wù)發(fā)現(xiàn)中心剔除。

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

2.2 微服務(wù)網(wǎng)關(guān)組件

由于一站式服務(wù)平臺(tái)采用微服務(wù)架構(gòu)理念進(jìn)行設(shè)計(jì)，一個(gè)輕應(yīng)用可能由多個(gè)模塊組成，則需要訪問多個(gè)微服務(wù)實(shí)例完成請(qǐng)求[16]。例如：個(gè)人中心需要請(qǐng)求一卡通消費(fèi)流水、課程提醒、待辦事務(wù)等服務(wù)實(shí)例，而這些接口都需要一套校驗(yàn)邏輯認(rèn)證用戶訪問權(quán)限，如果每個(gè)實(shí)例都各自進(jìn)行實(shí)現(xiàn)，隨著微服務(wù)規(guī)模的擴(kuò)大，在客戶端調(diào)用多個(gè)服務(wù)接口顯然會(huì)增加客戶端復(fù)雜性，從而造成訪問困難。

為解決上述架構(gòu)中的問題，本系統(tǒng)在介于客戶端與服務(wù)端的中間層架設(shè)一個(gè)微服務(wù)網(wǎng)關(guān)組件，以封裝應(yīng)用程序內(nèi)部結(jié)構(gòu)，客戶端只需要與網(wǎng)關(guān)交互，而不需要與每一個(gè)服務(wù)接口關(guān)聯(lián)。所有外部訪問都需要經(jīng)過其調(diào)度與過濾，主要實(shí)現(xiàn)路由請(qǐng)求、校驗(yàn)過濾、負(fù)載均衡以及熔斷等功能，發(fā)揮類似小區(qū)保安的作用[17]。

3 微服務(wù)集成案例

校園一站式服務(wù)平臺(tái)最終以輕應(yīng)用形式發(fā)布在微信企業(yè)號(hào)上，面向師生提供覆蓋辦公、教務(wù)、人事、財(cái)務(wù)等多個(gè)領(lǐng)域的個(gè)性化服務(wù)[18]。本節(jié)通過涉及多部門數(shù)據(jù)交互的掃碼迎新應(yīng)用設(shè)計(jì)一個(gè)微服務(wù)架構(gòu)。依照微服務(wù)架構(gòu)原則，抽取各部門的相應(yīng)功能并進(jìn)行模塊化，每個(gè)模塊實(shí)現(xiàn)一個(gè)獨(dú)立的微服務(wù)功能，可單獨(dú)部署，模塊之間松耦合，通過rest或其它協(xié)議進(jìn)行通信[19]。系統(tǒng)主要業(yè)務(wù)需求如圖4所示。

圖4 掃碼迎新應(yīng)用業(yè)務(wù)需求

根據(jù)需求，應(yīng)用主要包括以下微服務(wù)實(shí)例：組織部的志愿者服務(wù)、招生辦的新生基本信息查詢服務(wù)(含銀行卡余額信息)、財(cái)務(wù)處的扣款服務(wù)、宿管科的新生宿舍信息以及報(bào)到狀態(tài)查詢、更改等服務(wù)。本文以新生報(bào)到過程中的繳納費(fèi)用為例，在進(jìn)行扣款業(yè)務(wù)操作之前，財(cái)務(wù)扣款服務(wù)需要調(diào)用新生基本信息微服務(wù)接口，查詢?cè)撋y行卡余額是否符合扣費(fèi)標(biāo)準(zhǔn)等。在該場(chǎng)景下，新生基本信息微服務(wù)是一個(gè)服務(wù)提供者，而財(cái)務(wù)扣款微服務(wù)則是一個(gè)服務(wù)消費(fèi)者。

3.1 服務(wù)提供者與服務(wù)消費(fèi)者

3.1.1 服務(wù)提供者

創(chuàng)建一個(gè)項(xiàng)目工程，命名為microservice-provider-student, 在配置文件中引入項(xiàng)目所需依賴，并將服務(wù)提供者端口設(shè)置為7074，然后依次創(chuàng)建學(xué)生實(shí)體類、dao、controller和啟動(dòng)類。

根據(jù)http://localhost:7074/student/1 , 獲得信息：

{

"status": "ok",

"result": {

"id": 1,

"name": "韓梅梅",

"age": 26,

"sex": "女",

"balance": 10000

}

}

3.1.2 服務(wù)消費(fèi)者

服務(wù)消費(fèi)者與服務(wù)提供者的創(chuàng)建過程基本類似，創(chuàng)建一個(gè)項(xiàng)目工程，命名為microservice-consumer-payment ,將服務(wù)消費(fèi)者的端口設(shè)置為7076，然后依次創(chuàng)建學(xué)生實(shí)體pojo類、controller(在其中使用RestTemplate調(diào)用學(xué)生微服務(wù)的API)與啟動(dòng)類。

在postman工具中進(jìn)行測(cè)試，獲得信息：

{

"status": "ok",

"result": {

"id": 1,

"name": "韓梅梅",

"age": 26,

"sex": "女",

"balance": 10000

}

}

說明扣款服務(wù)能夠正常調(diào)用學(xué)生信息微服務(wù)的API。

3.2 微服務(wù)注冊(cè)與發(fā)現(xiàn)

上述案例在代碼中硬編碼了服務(wù)的網(wǎng)絡(luò)地址，在項(xiàng)目初期服務(wù)較少的情況下可以采用該方法完成服務(wù)調(diào)用。但隨著項(xiàng)目的發(fā)展、業(yè)務(wù)規(guī)模的擴(kuò)大，硬編碼與靜態(tài)配置方式已無法滿足項(xiàng)目需求。因此，架構(gòu)采用Netflix開源服務(wù)發(fā)現(xiàn)組件Eureka實(shí)現(xiàn)微服務(wù)的注冊(cè)與發(fā)現(xiàn)，以對(duì)所有校園微服務(wù)實(shí)例進(jìn)行有效管理。

SpringCloud編寫Eureka Server的服務(wù)比較簡(jiǎn)單，首先創(chuàng)建一個(gè)新的項(xiàng)目工程，命名為microservice-discovery-eureka, 在項(xiàng)目中添加相關(guān)依賴，然后在啟動(dòng)類上添加@EnableEurekaServer注解即可。本節(jié)中的兩個(gè)微服務(wù)實(shí)例需要添加依賴以及啟動(dòng)類注解@EnableDiscoveryClient , 然后在配置文件中添加需要交互的Eureka Server地址，將實(shí)例注冊(cè)到Eureka Server上。

圖5 微服務(wù)注冊(cè)與發(fā)現(xiàn)

由圖5可以看出，學(xué)生信息服務(wù)與扣費(fèi)服務(wù)已被成功注冊(cè)到Eureka Server上。

3.3 微服務(wù)網(wǎng)關(guān)構(gòu)建

本項(xiàng)目集成Netflix開源服務(wù)網(wǎng)關(guān)組件Zuul，配合注冊(cè)組件Eureka、負(fù)載均衡組件Ribbon以及容錯(cuò)組件Hystrix。

創(chuàng)建一個(gè)服務(wù)網(wǎng)關(guān)項(xiàng)目，命名為microservice-gateway-zuul，在配置文件中添加Zuul依賴，端口號(hào)設(shè)置為8040，并將Zuul注冊(cè)到Eureka上，即可完成簡(jiǎn)單的微服務(wù)網(wǎng)關(guān)編寫。

啟動(dòng)microservice-provider-student 、microservice-consumer-payment、microservice-gateway-zuul 3個(gè)實(shí)例，訪問http://localhost:8040/microservice-consumer-payment/student/1,請(qǐng)求會(huì)被轉(zhuǎn)發(fā)到http://localhost:7076/payment/1。如果訪問http://localhost:8040/microservice-provider-student/student/1,請(qǐng)求會(huì)被轉(zhuǎn)發(fā)到http://localhost:7074/student/1 ,說明Zuul會(huì)代理注冊(cè)到Eureka上。

4 結(jié)語

本文分析了現(xiàn)階段高校信息化建設(shè)過程中存在的問題，提出基于Spring Cloud的微服務(wù)架構(gòu)解決方案，將高度耦合在各部門應(yīng)用系統(tǒng)中的業(yè)務(wù)拆分為可注冊(cè)的微服務(wù)，從而達(dá)到統(tǒng)一管理數(shù)據(jù)接口及業(yè)務(wù)功能復(fù)用的目的。介紹了微服務(wù)設(shè)計(jì)過程中涵蓋的關(guān)鍵組件[20]，最后以掃碼迎新應(yīng)用案例為例進(jìn)行剖析，簡(jiǎn)述如何進(jìn)行業(yè)務(wù)拆分，以及數(shù)據(jù)接口在微服務(wù)架構(gòu)中是如何開發(fā)、發(fā)現(xiàn)與注冊(cè)的。