基于Django 的校園疫情防控系統設計與實現

徐秀芳，夏 旻，徐 森，裴森森，陶奕陽

（1.鹽城工學院信息工程學院；2.鹽城工學院 校長辦公室，江蘇 鹽城 224051）

0 引言

2020 年春節前夕，一場突如其來的新冠肺炎疫情洶涌而至［1-2］。疫情時期，根據國家教育主管部門要求，學校嚴格執行“日報告”“零報告”制度［3］，精準掌握師生員工健康狀況，在加強學生思想疏導和學習生活指導的同時，積極開展線上授課和線上學習等在線教學活動，做好疫情防控期間高校在線教學組織與管理工作［4］。

根據疫情上報需要，很多單位和部門研究開發健康申報系統或微信小程序［5］。余靚等［6］建立數據監測與管理系統平臺，保障武漢14 家方艙醫院平穩高效運行；肖永平［7］設計具有報送提醒、填寫、審核、監測管理和統計分析功能的疫情監測與上報管理系統；鐘機靈［8］設計具有健康打卡、異常報告、返校申請等功能的應急管理服務平臺；李潤川等［9］設計基于云計算的智能健康監測系統；周振發等［10］依托省地理信息公共服務平臺，建立省級疫情防控輔助決策系統等。

以上方法未在校園應用場景方面進行深入細致研究，如師生返校條件審核、進校數據存儲、學生進入學習和生活場所的數據管理、疫情常態化后進出校門管理等。本文系統在滿足日常健康申報的基礎上，通過用戶掃描校園不同地點的二維碼，實現反向追蹤查詢，為疫情防控提供依據。同時，根據風險地區等級實時分析疫情相關數據，形成數據報表或可視化圖表，提供決策支持。

1 需求分析

1.1 系統設計目標

疫情防控初期，由于學校師生員工數量眾多且來自全國各地，校方在進行健康信息收集（電子表格形式統計）時，經常出現信息填寫錯誤、報送不夠及時、工作效率低下、數據更新滯后等問題。高校校園場景急需一套具有健康信息報送、校園軌跡跟蹤和健康數據分析等功能的智能應用系統，為疫情防控提供實時監控和決策依據。

通過網絡調研及校園場景應用需求分析，確定系統主要目標為：①實現師生員工健康信息每日報送［11］；②記錄用戶校園活動軌跡［12］；③根據學校分級管理體系為管理員設置不同權限，分工明確、高效管理；④根據健康數據和活動軌跡，挖掘與疫情相關的有價值信息，提供決策支持［13］。

1.2 性能需求

（1）并發性。確保2 萬人同時段訪問下系統穩定和及時響應。

（2）數據更新。系統存儲用戶健康報送信息，并對權限管理員提供數據查詢、修改等操作，實時更新。

（3）安全性。采取多維度、高強度數據加密等多重安全措施，防止用戶敏感數據泄露。

（4）界面友好。用戶體驗良好，適配PC 端與移動端，可視化圖表輔助用戶挖掘數據。

（5）兼容性。系統界面適應市場主流移動設備與不同PC 端，兼容iOS、Android 等不同手機系統。

1.3 業務需求

（1）師生信息需求。能夠存儲全校師生員工的個人信息與健康信息，包括姓名、證件號、地址、電話、部門及當前位置、接觸狀況等，并以簡潔清晰的不同表單形式填寫。

（2）用戶權限需求。根據學校管理架構，分為教師、職工、本科生、研究生四類用戶，各部門管理員設計不同權限。以學生管理為例，支持班級輔導員、學院學生科、學院領導、校學生處、校領導等多種角色，各司其職。

（3）健康報送需求。健康報送表單完善、全面，系統根據不同用戶自動匹配表單。為提升填寫效率和交互體驗，用戶通過選項按鈕、自動填充默認信息、下拉列表等，以向導提示完成數據填寫。

（4）健康碼需求。參考支付寶的“健康碼”［14］，系統根據用戶填報的數據進行風險評估，從地理位置、接觸狀況、身體狀況等多個維度進行風險評估，分為“高、中、低”3 種風險等級，以紅、黃、綠三色碼呈現“個人健康碼”。同時提供二維碼和條形碼兩種形式的健康碼，方便不同設備讀取，并提供接入掃碼槍功能。特別是在疫情相對穩定時，鹽城工學院作為江蘇省第一批開學的高校，系統為學校順利開學提供了極大支持。

