基于Django框架的高校就業信息可視化平臺的設計與實現

林 彬， 楊彬彬， 孫 芳

(1.遼寧師范大學 計算機與信息技術學院，遼寧 大連 116081; 2.遼寧師范大學 研究生院，遼寧 大連 116029)

現有的高校就業信息處理平臺需要獲取就業年份、學院、專業、學生基本信息等多維度數據，存在效率低、實時性差的問題[1].部分數據需具有管理權限的工作人員經過系列操作之后方可實現，獲取模式復雜，難以滿足用戶需求，影響用戶體驗.現實需要一種既能實時、直觀、智能化的處理高校就業信息的平臺，又能兼容Windows、Linux、Mac OS等多種操作系統，并且以多種可視化形式呈現數據統計結果的平臺.基于Django框架開發的可視化微信小程序平臺，就可以滿足上述需求.

開發信息可視化平臺，實際上就是面向PC端和移動端的管理信息系統.需要解決信息系統效率低下問題[2-3]、控制流程邏輯問題[4]、微信小程序開發技術問題[5]、可視化數據處理技術等問題[6].在參考系列應用與實現的基礎上，利用主流技術，開發了基于Django框架的高校就業信息可視化平臺，用戶在系統內可查看實時數據統計，更能高效完成分析、決策.平臺開發遵循模塊化、可插拔等特性，在簡單調整基礎上可適配不同高校就業數據信息管理并授權給其他高校使用.

1 相關技術

在平臺開發過程中，選用Django框架開發后端API為前端提供數據支持；選用Nginx服務器保證數據安全；選用uWSGI協議保證安全接收客戶端請求.

1.1 Django框架

Django框架中可添加多個開發組件，開發過程以應用模塊為單位，每個應用模塊間有相互獨立的models文件、views文件、urls文件.models文件負責對數據庫封裝，開發者可通過models文件實現數據庫增、刪、改、查等功能.urls文件負責請求路由，分為項目層面根路由模塊與應用層面子路由模塊兩個部分.view文件是視圖層文件，封裝業務邏輯，有函數與面向對象兩種開發模式.平臺使用了面向對象開發模式，保證系統邏輯層具有更好的封裝性和代碼重用性.

1.2 Nginx服務器

Nginx服務器擔任網站服務器、反向代理服務器、負載均衡服務器等角色.作為網站服務器，不依賴第三方服務和模塊處理請求.作為反向代理服務器，不直接處理請求，而根據開發者定義規則，將請求轉發給Real Server.Real Server處理請求后，再通過Nginx服務器將請求結果返回給客戶端，此代理方式增加了后端源代碼安全性，防止黑客攻擊.作為負載均衡器，Nginx服務器請求轉發對象從一個后端服務變為多個，每個后端服務都相互獨立，使后端處理盡可能平衡且高效，從而達到負載均衡目的，根據情況不同，Nginx服務器自動選擇轉發后端服務.

1.3 uWSGI協議

WSGI協議是一種Web Server與Web Application的通信規范協議.uWSGI是WSGI協議的一種具體實現方式，主要功能是接收客戶端請求，再通過WSGI協議轉發給Django框架應用.

2 平臺總體設計

2.1 功能與框架設計

針對就業數據獲取與分析遇到的問題以及微信小程序系統框架研究成果[7],基于Django框架的高校就業信息可視化平臺在功能上分為3部分，分別是就業信息管理及可視化模塊、生源信息管理及可視化模塊和后臺數據獲取模塊.其中就業信息管理及可視劃分為7個模塊，生源信息管理及可視化分為6個模塊.具體功能模塊如圖1所示.

圖1 系統功能設計

系統需要實時從互聯網上獲取就業信息與生源信息進行匯總與分析，并將結果可視化，用戶可以實時的查看生源信息可視化圖表與就業信息可視化圖表.同時用戶在使用平臺的時需要保證用戶信息、就業信息、生源信息的安全性，所以系統實行用戶分級管理，權限由高到低分別是管理員級用戶、校級用戶、院級用戶,三級用戶的系統UML圖，如圖2所示.其中，管理員級用戶是校級用戶的超集，具備校級用戶的一切權限且可以進行用戶管理與公共密碼管理.校級用戶與院級用戶可以瀏覽其權限內的生源信息可視化圖表與就業信息可視化圖表.

圖2 系統UML圖

2.2 數據庫設計

管理平臺所涉數據眾多，包括用戶數據、生源信息數據、就業信息數據等，所有數據都保存在數據庫中，數據表由Django框架的Model基類中的方法自動生成.生成的用戶數據表如表1所示.

表1 用戶數據表

2.3 模型框架

