前言

本文是學生管理系統業務架構設計文檔，用於指導子系統開發、測試，與網關、數據庫維運。

詞彙表

nginx: 負責反向代理請求到各個子系統

springboot: 入門檻低且強大的 web 應用服務搭建的框架

RESTful: 一種 http request 的設計風格

actuator: springboot 提供的套件，幫助監控管理應用程式。

1. 業務背景

隨著學校規模不斷擴大，學生數量增加，需要處理的信息也日趨增大，手動維護這些信息不僅增加教師工作量，效率也很低，因此帶來幾個明顯的系統問題:

• 學生信息量大，修改不便。

• 對一系列數據分析花費時間長

• 缺乏系統化、規範化、自動化的管理

基於以上背景，我們需要根據業務需求進行合適的子系統切分，以提升整體的管理效率。

2. 約束和限制

• 反向代理採用 nginx

• 數據庫採用 MySQL

• 至少能支撐 1 萬名的學生信息管理

• 所有數據不可丟

3. 總體架構

3.1 架構分析

3.1.1 可擴展

將學生管理系統拆成三個子系統，當學生子系統或課程子系統故障時，不會互相影響，未來若要擴充業務，也能較容易的新增子系統去支持新業務。

當特定子系統的請求數量大到單一個服務器無法支撐時，也可以用冗余的方式增加單一子系統的實體，以支撐更大量的請求

3.1.2 高性能

目前需求只需要支撐 1 萬名學生管理，除了選課期間與期末評分，平時同時上線使用的人應該不多，所以不需要要求非常高的性能，若是選課期間請求量大增，可以透過臨時增加相關子系統的服務器台支援暫時的大量請求。

3.1.3 高可用

校方要求數據絕對不可丟，所以透過主備機制儲存學生管理系統相關數據，即使一台數據庫故障，還是可以從另一台數據庫做復原。

3.1.4 成本

基本需要六台服務器，nginx 一台，三個子系統各一台，數據庫主備共兩台。

3.1.5 安全

權限管理子系統與數據庫必須保證帳號密碼有一定強度的加密保護，不容易被破解，進而修改或獲得學生信息、破壞系統。

3.2 總體架構

1. nginx 負責將請求正確導向對應的子系統

2. 學生子系統與課程子系統開始使用前，都必須先向權限子系統確認用戶有對應的權限設定，以確保不會操作到沒有權限的功能。

3. 學生子系統可透過課程子系統獲得課程相關信息，如課程詳細信息、成績查詢等。

4. 課程子系統可透過學生子系統獲得學生基本信息進行選課、排課。

5. 採用主備模式的數據庫，主數據庫服務器接收寫請求，以同步的方式複製數據到備數據庫服務器，以確保數據都有兩份，不會丟數據。

6. 主數據庫服務器只提供寫，備數據庫服務器只提供讀，進而達到讀寫分離。

4. 詳細架構

4.1 核心功能

名詞說明: 授權信息 為登入成功後，權限子系統返回給客戶端，以便操作其他系同時，作為判別是否授權的信息。

4.1.1 系統登入

1. 客戶端提供帳號密碼，向權限子系統發送登入請求。

2. 權限子系統查詢數據庫，獲得使用者信息。

3. 權限子系統確認使用者有可登入，並返回登入成功給客戶端。

4.1.2 權限控管

依用戶角色提供對應的權限功能

以學生子系統為例，此流程也直接套用至課程子系統。

1. 客戶端提供授權信息，向學生子系統索取功能清單。

2. 學生子系統向權限子系統詢問權限信息

3. 權限子系統查詢數據庫，並返回對應的權限信息給學生子系統。

4. 學生子系統根據權限信息，返回可使用的功能清單給客戶端。

4.1.3 選課

1. 客戶端提供授權信息，向課程子系統申請選課。

2. 課程子系統向權限子系統詢問此客戶端所屬系所

3. 學生子系統查詢數據庫，並返回系所信息給課程子系統。

4. 課程子系統依據系所信息查詢數據庫，並獲得此系所的可選的課程列表。

5. 課程子系統確認客戶端選擇的課程為可選的課程

6. 課程子系統嘗試在數據庫將學生註冊到指定課程中 (有可能滿額)

7. 數據庫返回寫入成功給課程子系統，課程子系統即返回選課成功給客戶端。

4.1.4 統計課程成績

1. 客戶端提供授權信息，向課程子系統要求查看課程成績。

2. 課程子系統向數據庫查詢考勤紀錄、作業成績、考試成績

3. 課程子系統依據數據庫返回的所有數據，使用預設的成績計算比例產出每個學生的最終成績。

4. 課程子系統返回成績統計結果給客戶端

4.2 關鍵設計

4.2.1 數據存儲高可用

使用主備兩台數據庫服務器，數據複製採用同步複製的方式，只有在兩台數據庫服務器都寫成功時才會返回成功，這樣可以保證數據有兩份，當一台故障時，還能從另一台復原。

4.2.2 系統可擴展

依核心業務將學生管理系統拆分為學生子系統、課程子系統、權限子系統，未來若有新的業務，可以很容易的新增一個子系統，並融入現有架構。

4.3 設計規範

• 子系統採用 springboot 框架開發

• 子系統導入 springboot actuator 以便運維監控應用

• 子系統間用 RESTful API 溝通，數據傳輸格式為 JSON。

• 單一帳號不允許同時多人登入

• MySQL 使用 InnoDB 儲存引擎

5. 質量設計

5.1 可測試性

業務功能皆以 RESTful API 實現，透過 Postman 或 RESTful client 即可測試。

5.2 可維護性

開放 jmx 連接，並提供相關 operation，以應付系統特殊狀況可做關鍵狀態的修改。

5.3 可觀測性

使用 springboot actuator 提供接口查看系統關鍵設定與狀態

5.3 成本

• 團隊都熟悉 Springboot 跟 MySQL，迭代開發可按業務優先級順序進行。

• 硬件最小需要 6 台服務器，未來在依上線運行狀況擴容。

• 未使用到付費產品，所以不需要額外授權經費。

5.4 安全

• 帳號密碼能阻擋暴力破解的攻擊

• 數據庫儲存的密碼與學生重要信息不為明碼

6. 演進規劃

6.1 學生管理系統一期

6.1.1 權限控制

• 所有的用戶帳號與權限只能由開發團隊手動建置到數據庫中

• 學生按實際組織管理層級劃分

6.1.2 學生管理

• 透過登入系統的帳號不同，而獲得不同的權限。

• 能夠查詢課程信息

6.1.3 課程管理

• 提供管理者課程錄入、選擇教材

• 提供學生選課、排課

6.2 學生管理系統二期

6.2.1 權限控制

提供介面設置，讓管理者可以生成教師帳號並分配管理權限。

6.2.2 學生管理

• 提供作業、課堂筆記的文件上傳/下載

• 提供學生帳號綁定，以便實現帳號自助找回。

6.2.3 考試管理

• 提供自動試卷區域分割

• 提供教師評分功能