（5）軌跡追蹤需求。根據校園常用地點列表，自動生成地點ID、地點二維碼、批處理數據文檔資源，再由動態二維碼生成器［15］和Photoshop 技術處理，自動批量生成美觀的地點二維碼海報，張貼在校園對應位置，經過或使用該地點的人員通過手機掃描二維碼即可完成地點登記，為用戶行蹤分析提供依據。

（6）歷史數據需求。系統在提供實時數據可視化功能的同時，也提供歷史數據下載。授權用戶通過PC 端頁面進行歷史日期選取，查看并下載歷史健康數據，便于備份和利用電子表格作進一步分析。

2 總體設計

2.1 項目環境

為提高開發效率和便于功能擴展，使用Python 語言及Django 框架開發；為保證WEB 前端的全平臺兼容性，采用Bootstrap4（一種前端開發框架）及Vant（移動端Vue 組件庫）框架技術，Visual Studio Code 進行跨平臺開發［16-18］。生產環境部署在阿里云，使用Aliyun Linux 及Docker（一種應用容器引擎）容器化，并將系統與Uwsgi（一種Web 服務器）一同構建鏡像，使用的Nginx（一種Web 服務器）服務器、MariaDB、Redis（一種內存數據庫）數據庫均為官方容器鏡像。需要分別在Windows、Android 和iOS 的系統環境下進行測試，以保證全平臺的可用性與兼容性。

2.2 疫情防控解決方案

疫情防控解決方案［19-21］主要包括以下功能：健康報送、個人健康碼、地點碼、跟蹤分析和數據可視化等。其中，健康報送與地點碼掃描是整個方案的基礎，后續個人健康碼、軌跡分析、接觸人員跟蹤、人流預估等功能以此數據分析得到。

校園疫情防控系統架構如圖1 所示。系統架構從下向上分為云平臺、運行環境、數據庫、業務層、展示層、用戶界面和訪問層。業務層以下提供數據存儲和開發環境，業務層實現用戶管理、角色管理、權限管理、班級管理、學院管理、記錄審計等功能；展示層提供瀏覽器訪問頁面時的模板引擎渲染數據和AJAX（Asynchronous JavaScript and XML，異步的JavaScript 和XML）請求；前端界面采用最新的UI 技術，保證功能性、美觀性和良好體驗；最上面為訪問層，系統采用HTTPS（Hypertext Transfer Protocol Secure，超文本傳輸安全協議）協議、HSTS（HTTP Strict Transport Se?curity，HTTP 嚴格傳輸安全協議）強制安全策略，通過不同移動端和PC 端為用戶訪問提供數據安全和實時響應。

Fig.1 Campus epidemic prevention and control system architecture圖1 校園疫情防控系統架構

2.3 數據庫設計

疫情防控解決方案采用MariaDB 數據庫，共有28 個表，且各表之間相互關聯，部分E-R（實體-聯系）圖如圖2所示。

（1）用戶表。存儲用戶基本信息和權限，包括用戶id、用戶名、密碼、最后一次登錄時間、姓名、學號（工號）、人員類別、學院（部門）、班級，權限等級、風險等級、風險更新時間、風險原因等。

（2）班級表。存儲班級信息，可指定班級輔導員，包括班級id、班級名稱、學院id、輔導員id 等。

（3）學院（部門）表。存儲系統內的學院或部門信息，包括id 和學院（部門）名稱。

健康報送是系統的主體部分，主要由個人基礎信息和每日健康數據兩個表組成。

（4）基本信息表。記錄用戶基礎信息，包括基本數據id、創建時間、用戶id、籍貫、籍貫地址、校區、宿舍、性別、電話等信息。用戶初次進行健康報送時填寫，之后禁止用戶自行修改。

（5）更新信息表。用于記錄用戶每日健康信息，包括更新數據id、創建時間、用戶id、所在地、接觸疫情嚴重地區人員時間、家庭/小區/村有疑似或感染時間、到訪或途徑高風險地區時間、離開高風險地區時間、健康狀況、非正常健康狀況時間、是否咳嗽、是否發燒、是否呼吸困難、其他疑似癥狀、接觸境外人員時間、家庭成員入境國家等。用戶每日進行健康登記時，都會創建一條更新信息，權限管理員可以日歷形式進行健康審閱。

Fig.2 System E-R diagram（part）圖2 系統E-R 圖（部分）

（6）地點表。記錄校園內教室、實驗室、體育館、校門進/出口等地點信息，包括地點id、校區、地點名稱、位置等信息。