與傳統的Django框架應用MTV軟件架構模式不同的是，平臺采用的是MVC軟件架構模式.模型層(Model)使用的是MySQL數據庫與Django框架模型層封裝方法結合的方式進行編寫，首先使用繼承Django框架中的Model類的數據模型類對數據進行一次封裝，之后使用Django框架自動在MySQL數據庫中生成數據表[8].

視圖層(View)的實現方式是繼承Django框架中的View基類的編寫視圖類，每個視圖類對應后臺的一個API，視圖類中有get方法、post方法、put方法、delete方法，分別對應HTTP協議中的GET、POST、PUT、DELETE方法.繼承了View基類的視圖類會對請求中的method參數進行自動分析，確定所需要調用的方法進行自動的調用.控制器(Controller)使用的是Django框架中的URLCONF，每當一個請求到達Django后臺，框架直接進行參數分析，獲取URL、method等參數，根據配置的urls文件進行自動的路由，然后調用相應的模型層類中的方法運行具體的業務邏輯.

2.4 物理架構設計

由于Nginx服務、HTTPS解析、Django后臺服務等都需要大量的算力與內存，后端服務器中很可能由于搶占算力與內存造成數據爬取的時序問題，嚴重的甚至可能導致數據庫中的數據發生錯誤，因此部署了雙服務器的物理架構，將數據的獲取與存儲過程和后端的服務器進行物理層面的分離.因為后端數據庫合法訪問IP只有后端服務器，所以任何人無法通過任何方式直接調用數據庫中的數據，這種處理方式可以最大程度地保證后臺數據的安全性.

后臺服務器共有3個模塊，從外到內分別是Nginx、uWSGI、Django，其中最外層采用了Nginx服務器，平臺使用了Nginx的網站服務器功能、反向代理服務器功能和負載均衡服務器功能.其將合法的訪問全部轉發給uWSGI的同時也直接代理網站的靜態資源.在后臺服務器中如果使用傳統方式由Django后臺服務器將靜態文件發給uWSGI再發給Nginx的話，會占用服務器大量的內存，因此，使用Nginx對靜態文件進行代理，在收到獲取靜態文件的請求時，不再對請求進行轉發，直接由Nginx使用靜態資源進行應答.第二層使用了uWSGI對Django框架進行進程管理.uWSGI會開啟多個Django進程,Nginx在進行負載平衡時會對這些進程進行調度.最內層是Python虛擬環境，其中運行著Django后臺服務與Xadmin后臺管理器.Django后臺會不斷地讀取數據庫服務器中的實時數據，對前臺進行數據支持.Xadmin是后端Django的管理插件，其作用是對Django的每一次數據庫操作進行日志記錄，同時提供對數據的增刪改查等功能，該功能由管理員與開發者進行使用.為了保證數據的安全性，一些敏感數據不會在Xadmin中進行管理.

數據庫服務器中的爬蟲程序會以一定的頻率反復獲取實時的數據存入數據庫，之后由后臺服務器對數據進行調用.在后臺程序的維護與升級過程中，不會影響到與之進行物理隔離的數據庫服務器中的數據，從而保證數據庫服務器中的數據安全.

系統邏輯架構平臺采用前后端分離開發模式，前端使用微信小程序，后端使用Django框架.整體流程分為3部分，分別是小程序、Django后臺和爬蟲系統，總體邏輯框架如圖3所示.為了方便后端代碼維護與升級，使用Gitee同步代碼，開發者在本地開發與測試代碼，并同步到Gitee，在服務器端拉取.后端服務器采用模塊化部署，因此后端代碼是可熱插拔的，在拉取代碼后即可正常使用.

圖3 系統總體邏輯框架圖

3 平臺實現

3.1 系統功能的實現

首次打開小程序顯示小程序綁定用戶信息頁面.小程序端一共分為4部分，分別是生源數據、就業數據、歷年數據、用戶數據.生源數據與就業數據的主要內容對應調用API接口，對數據進行可視化展示.用戶頁面是對當前用戶信息查看，并且提供解綁功能可以解除當前已登錄用戶和當前微信的綁定.呈現在移動端界面如圖4所示，從左至右為依次為用戶綁定頁面、就業信息可視化頁面、就業地點分布可視化頁面.

圖4 用戶綁定界面與信息可視化頁面效果圖

3.2 關鍵技術分析

