基于學生評教小程序的Web服務端研究與設計＊

楊亞仿，林政藝

(廣西中醫(yī)藥大學，廣西 南寧 530200)

0 引言

無論是哪一種小程序，基本的用戶驗證、業(yè)務加載、流程提交等數(shù)據(jù)請求，都需要Web 服務端的安全驗證與快速響應，因此，Web 服務端的數(shù)據(jù)安全和快速響應是小程序業(yè)務的運行基礎。傳統(tǒng)的互聯(lián)網(wǎng)服務器可以使用內(nèi)網(wǎng)方式進行數(shù)據(jù)通信，但小程序和Web 服務端之間必須使用公共域名進行數(shù)據(jù)通信或數(shù)據(jù)交換，因此小程序?qū)eb 服務端的數(shù)據(jù)安全和響應速度有更高的要求。

本文基于實際的高校學生評教小程序項目，對小程序的Web服務端特點進行研究與分析，對Web服務端如何保持安全、高效的運行進行了討論，結(jié)合具體評教業(yè)務流程，設計了一套符合該項目需求的Web 服務端程序，該服務端程序具備一定的通用能力，包括自定義JSON 序列化、自定義Token 驗證，也包括適合該項目特點的課表數(shù)據(jù)緩存與同步更新機制。

1 小程序Web服務端的研究綜述

互聯(lián)網(wǎng)的各種應用均離不開Web 服務端的支持，傳統(tǒng)Web 服務端的基本功能應包括用戶身份認證、數(shù)據(jù)交互、數(shù)據(jù)安全、數(shù)據(jù)緩存等，小程序的Web 服務端不僅要包含以上功能，還應在這些功能上追求更高的性能和效率，才能應對和滿足小程序的輕量、便捷、高效等特點與要求。很多學者對此展開了研究與討論，并取得了一定的研究成果。

周虎通過對比傳統(tǒng)Cookie/Session 身份驗證機制的不足，提出了一種基于JWT 認證過程中動態(tài)刷新Token的方法，并在Web開發(fā)中進行了實踐應用[1]。李毓麗等自定義了一套Token校驗機制并利用Swoole下的WebSocket 接口實現(xiàn)了消息通知功能[2]。鄒軍國在輕量級微服務架構(gòu)思想指導下按照Token身份認證原理提出了高校實訓互動平臺的身份認證解決方案[3]。徐冉通過研究微服務架構(gòu)，使用消息中間件與高性能緩存，研究實現(xiàn)了秒殺系統(tǒng)的Web 服務端設計[4]。張欣將知識圖譜引入小程序，面向?qū)W生個性化學習設計了認知診斷、個人知識圖譜和課程推薦等功能，實現(xiàn)了基于微信小程序的教育知識圖譜個性化學習平臺[5]。饒煜等分析了在線學習系統(tǒng)的需求，在Web 服務端設計了文件上傳、題庫和考試管理、統(tǒng)計分析等功能，完成了基于微信平臺的在線學習系統(tǒng)的設計與實現(xiàn)[6]。

賈歐等通過使用緩存技術(shù)，對用戶需要查閱的數(shù)據(jù)進行預讀取，提前在數(shù)據(jù)庫中查詢出符合條件的數(shù)據(jù)存入緩存中，減少數(shù)據(jù)庫的訪問次數(shù)，優(yōu)化了電能質(zhì)量智能信息系統(tǒng)，提高了Web 應用系統(tǒng)的性能[7]。翁美珍等在多媒體會議系統(tǒng)的研究中，設計實現(xiàn)了基于LRU 替換策略的緩存系統(tǒng)，有效提高了緩存系統(tǒng)的字節(jié)命中率，同時將Memcached 技術(shù)應用于Hibernate框架中實現(xiàn)了數(shù)據(jù)庫數(shù)據(jù)緩存，提高了訪問吞吐量和服務響應速度[8]。

綜上所述，基于Web 服務端的信息系統(tǒng)在各行各業(yè)中發(fā)揮著舉足輕重的作用，Web 服務端通過Token機制能有效標識用戶身份，通過緩存技術(shù)能有效提高信息系統(tǒng)的響應速度。

2 學生評教小程序Web服務端功能分析

本文中的學生評教小程序來自于實際的教育教學改革與研究課題，基本的功能要求是每個學生正常登錄后可以針對教師已講授的所有課程做出實時的教學評價，具體需求有：①身份驗證，學生須用學號登錄；②學生以移動端方式（如手機、平板）評教為主，以課表為單位進行評教，課表數(shù)據(jù)來自于教務系統(tǒng)；③數(shù)據(jù)傳輸過程中應采用有效的安全檢測方法，防止數(shù)據(jù)惡意請求及數(shù)據(jù)泄漏；④Web 服務端須高效穩(wěn)定運行，能實時響應學校近數(shù)千名學生的評教數(shù)據(jù)請求；⑤評教界面應操作簡單。