（7）二維碼掃描記錄表。記錄入校掃描記錄，包括學生入校記錄和日常活動地點碼掃描記錄，便于人員位置跟蹤和分析。

（8）輔導員表。用于查看、審核、統計班級學生健康情況，包括輔導員id、姓名、學院id、班級id 等。

3 系統詳細設計

3.1 前端界面設計

系統前端采用Bootstrap4 及Vant 框架技術。Bootstrap4用于開發跨平臺頁面，可以在不同尺寸的設備上提供一致的體驗，有效縮短開發周期。Vant 框架用于設計移動端專屬頁面，提供更加接近原生應用的體驗。移動端界面采用向導式設計，移動端界面設計如圖3 所示。

Fig.3 Interface design of mobile terminal圖3 移動端界面設計

3.2 健康報送模塊設計

健康報送子模塊的表單項根據《江蘇省教育廳疫情上報模塊、學校疫情日報表、入蘇返蘇人員健康狀況統計表》這3 張表進行綜合分析后設計而成，且根據不同人員類別分別設計不同表單。為避免相同信息重復填報，在初次成功報送后，若用戶的健康狀況、地理位置等未發生變化，可選擇“與昨日一致”，3～5s 即可完成健康報送［21］。

（1）信息報表子模塊。根據使用者的權限，生成權限范圍內人員每日健康狀況，由xlsx.js 生成excel 表格，便于數據統計和分析。

（2）信息審計子模塊。用于審計個人基礎信息與健康信息填寫是否正確。系統根據人員的不同健康狀況使用js-year-calendar.js 日歷，以不同色彩顯示，管理員發現異常后可進一步核查，確認是否需要向上一級匯報或修改誤操作狀態。

（3）核心功能代碼。該模塊部分核心代碼如下：

3.3 個人健康碼模塊設計

（1）風險評估子模塊。根據健康報送中的數據，進行異常數據分析，如途經風險地區、家庭/小區/村有確診或疑似病例”、咳嗽發燒、家庭成員身體異常等11 個異常檢查點，對應不同風險等級，以“紅黃綠三色碼”顯示個人健康碼。

（2）健康碼子模塊。健康碼子模塊以黑白條形碼與彩色二維碼兩種方式呈現。采用qrcode.js 技術生成，并根據用戶id 和當前時間加密，通過encodeURIComponent 技術操作后加域名的方式實現，便于手機掃碼讀取。健康碼每分鐘自動刷新，防止截屏保存，提高掃碼的安全性、準確性。

（3）掃碼槍子模塊。為滿足學生開學入校登記的掃碼需求，系統提供準確、高速的掃碼槍功能。管理員掃描“鹽工健康碼”，形成學生入校記錄并顯示其風險狀態，非低風險者系統會進行彈窗警告和語音播報功能。

3.4 地點碼模塊設計

（1）地點碼模塊。根據不同校區、不同樓宇和地點，利用Photoshop 技術，批處理后快速生成地點二維碼。每張二維碼海報包含該地點的全稱、簡稱、地點專屬二維碼，可選附加NFC 芯片，實現一碰即完成登記，并附有防疫宣傳標語及防疫工作組聯系電話，兼顧功能性和美觀性。

（2）掃碼記錄審計子模塊。該子模塊可以按日期查看某個指定地點的全部掃碼記錄。在常態化疫情控控時期，學生可以通過校門口的進、出二維碼進出校門，便于校方掌握學生動態。

3.5 跟蹤分析模塊設計

跟蹤分析模塊也是系統的主要設計目標，數據來源于地點碼的掃碼記錄和健康數據。

在對指定人員進行跟蹤分析時，根據其在某一地點的掃碼記錄，獲取其掃碼前后某一時間段在該地點掃碼的其他人員信息，即可找出可能與此人接觸的其他人員，便于后續篩查。

3.5.1 跟蹤分析步驟

（1）輸入分析數據。前端頁面仿照百度的搜索邏輯，并提供了自動補全功能，僅需輸入被分析人員證件號、姓名、學號、工號等關鍵字，系統便可自動找出最相關的人員，選中人員后可以對其進行跟蹤分析。