登錄模塊采用一種新的登錄方式，選擇自建用戶體系進行用戶管理，該方式具體實現登錄功能如圖5所示.使用Cookies+Session的登錄狀態保存方式存在一個問題,微信小程序與Django服務后臺間存在一個微信服務器，只負責轉發，并不記錄狀態.小程序與微信服務器間不存在上下文關系、微信服務器與Django服務后臺間也不存在上下文關系，因此導致微信小程序與Django服務后臺間不存在直接的上下文關系.為解決此問題，平臺直接在小程序中保存Cookies，僅需調用小程序的Storage，用Storage保存Cookies，之后在每次調用接口時將Cookies加進請求報文中，從而實現小程序的有狀態服務.

圖5 登錄功能時序圖

用戶的信息存儲在后臺服務器中，采用的唯一身份標識是用戶的openid.每個用戶打開小程序后，微信小程序會自動調用wx.login接口獲取用戶的code，之后將用戶code與appid作為參數調用后端authorize接口進行登錄，后端的authorize接口會根據用戶提供的code、appid與后端存儲的小程序appsecret調用微信小程序官方API獲取用戶的openid.其中獲取用戶openid的模塊代碼如下：

def code2session(appid, code):

API = ′https://api.weixin.qq.com/sns/jscode2session′

params = ′appid=%s&secret=%s&js_code=%s&grant_type=authorization_code′ % (appid, WBBB.settings.WX_APP_SECRET, code)

url = API + ′?′ + params

response = requests.get(url=url, proxies=proxy.proxy())

data = json.loads(response.text)

print(data)

return data

其中,proxy模塊為代理模塊，可以設置多個代理接口，在其中一個代理接口超時的情況下，會根據已定義的規則自動選擇其他方式獲取用戶的openid，以保證接口的高可用性.

小程序的code具有時效性且只能使用一次，并且小程序的appsecret是保密數據，因此可以防止惡意用戶使用盜取openid的方式冒名進行登錄.在后端獲取用戶的openid之后，會自動和數據庫中的數據進行比對，如果用戶合法，則返回cookie將用戶狀態設置為已經登錄.如果用戶的openid沒有記錄在系統后臺，系統會自動返回未綁定信息到前端并調用SignUp接口進行注冊綁定.用戶登錄的有狀態信息封裝代碼如下：

if user:

#open id

request.session[′open_id′]= openid

# 是否已經登陸

request.session[′is_authorized′]= True

其中,用戶的openid與登錄信息保存在request中的session中，返回給前臺進行保存[9].

小程序端調用SignUp接口需要前端填寫正確的用戶信息與初始密碼.然后由后端將用戶所填寫信息與合法用戶列表中的信息進行對比.如果信息正確且合法，會在數據庫中保存該用戶的信息與openid，并且自動調用authorize接口對用戶進行登錄.具體的登錄流程如圖6所示.

圖6 登錄流程圖

API數據獲取模塊實行用戶分級管理，為保證數據安全性，小程序端與Django后臺服務器分別對用戶權限進行驗證.在數據獲取接口中，管理員級用戶權限與校級用戶權限并無區別.因此后端接口權限驗證主要分為兩類，一類是管理員級用戶和校級用戶，另一類是院級用戶.為提高代碼重用性，API模塊中常用登錄檢查、身份檢查、Response包封裝等功能都以獨立模塊方式開發，以便調用.API模塊眾多，每個數據具有單獨API模塊支持，但API模塊結構都大同小異.具體調用流程為：小程序端調用API模塊接口，后端先審查用戶是否已登錄，其次審查用戶的權限是否能獲取該數據，若審查通過，則返回封裝好的數據包.

爬蟲模塊用于實時獲取最新生源和就業數據.數據來源是遼寧省大學生智慧就業創業云平臺[10]，該平臺未提供公開使用接口，爬蟲須通過模擬真實用戶方式獲取數據.傳統瀏覽器模擬方式浪費大量計算資源，且效率低，因此采用請求包模擬方式獲取數據.該網站用戶驗證方式是用戶名+密碼+驗證碼方式進行驗證，用戶名和密碼由相關部門授權，驗證碼使用Tesseract-ORC開源庫識別.在模擬登錄成功后保存網站Cookie，再對數據進行有針對性爬取.爬蟲模塊進行一次類封裝，將關鍵信息全部存儲在該類中.該爬蟲類中使用大量的私有方法，用以聲明一些敏感接口與變量在后續的升級與維護中不應被直接使用[11].具體流程如圖7所示.

圖7 爬蟲程序流程圖

4 系統應用效果

基于Django框架的高校就業信息可視化平臺開發完成后，使用Postman工具對平臺各個功能塊進行測試，未出現任何錯誤，各功能模塊滿足應用需求.平臺實現了高校就業信息自動獲取，統計分析和可視化過程中的難點問題，提高了辦公效率.平臺可通過授權方式進行推廣，為各高等院校工作人員帶來便利的同時，也可帶來一定商機.