針對以上需求，本文的Web 服務端采取如下方式進行設計：

⑴系統(tǒng)結(jié)構(gòu)方面采取經(jīng)典的三層模式架構(gòu)應對評教業(yè)務功能，即業(yè)務邏輯層、數(shù)據(jù)訪問層和實體層。該架構(gòu)最大的優(yōu)勢是各層之間的結(jié)構(gòu)清晰、易于擴展和邏輯復用，如未來可在同一系統(tǒng)架構(gòu)下較為方便的增加同行評教、督導評教等功能。

⑵采取自定義JSON 序列化方式傳輸數(shù)據(jù)。小程序與Web 服務端之間的數(shù)據(jù)傳輸須使用標準JSON格式，本文提出了一種自定義JSON 序列化的方式，能實現(xiàn)定制化輸出，在一定程度上提高了對象序列化為JSON字符串的效率，提升了系統(tǒng)性能。

⑶采取自定義Token 方式對用戶身份和數(shù)據(jù)請求進行安全驗證，防范數(shù)據(jù)惡意請求及數(shù)據(jù)泄漏。

⑷采取數(shù)據(jù)緩存的方式將課表數(shù)據(jù)加載到內(nèi)存中，提高數(shù)據(jù)查找效率，根據(jù)不同數(shù)據(jù)的特點分別采取特定時間間隔進行同步更新，保持數(shù)據(jù)一致。

⑸評教界面以課表為單位，最近七天需要評教的課表采取列表方式，讓學生一次選擇后即可打開評教頁面進行內(nèi)容填寫，其他需評教的課表采取列表和表格兩種方式進行選擇。

3 學生評教小程序Web服務端設計

3.1 自定義JSON序列化

Newtonsoft.Json、JavaScriptSerializer 等現(xiàn)有組件提供了較為通用的JSON 序列化方法，使用起來也比較簡單，但還不夠靈活，較難實現(xiàn)定制化輸出，如根據(jù)實體中的多個屬性值進行邏輯判斷后輸出不同的JSON 字符串、組合多個實體的屬性值輸出JSON 字符串等，現(xiàn)有組件面對此種特殊需求較難實現(xiàn)。

根據(jù)面向?qū)ο缶幊痰幕舅枷?，哪里出現(xiàn)變化就封裝哪里，即封裝變化點，軟件設計的關(guān)鍵是能將變化點抽象提煉出來。通過對本文的Web 服務端功能進行分析，學生、課表等各實體對象在進行JSON 序列化過程中可能出現(xiàn)較大變化，因此將該JSON 序列化過程封裝在特定接口中，具體如下：

其他實體類須繼承實現(xiàn)該接口的ToJson 方法來實JSON 序列化的定制輸出，如學生用戶User 類繼承了IJson 接口，并實現(xiàn)了ToJson 方法，實現(xiàn)了level 屬性的格式化定制輸出，具體如下：

其他實體類實現(xiàn)IJson 接口的過程與上類似，如圖1所示。

圖1 Web服務端的實體類設計

3.2 自定義Token

Token 的使用在一定程度上提高了數(shù)據(jù)的安全性，在Token 認證體系下，小程序通過用戶身份驗證后，接下來與Web 服務端的數(shù)據(jù)交互內(nèi)容均由正常的業(yè)務數(shù)據(jù)+Token 內(nèi)容兩部分組成，其中Token 內(nèi)容用于驗證數(shù)據(jù)請求的有效性。標準Token 內(nèi)容包括Header，Payload，Signature，其中Payload存儲著主要的數(shù)據(jù)內(nèi)容，包括用戶Id，TokenId，頒發(fā)時時間和過期時間等，在實際業(yè)務中也可根據(jù)需要包括其他自定義內(nèi)容，此舉固然安全，但標準Token 的內(nèi)容較多，增加了開銷，此外，Token 過期后，用戶需要重新進行用戶名密碼驗證，降低了用戶體驗。

為了減少小程序與Web 服務端的數(shù)據(jù)傳輸開銷，本文基于標準Token，自定義了Token 內(nèi)容，使用Guid（128 位，用32 個十六進制數(shù)表示）作為TokenId，小程序與Web 服務端之間的數(shù)據(jù)傳輸僅加上該TokenId（32 位字符串）用于標識驗證用戶，TokenId 的頒發(fā)時間和有效期驗證轉(zhuǎn)移到Web服務端處理。標準Token和本文自定義Token 兩種情況下的數(shù)據(jù)傳輸對比如圖2所示。

圖2 標準Token與自定義Token數(shù)據(jù)傳輸對比