（2）掃碼記錄分析。分析內容包括個人信息、個人掃碼記錄及某時段在同一地點的相關人員。相關人員由系統自動查找與分析得出，分析數據由用戶的掃碼記錄與學院、班級、宿舍、籍貫、所在地等個人信息相結合。通過數據庫查找，篩選出用戶掃碼前1 小時與后5 小時計6 小時內的掃碼記錄，將掃碼人添加至可能接觸人員字典，并賦初始權值5，若用戶被多次判定為可能接觸人員，則每次權值加5。

（3）數據信息關聯。完成掃碼記錄分析后，根據獲得的可能接觸人員字典，分析每個可能接觸人員與被分析人員在學院、班級、宿舍、籍貫、所在地等信息上的關聯度。關聯度越大，權值越高，最終按權值降序顯示相關人員列表，有利于后續進一步排查和主動防疫。

3.5.2 核心功能代碼（部分）

3.6 可視化模塊設計

3.6.1 數據可視化

數據可視化模塊則是引入爬蟲技術［22］與ECharts4.0庫，爬蟲獲取“全球新冠病毒最新實時疫情地圖_丁香園”［23］國內各地現存感染人數，以ECharts4.0 中的“地圖”圖表展示，并疊加學校人員當前位置信息，便于查看人員地理位置與疫情局勢。數據可視化頁面如圖4 所示。

此模塊還包括每日報送情況、人員健康狀況等校園數據，以不同圖表顯示，每種圖表均可針對人員類別及人員部門進行篩選，有助于工作人員實時掌握師生的健康動態。

3.6.2 人流量預估

人流量預估圖是系統根據指定地點的歷史校園卡刷卡、掃碼記錄，完成數據清洗后，使用時間序列算法進行預測得出，有助于師生選擇合適的時間段，錯峰用餐、洗澡。人流預估數據可視化頁面如圖5 所示。

4 系統測試

軟件測試是軟件生命周期中的重要組成部分，主要檢測軟件的可靠性。主要包括功能測試、UI 測試、兼容性測試、安全性和訪問控制測試以及性能測試等，而單元測試和集成測試由開發人員執行。

Fig.4 Visualization page of health data圖4 健康數據可視化頁面

Fig.5 Visualization page of passenger flow estimation data圖5 人流預估數據可視化頁面

4.1 功能測試

測試模塊：用戶登錄、健康報送、個人健康碼、地點碼、人流預估、軌跡分析、接觸人群追蹤、數據可視化等功能。

測試過程：各功能模塊均以不同用戶身份進行測試并應用，如用戶提交數據的合法性驗證、軟件功能與交互界面的正確性判定、響應時間的用戶體驗度及系統和數據安全性檢驗等。

測試結論：從健康報送、軌跡分析、接觸人群追蹤、數據可視化等單元測試到整個系統的集成測試，均正確運行。從基礎信息到每日健康報送，從地點碼掃描到風險數據分析，實現校園疫情防控智能化。

4.2 性能測試

系統運行過程中，分別對內存使用、平均負載和網絡流入流出速率等性能進行監測與分析。

24 小時系統平均負載如圖6 所示，網絡流入流出速率如圖7 所示。

Fig.6 Average load of the system（24 hours）圖6 系統平均負載（24 小時）

由圖6 和圖7 可知，平均負載和數據查詢在0 點時會有一個高峰，在7 點半左右會有一個小高峰，這是由于系統每日限定登記時間為0 點到10 點所致。

以8 月28 日為例，根據系統檢測，在0 點時每秒查詢率達到高峰550QPS，此時系統仍能正常處理請求。這是由于系統中的靜態資源交由CDN 處理，網絡流入流出速率保持在5Mbps 以下。系統內存占用在0 點處有一個小的下降，是由于大量訪問觸發了Uwsgi Web 服務器的自動重啟機制，由于同時存在多個Uwsgi 服務進程，重啟不會導致服務中斷，且可以有效防止內存泄漏，在提高性能的同時保證安全性。

Fig.7 Network inflow and outflow rate圖7 網絡流入流出速率

5 結語

面對突發的新冠肺炎疫情，確保師生健康和學校安全穩定成為首要工作。根據學校師生特點及分層管理，設計不同用戶及管理權限，采用Django 框架和Python 語言開發一套用戶體驗好、安全性高、數據可追蹤的健康信息報送系統。與傳統電子表格收集數據相比，數據報送的及時性和準確性得到大幅提升，工作效率提高3 倍以上。自2020年3 月1 日以來，全校2 萬多名師生員工每天通過學校官微中的“健康報送”入口，上報個人健康信息，為領導決策和疫情防控提供數據支持。