Web 服務端對Token 的處理主要由Token 類和TokenBll類完成，具體設計如圖3所示。

圖3 Token類和TokenBll類設計

Token類的成員以數(shù)據(jù)屬性為主，如表1所示。

表1 Token類

Token類在構(gòu)造函數(shù)中實現(xiàn)了TokenId的自動生成，具體代碼如下：

TokenBll 類包括屬性成員和方法成員兩種，最重要的屬性是Toekens字典集合，其存儲了所有的Token集合，其他屬性和方法均圍繞該字典集合展開相應的增加與更新操作，主要說明如表2所示。

表2 TokenBll類

私有方法TokenAdd 和TokenUpdate 在實際使用過程中需同時處理多個客戶端的并發(fā)請求，即需實現(xiàn)多線程環(huán)境下對共享數(shù)據(jù)Tokens 字典集合的同步與互斥操作，本文結(jié)合Lock 鎖和LockObj 對象，實現(xiàn)了對該共享資源的控制，具體實現(xiàn)過程如下：

3.3 數(shù)據(jù)緩存

傳統(tǒng)模式下，小程序的數(shù)據(jù)交互由小程序端向Web 服務端發(fā)出數(shù)據(jù)請求，Web 服務端向數(shù)據(jù)庫提交SQL命令取得返回結(jié)果，再向小程序端發(fā)出數(shù)據(jù)響應，該模式經(jīng)過Web 服務端與數(shù)據(jù)庫兩次數(shù)據(jù)響應，當用戶并發(fā)數(shù)較多時，對整個程序的性能會有一定影響。

本文采用了數(shù)據(jù)緩存模式下的數(shù)據(jù)交互方式，Web 服務端將數(shù)據(jù)庫中的數(shù)據(jù)提前讀取到數(shù)據(jù)緩存中，當收到小程序端的數(shù)據(jù)請求時，從數(shù)據(jù)緩存中查詢數(shù)據(jù)進行數(shù)據(jù)響應，因內(nèi)存查詢的速度遠高于數(shù)據(jù)庫的查詢速度，從而提高了數(shù)據(jù)響應能力。傳統(tǒng)模式和數(shù)據(jù)緩存模式下的數(shù)據(jù)交互對比如圖4所示。

圖4 傳統(tǒng)模式與數(shù)據(jù)緩存模式下的數(shù)據(jù)交互對比

數(shù)據(jù)緩存的關(guān)鍵在于選擇哪些數(shù)據(jù)進行緩存，緩存的數(shù)據(jù)何時更新同步。緩存的數(shù)據(jù)應該較少變化，或者是呈現(xiàn)有規(guī)律的變化，如果數(shù)據(jù)經(jīng)常變化，數(shù)據(jù)同步的代價太高，那就失去了緩存的意義。通過對學生評教小程序的業(yè)務進行分析，需要交互的評教數(shù)據(jù)及其特點如下：

⑴學生登錄數(shù)據(jù)，包括學號、密碼等，因為用戶會隨時修改密碼，所以一般不做緩存處理。

⑵ 課表數(shù)據(jù)，包括學號、課程名、教師、上課的教室、上課的時間等。課表數(shù)據(jù)屬于數(shù)據(jù)交互最集中的數(shù)據(jù)，學期課表正式公布后，一般不會調(diào)整，如果需要調(diào)整，也要提前一到二天，屬于有周期變化規(guī)律的數(shù)據(jù)，可做緩存，每天定時進行數(shù)據(jù)同步。

⑶教師列表總數(shù)據(jù)，可能會單獨請求該數(shù)據(jù)，教師列表總數(shù)據(jù)在學期中途較少有變化，可做緩存，可從最新的課表數(shù)據(jù)中同步更新。

⑷教室列表總數(shù)據(jù)，可能會單獨請求該數(shù)據(jù)，教室列表數(shù)據(jù)是本系統(tǒng)中最少變化的數(shù)據(jù)，可做緩存，可從最新的課表數(shù)據(jù)中同步更新。

以上評教數(shù)據(jù)中，數(shù)據(jù)交互最頻繁的是課表數(shù)據(jù)，下面以課表數(shù)據(jù)為例簡述其數(shù)據(jù)緩存和數(shù)據(jù)同步的實現(xiàn)過程，關(guān)鍵代碼如下：

4 結(jié)束語

本文基于實際的高校學生評教小程序項目，研究了小程序Web 服務端的實現(xiàn)要點，通過自定義JSON序列化，實現(xiàn)了小程序端與Web 服務端的數(shù)據(jù)傳輸，通過自定義Token 完成了數(shù)據(jù)請求的安全驗證，通過數(shù)據(jù)緩存提高了Web 服務端的響應能力，在實際應用中有效提高了小程序Web 服務端的處理能力，具有一定的參考價值。