基於spring cloud alibaba系統設計說明書

 說明：

1.因爲是從word 複製過來的，很多圖片沒有複製過來。另外，作圖工具是通過processon來做的，需要修改有原型。

2.通過此文檔膜拜，質需要些下你係統具體的業務說明（菜單功能簡單闡述），半天就能寫完一份文檔

3.如何修改說明：

1. 某某系統平臺，修改爲當前系統，全局替換
2. 搜索“需要修改”，查看需要修改的地方。
3. 紅色字體內容做爲參看，基本也是需要修改
4. 搜索“某某公司”，查看位置，需要修改
5. 重新更新目錄

 

 

 

 

 

 

 

某某系統平臺

系

統

架

構

設

計

說

明

書

                                                                                                   某某公司

2020年6月1日

 

如何修改說明：

1. 某某系統平臺，修改爲當前系統，全局替換
2. 搜索“需要修改”，查看需要修改的地方。
3. 紅色字體內容做爲參看，基本也是需要修改
4. 搜索“某某公司”，查看位置，需要修改
5. 重新更新目錄

目錄

1 綜述6

1.1 編制目的 6

1.2 適用範圍 6

1.3 參考依據 6

1.4 約束定義 7

1.4.1 文字符號約束7

1.4.2 圖元約束7

1.4.3 格式約束8

1.4.4 層次定義9

1.5 導讀說明 9

2 系統架構規劃11

2.1 工作背景 11

2.2 設計原則 15

2.3 系統架構總覽 17

2.3.1 應用架構設計17

2.3.2 數據架構設計18

2.3.3 技術架構設計19

3 應用架構26

3.1 應用模塊 26

3.2 運維管理平臺 27

3.2.1 模型管理27

3.2.2 隱蔽工程28

3.2.3 新線籌備與驗交查驗28

3.2.4 資產與設備管理29

3.2.5 質量管理29

3.2.6 應急模擬30

3.2.7 能耗管理30

3.2.8 成本管理31

3.2.9 知識庫管理31

3.3 後臺管理系統 32

3.3.1 系統管理32

3.3.2 權限管理37

3.3.3 資源管理40

3.3.4 系統監控41

4 邏輯架構視圖46

4.1 某某系統平臺後臺架構圖 46

4.2.1展現層46

4.2.2通訊層47

4.2.3 業務層47

4.2 數據庫層 52

4.2.1 基於mysql的數據庫備份和恢復方案52

4.3 服務相關 54

4.4.1、認證系統54

4.4.2日誌系統57

4.4.3回話治理58

4.4.4DNS劫持處理58

4.4 組件視圖 59

4.4.1 組件功能59

5 開發架構視圖61

5.1 項目工程劃分 61

5.2 關鍵代碼展示 64

5.2.1 註冊登錄64

5.2.2 訪問授權70

5.2.3 REST風格接口71

6 開發技術使用規則75

6.1 設計及編碼規範 75

6.1.1 編碼規則75

6.1.2 數據庫設計規範75

6.1.3 異常處理規則76

7 部署架構視圖77

7.1 部署圖 77

7.1.1 網絡拓撲圖77

7.1.2 請求流程圖77

7.2 日誌文件約定 77

8 項目本期的安全系統設計79

8.1 需求分析 79

8.2 信息安全設計原則 79

8.2.1 整體安全原則（木桶原理）79

8.2.2 積極防禦原則80

8.2.3 多重保護原則80

8.2.4 一致性原則80

8.2.5 易操作性原則80

8.2.6 可擴展性原則81

8.2.7 標準化原則81

8.3 信息安全總體設計 81

8.4 信息系統分層安全方案 82

8.4.1 物理層安全方案82

8.4.2 網絡層安全方案82

8.4.3 信息安全評估83

8.4.4 系統層安全方案83

8.4.5 應用層安全84

8.4.6 數據層方案85

 

 

1 綜述

1.1 編制目的

依據《國家中長期科學和技術發展規劃綱要（2006－2020年）》和《國務院關於深化中央財政科技計劃（專項、基金等）管理改革的方案》，在國家重點領域技術預測、交通領域技術預測、關鍵技術遴選工作成果以及面向相關部門、地方和機構廣泛徵集國家重點研發計劃科技創新需求建議的基礎上，科技部會同國家鐵路局、交通運輸部、教育部、中國科學院等部門，組織專家編制了《國家重點研發計劃先進軌道交通重點專項實施方案》，在此基礎上啓動先進軌道交通重點專項，併發布指南。通過對需求進行結構化分析，界定廣州地鐵集團建立某某系統平臺的需求範圍和相關約束條件，爲某某系統平臺設計中的架構設計、詳細設計、相關技術規範以及編碼實現工作提供指導，也爲下一階段某某系統平臺建設中的系統測試、驗收等工作提供參考依據。

1.2 適用範圍

本文檔適用於某某公司某某系統平臺中系統詳細設計階段，以及後期知識管理試點建設、實施推廣、深化建設、應用提升等各階段工作。

1.3 約束定義

1.3.1 文字符號約束

1.3.2 圖元約束

（1） 流程圖圖元約束：

圖形符號	名   稱	定    義
	開始框	標準流程的開始，每一流程圖只有一個起點
	結束框	流程的中斷和結束
	處理框	表示對事件或結果的處理過程
	決策或判斷	用來根據給定的條件是否滿足決定執行兩條路徑中的某一路徑
	流程線	箭頭的方向表示流程執行的方向與順序，兩個符號間不得使用雙箭頭
	連接標識	用於同一流程圖中頁和頁的連續或者用於同頁內從一個動作框轉到另一個動作框
	流程標識	表示在流程圖中引用另一個流程

 

（2） 流程圖展示方式約束：

流程圖推薦採用縱向頁面佈置、橫向職能帶佈置的樣式，另根據需要可增加劃分業務流程階段，但不得改變流程圖基本樣式。

流程圖中所用符號應均勻分佈，連線保持合理的長度，並儘量少用長線。

使用各種符號應注意符號的外形和各符號大小的統一，避免使符號變形或各符號大小比例不一。

符號內的說明文字儘可能簡明。通常按從左向右和從上向下方式書寫，並與流向無關。

儘量避免流線的交叉，即使出現流線的交叉，交叉的流線之間也沒有任何邏輯關係，並不對流向產生任何影響。

一個大的流程可以由幾個小的流程組成。單個流程過於複雜時，在不影響業務的完整性和連續性的前提下，應拆分爲兩個及以上子流程。

所附表單能體現流程要求時，則可簡化流程圖，儘量將表單能體現的流程要求合併爲一個流程節點。

1.3.3 格式約束

文檔模板：文檔編制必須嚴格依據本文檔模板的格式要求。

（1） 引用描述格式

l 《<資料名稱>》<發佈單位><發佈日期>

l 《<資料名稱>》(<文號>)

l 《<資料名稱>》(<標準號>)

（2） 文字格式

l Word樣式，正文首行縮進

l 首行縮進2字符，宋體，小四，1.5倍行距，段前 0，段後 0。

（3） 表格格式

l 列標題，Word樣式，表格標題

l 列標題，首行縮進 無，居中，宋體，五號，單倍行距，段前 0，段後 0。

l 列標題，重複標題行

l 表格正文，Word樣式，表格正文 居左

l 表格正文，首行縮進 無，居左，宋體，五號，單倍行距，段前 0，段後 0。

l 表格正文中的序號，Word樣式，表格正文 居中

l 表格正文中的序號，首行縮進 無，居中，宋體，五號，單倍行距，段前 0，段後 0。

（4） 圖格式

l Word樣式，圖居中

1.3.4 層次定義

業務域劃分及其編碼：

● 戰略管理 SM；

● 營銷服務 BM；

● 安全生產 SP；

● 規劃建設 PP；

● 人力資源 HR；

● 財務管理 FI；

● 物資管理 MM；

● 信息管理 IM；

● 綜合管理 GM；

1.4 導讀說明

編號	如果您是：	請關注以下部分：
1	領導層	第一、二章
2	公司業務人員	第一、二章
3	公司信息人員	第一、二、三章
4	項目建設人員	第二、三、四、五、六、七、八章
5	評審人員	第一、二、三、四、五、六、七、八章

2 系統架構規劃

2.1 工作背景

作爲最具可持續性的交通運輸模式，軌道交通是國民經濟大動脈、大衆化交通工具和現代城市運行的骨架，是國家關鍵基礎設施和重要的基礎產業，對我國經濟社會發展、民生改善和國家安全起着不可替代的全局性支撐作用。

軌道交通科技持續自主創新更是國家通過實施“創新驅動發展”戰略，全面支撐“新型城鎮化”、“區域經濟一體化”、“一帶一路”、“製造強國”和“走出去”戰略的全局性重要基礎保障；對建設創新型國家、構建現代綜合交通運輸體系、在經濟社會發展新常態下，實現全面建成小康社會目標，具有重大意義。

依據《國家中長期科學和技術發展規劃綱要（2006－2020年）》和《國務院關於深化中央財政科技計劃（專項、基金等）管理改革的方案》，在國家重點領域技術預測、交通領域技術預測、關鍵技術遴選工作成果以及面向相關部門、地方和機構廣泛徵集國家重點研發計劃科技創新需求建議的基礎上，科技部會同國家鐵路局、交通運輸部、教育部、中國科學院等部門，組織專家編制了《國家重點研發計劃先進軌道交通重點專項實施方案》，在此基礎上啓動先進軌道交通重點專項，併發布指南。

專項的指導思想是：以滿足國家戰略需求爲目標，以國內外市場需求爲導向，在既有軌道交通科技發展成果的基礎上，以“產學研用”協同創新爲主要模式，強化國際合作創新，通過在軌道交通系統安全保障、綜合效能提升、可持續性和互操作等戰略技術方向進

 

2.2 設計原則

某某系統平臺的設計，遵循“十三五”信息化規劃的總體要求，基於前期業務模型構建成果，以切實發揮本階段承上啓下的作用爲目標，貫穿整個設計研發過程。以下是一些主要的設計原則和規範。

開放性原則

某某系統平臺的可擴展性：系統的設計在軟件上充分考慮系統的可擴展性，採用模塊化設計，以便於隨着系統服務項目的增多和業務量的增加平滑地進行系統的擴充。

系統的可管理性：對系統運行的監測、控制和管理功能，從而保證系統的正常運行。

良好的系統接口：某某系統平臺作爲公司的重要數據中心和信息平臺，要求它與其他現有的各種信息系統相連，以實現資源共享，爲業務層、管理層和決策層提供一個信息化工作環境。系統的開放性原則是實現系統互連的基礎，它使系統具備良好的擴展和互操作能力，以便於系統的維護和管理。

標準化原則

某某系統平臺基於信息技術和現代網絡技術的標準化趨勢有三個方面：

n 業務流程標準化；

n 信息流標準化；

n 數據格式標準化。

某某系統平臺的標準化，成爲了其他系統的連接的樞紐，有助於信息的標準化；信息流標準化的重點是企業各類信息的編碼、管理信息、經營數據和技術數據標準化問題；數據格式標準化主要是爲了解決數據的互聯與互通。實現數據交換和信息的共享，利用先進的信息化管理技術手段實現標準統一，標準要適當超前的目標。

容錯性原則

提供有效的故障診斷及維護工具，具備數據錯誤記錄和錯誤預警能力；具備較高的容錯能力，在出錯時具備自動恢復功能。

安全性原則

用戶認證、授權和訪問控制，支持數據庫存儲加密，數據交換的信息包加密，數據傳輸通道加密，採用密級強度可自定義的標準型加密算法。發生安全事件時，能以事件觸發的方式通知系統管理員處理。

可靠性原則

應能夠連續7×24小時不間斷工作，平均無故障時間達到99.99％以上，出現故障應能及時告警，軟件系統應具備自動或手動恢復措施，自動恢復時間<60分鐘，手工恢復時間<24小時，以便在發生錯誤時能夠快速地恢復正常運行。軟件系統要防止消耗過多的系統資源從而避免系統崩潰。

兼容性原則

滿足向下兼容的要求，軟件版本易於升級，任何一個模塊的維護和更新以及新模塊的追加都不應影響其他模塊，且在升級的過程中不影響系統的性能與運行。

易用性原則

應具有良好的簡體中文操作界面、詳細的幫助信息，系統參數的維護與管理通過操作界面完成；系統的建設應最大限度利用現有的設備和數據資源，保護現有的軟、硬件資源。

 

2.3 系統架構總覽

2.3.1 應用架構設計

某某系統平臺的應用架構如下：

 

流程需要需要修改

實現整個面向全生命週期成本優化的軌道交通設計、建設、運營協同技術之某某系統平臺的“集約建設、規範管理、數據共享、互通協同”，是希望通過爲太和站及夏太、太竹區間的運維管理提供一套更智慧、更有效、多維度的、基於BIM的數字孿生某某系統平臺，將機電管理、信息管理、能源管理、安全管理、質量管理、智能系統管理及各業務等多種類的子模塊進行一體化整合，使多個系統在同一子平臺進行可視化呈現以及協同。同時新增人流密度統計、區域關注、溫度統計、流程審批、節能減排等功能，對站臺門、道岔、低損耗變壓器、緊急疏散等典型專業的全生命週期成本優化關鍵技術進行數據驗證與設計、建設反饋協同。

 

2.3.2 數據架構設計

某某系統平臺的數據來源於外部系統和基於系統的自產生（隱形知識顯性化）

• 外部系統來源：

 

• 隱性知識顯性化：

隱性知識存在於員工的頭腦中，如工作經驗、操作技巧和方法，心得體會等，難以表達和系統化；同時隱性知識也是企業知識管理中的重點和難點。

2.3.3 技術架構設計

技術架構自下而上分爲六層，分別是基礎設施層、數據層、支撐層、服務層、應用層和展示層。

流程需要修改

 

• 基礎設施層：主要是系統層，包括硬件設備和系統軟件，硬件設備主要是爲應用系統提供硬件支撐。採用質量可靠、性能優越、容量滿足未來業務發展的服務器，包括應用服務器和數據庫服務器。在硬件設備層採用集羣實現，保障系統的可用性。 系統軟件主要是成熟的操作系統、中間件、數據庫軟件等，用於構建系統的應用支撐環境。
• 數據層：數據層爲應用系統提供數據服務，通過構建統一的數據中心體系，實現數據資源的充分有效管理和利用。數據類型主要結構化數據、非結構化數據和索引數據。根據不同的數據週期，制定各自的歸檔策略，並且採用適度的常規備份和事件觸發的備份策略，建議每週進行一次全備份，每天進行增量歸檔備份。此外，在進行大數據量的數據導入之後，例如進行完大量知識業務數據的維護之後，在從外部系統導入完歷史數據之後，都要進行一次完整的數據庫備份，以保證在發生意外時，擁有基本實時的數據。
• 支撐層：支撐層是應用系統的基礎服務層，在這一層中提供通用的服務和組件，主要是J2EE容器、工作流引擎、內容引擎和搜索引擎。

² J2EE容器：提供Web應用程序的配置、管理和發佈。包括Web服務器端容器Applet客戶端容器（包含組件爲Applet，Applet是嵌在瀏覽器中的一種輕量級客戶端；應用客戶端容器（包含的組件爲Application Client。能夠使用J2EE的大多數Service和API）。

² 工作流引擎：提供工作流服務，通過工作流引擎靈活實現各業務流程的角色分配和任務走向。

² 日誌引擎：對不同系統進行日誌統一搜集展示處理等。

² 搜索引擎：提供基於索引數據的搜索服務，包括關鍵字查詢、布爾條件查詢等。

• 服務層：服務層提供基於SOA的服務，分爲WebService、FTPService和MQ等。應用層：公共服務。
• 展示層：展示層是整個系統的統一訪問入口和集成前端展現，提供與各類最終用戶進行交互的多種界面。提供統一的訪問授權、個性化控制、內容共享、發佈和訂閱以及面向主題的展現集成。支持不同形式的展示終端，包括瀏覽器、客戶端和PDA/手機。

2.3.3.1 系統可用性

項目中各地鐵運營保障子系統實行獨立運行、分散監控，各子系統與子平臺保持及時、可靠地數據交換與指令溝通。

各子系統之間的操控相對獨立，可通過集成系統的高級控制邏輯和業務邏輯實現聯動控制和業務關聯，但每個子系統的故障均不會影響其它子系統的正常工作。

子系統之間的數據共享通過統一數據庫與協議轉換器完成，最大限度地減少數據流通的中間環節，以分離故障、分散風險、便於管理。

子平臺支持7×24小時穩定運行。子平臺的用戶總人數可大於2000，併發請求考慮按3000用戶併發訪問設計，考慮滿足不同地域、多辦公地點的遠程訪問。服務器併發性能要求在理想的硬件及網絡環境條件下，同時3000併發系統可正常運行。

子平臺把各種子系統集成爲一個有機的統一整體，實現如下功能集成：

1>對地鐵運維保障子系統信息進行表達。

2>對地鐵運維保障子系統進行集中監視和控制。

3>對全局事件進行管理。

4>以相同、相似的業務邏輯對各子系統的信息和業務進行統一管理。

5>以跨系統聯動控制策略實現子系統間的信息關聯、聯動控制。

服務器數據性能：95%以上的數據在5s內完成數據查詢。一般頁面響應時間不大於3秒，全系統全文檢索的響應時間不大於9秒，非全文檢索方式的查詢響應時間不大於5秒。

任何子系統的三維模型圖形加載要求在規定時間內完成。無論任何場景，事件均要求在10秒內報出報警視頻信息和三維場景。提示在報警時3秒內發出。

子平臺運行幀率：1G顯存保證95%的視角在25-50幀，2G顯存可保證95%的視角在50-75幀，4G顯存及以上可保證95%的視角在100幀以上。

任何一個3D場景在調出時，畫面三角形片數不超過100萬個。單個場景中可支持不少於4000個三維模型。

 

2.3.3.2 系統易用性設計

某某系統平臺主用戶界面主要採用基於瀏覽器實現和unity客戶端的實現，支持主流的瀏覽器（谷歌、火狐、IE）和不同類型的顯示終端，所有能夠熟練使用瀏覽器的用戶都能夠方便容易地使用。Unity客戶端能夠通過不同的打包方式運行在windows和ios系統上。同時在設計用戶界面時我們採用快速原型的開發理論，讓用戶在系統實施的早期就從用戶界面的角度提出修改意見，從而保證最終交付的系統具有良好簡單的用戶界面，方便各類用戶使用。

2.3.3.3 系統升級和擴展性設計

某某系統平臺採用前後端分離的模式進行開發，前端採用瀏覽器和unity進行開發。瀏覽器端主要是基礎服務器和系統的統一的管理功能，unity上承載的主要是地鐵三維模型的實際運用。

後端採用的微服務的設計模式，能夠根據服務訪問量，調整服務的數量，以應對不的訪問量需求，以便達到按需購買。從而減少成本，同時能夠應對不斷變化的訪問量。

在這樣一種架構下，可以根據不同的情況對系統進行擴展：

如果整個系統的瓶頸在Web服務器，由於所有的WEB問都將通過負載均衡服務器進行分發，因此我們可以簡單地通過添加WS的方式來提高整個系統的處理能力，圖示如下：

 

如果整個系統的瓶頸在應用服務器，我們可以從垂直（同一機器上的Clone） 和水平（添加機器）兩個方面進行擴展，擴展的圖示如下：

 

 如果系統的瓶頸在數據庫服務器，可以通過增加CPU或者採用更高端的機器來實現。方案中的平臺核心應用服務器軟件支持跨平臺使用，建議方案的開發技術又是基於Java的跨平臺技術，從而保證新系統具有優秀的擴展和升級能力。在進行系統和網絡設計的時候考慮到將來軟硬件的擴展，設備的性能均提前考慮擴展後的需要。

2.3.3.4 系統可靠性設計

方案從幾方面保障系統運行的可靠性：

• HTTP服務可靠性：負載均衡服務器負責將用戶的請求分派到兩臺HTTP服務器上。若其中有任何一臺HTTP服務器出現故障而停止服務，負載均衡服務器會將用戶全部引導到另外一臺工作正常的服務器，保證系統可用。
• 應用服務器的可靠性：HTTP服務器上安裝的應用服務器插件負責將動態的功能請求分派到相應的應用服務器組。本系統中所有應用服務器都成對配置，若有任何一臺應用服務器進程被停止，HTTP服務器上的插件都會將用戶引導到同一應用服務器組上的另外一臺正常的應用服務器上，確保服務不會中止。
• 數據庫服務器的可靠性：使用兩臺數據庫服務器，兩臺數據庫服務器間實現互備。若數據庫服務器遇到異常停止服務，備份服務器會立即接管數據庫服務器的存儲和IP地址，並啓動數據庫服務，確保系統正常運轉
• 網絡可靠性：在設備，鏈路上採用冗餘模式，保證應用數據無間斷的交互，有效的保障了整個系統的可靠性和可用性。

2.3.3.5 系統安全性設計

基於信息系統安全領域的技術和經驗，爲系統提供安全保障。

1）對於系統安全，利用防火牆技術本身的安全性本身設置安全策略，只允許符合規則的業務數據流通過，保障了網絡的安全訪問和內網不同層次的安全。在內網中，通過劃分VLAN，並且使數據只在某一VLAN中傳遞。主機和操作系統通過定期更新系統補丁，關閉不需要的端口和服務，驗證密碼有效長度和期限等來保證系統上的安全。

2）對於數據安全，系統中的數據安全主要體現在四個方面：身份認證、按角色進行分級權限控制、數據加密、操作日誌記錄。

 

 系統實現上將通過數字證書等手段確保終端身份認證；同時，對應不同角色進行不同的訪問權限細分，通過操作日誌記載跟蹤整個系統的使用情況，防止各類用戶的惡意訪問。

• 身份認證分爲身份管理、認證服務、信息服務三部分,採用分級、分域的管理方式，分部門、分子系統管理用戶，建立統一的用戶數字身份信息庫和角色信息庫，集中統一的用戶身份認證，實現單點登錄。
• 分級權限控制包括對用戶操作級別進行劃分，對應用功能進行劃分，對角色進行總結與劃分和角色功能的匹配。
• 對於用戶的所有操作，都記錄與日誌系統中，可以對異常的操作進行追蹤，確保異常的操作可以溯源。
• 數據加密在對關鍵信息的加密存儲上，使用DES或3-DES加密算法。
• 全程日誌管理對系統的運行狀態，操作狀態等信息以統一格式記錄在系統後臺的日誌中，對日誌文件的訪問必須有系統管理員的授權才能訪問。

2.3.3.6 系統易維護性設計

採用的技術都是遵循業界標準的技術，這些技術的使用使系統的管理和維護變得非常容易。同時方案中所有的硬件和軟件產品都有自己的監控管理器。同時在整個方案中的系統管理模塊作爲整個系統運行和維護的工作，方便系統管理員進行系統監控和管理配置。在系統實施的過程中，還將制定系統的運行和維護的相應規範和制度，從而保證新系統能夠穩定地運行。

2.3.3.7 系統高性能和實時性設計

系統使用負載均衡服務將用戶的請求均衡地分發到Web服務器上；如果是動態請求，它又將被均衡地分發到應用服務器上，從而實現用戶請求在系統的動態均衡。在網絡上，使用高性能的網絡設備，以保證數據交互無阻礙，達到快速轉發，以保證應用上的實時性。

 

3 應用架構

3.1 應用模塊

需要修改

需要修改

可能需要修改運維管理平臺側重於三維運用，後臺管理系統對一些通用數據和系統進行統一管理設置。

 

3.2 運維管理平臺                                                                                                                                                                                                                                                                                                                                                                                  

3.2.1 模型管理

a.模型管理

主要包含了模型的查看，模型載入，模型同步功能。通過BIMShare中心，載入模型基本數據，在運維管理平臺中修改主要參數，如果BIMShare中心數據有修改，可以通過同步，將其同步到運維管理平臺。

b.模型映射

主要功能包括：模型查找，模型映射。模型映射將模型定位到具體的模型視圖，修改模型的主要參數，並提交，生產一個模型審覈流程，通過預定的審覈流程進行審覈，並記錄審覈過程。

c.模型審覈

對提交的模型數據進行審覈，這過程需要具有審覈權限的人或者角色才能夠進行審覈操作，審覈完全通過之後，數據進行真正的更新。

-----添加功能模塊介紹

需要修改

 

 

3.3 後臺管理系統

3.3.1 系統管理

 

a.用戶管理

主要功能包括用戶增刪改查、密碼重置，用戶啓用以及禁用。

 

採用左樹右表的設計方式，通過點擊左邊的機構樹，可以對用戶進行過濾。

b.機構管理

       主要功能包括：機構增刪改查。

 

機構類似部門，同時包括了公司這樣的分類。

c.字典管理

字典提供了系統的公共參數。

字典管理包括：系統字典和業務字典。系統字典提供的是可以供系統所用的公共參數。業務字典則是提供某個業務中可以用的參數，在整個系統並不通用。

 

單擊字典

 

 

 

 

 

 

，在右側展示字典詳情

 

d.菜單管理

菜單包括頂部菜單和一般菜單。頂部菜單，顧名思義就是在頂部的菜單，頂部菜單是所用菜單的父類。一般菜單是在管理後臺的左側的菜單，它和頂部菜單的位置不同，同時，在添加一般菜單的時候，可以選擇所屬的頂部菜單。

e.參數管理

參數管理提供的是系統主要參數的設置。

 

f.租戶管理

租戶管理解決了不同租戶的數據隔離需求。同時，可以設定在每個租戶下面的用戶數量等。

 

 

 

3.3.2 權限管理

 

a.角色管理

主要功能包括角色增刪改查、權限設置，角色啓用以及禁用，收回權限，拷貝權限，選擇用戶。

 

權限設置。

 

b.數據權限

      數據權限是業務中，控制不同字段的查看權限。

 

c.接口權限

接口權限控制對外接口的訪問控制權限。

 

3.3.3 資源管理

 

a.對象存儲

 

配置不同的存儲接口，以及存儲資源的位置。

b.短信配置

配置不同的短信接口。

 

c.任務調度

3.3.4 系統監控

 

1. Zipkin監控

       分佈式系統中，存在系統間的相互調用，存在一個資源請求需要調用多個服務器，及其服務間相互調用，一旦調用過程中出錯，問題將很難定位。然後通過Zipkin可以輕鬆的知道一次調用系統之間的調用情況。

1. Turbine監控

       分佈式系統中，相同的節點需要部署多個的情況，很多時候，運維人員希望把這些相同節點一個集羣整體的方式展示出來，這樣能夠更好的把握整個集羣的狀態。

1. Sentinel監控

       隨着微服務的流行，服務和服務之間的穩定性變得越來越重要。Sentinel 是面向分佈式服務架構的輕量級流量控制產品，主要以流量爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助您保護服務的穩定性。

1. 日誌管理

       包括通用日誌、接口日誌、錯誤日誌。通用日誌是對操作的行爲做記錄，接口日誌是接口調用產生的日誌，錯誤日誌是在系統出錯的產生的記錄。

1. 接口文檔

        

 

文檔接口展示如上圖

採用了swagger2自動生成文檔。

1. 服務治理

          

通過集中式的查看各個服務的健康狀態，數量等信息。

1. ELK日誌管理系統

ELK是Elasticsearch、Logstash、Kibana三大開源框架首字母大寫簡稱。市面上也被成爲Elastic Stack。其中Elasticsearch是一個基於Lucene、分佈式、通過Restful方式進行交互的近實時搜索平臺框架。像類似百度、谷歌這種大數據全文搜索引擎的場景都可以使用Elasticsearch作爲底層支持框架，可見Elasticsearch提供的搜索能力確實強大,市面上很多時候我們簡稱Elasticsearch爲es。Logstash是ELK的中央數據流引擎，用於從不同目標（文件/數據存儲/MQ）收集的不同格式數據，經過過濾後支持輸出到不同目的地（文件/MQ/redis/elasticsearch/kafka等）。Kibana可以將elasticsearch的數據通過友好的頁面展示出來，提供實時分析的功能。

ELK工作原理如下：

4 開發環境

技術/標準/協議/工具	名稱	說明
開發語言	Java1.8
開發系統	Windows10
開發工具	Idea 2019.3
版本控制器	Git	分佈式版本控制工具
前端技術	avue2.0、element-ui、unity
前端開發工具	Visual studio
日誌	SFL4j，log4j
數據庫	Mysql5.7
數據庫客戶端	Heidisql3.9	開源免費
數據庫設計工具	Powerdesiner
流程圖、拓撲圖工具	Precesson	在線作圖工具
接口調試工具	Postman
壓力測試工具	AB

 

5 邏輯架構視圖

5.1 某某系統平臺後臺架構圖

 

4.2.1展現層

展現層分爲瀏覽器端和unity兩種的展現方式。

Web前端 基於HTML/HTML5/Vue/CSS3開發web前端頁面，兼容主流瀏覽器。展現層和數據層完全分離，通過跨域實現前後端數據通信；Unity客戶端能夠通過不同的打包方式運行在windows和ios系統上。 Restful接口 基於特定業務，採用Restful標準接口，對外提供數據服務。

4.2.2通訊層

基於TCP/HTTP/HTTPS 三種通信方式，實現前後端數據通信。

4.2.3 業務層

核心業務基於Spring Cloud Alibaba架構實現微服務化。

 Spring Cloud Alibaba是一個基於Spring Boot實現的雲應用開發工具，它爲基於JVM的雲應用開發中的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等操作提供了一種簡單的開發方式。 微服務是可以獨立部署、水平擴展、獨立訪問（或者有獨立的數據庫）的服務單元，Spring Cloud Alibaba就是這些微服務的大管家，採用了微服務這種架構之後，項目的數量會非常多，Spring Cloud Alibaba做爲大管家需要管理好這些微服務。 相關的組件包括如下：

5.1.0.1 Nacos

Nacos是以服務爲主要服務對象的中間件，Nacos支持所有主流的服務發現、配置和管理。四大功能包括：服務發現與服務健康檢查、動態配置管理、動態DNS服務、服務和元數據管理。

Nacos架構圖：

 

5.1.0.2 Netflix Hystrix

   熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。

 

 

5.1.0.3 Spring Cloud Gateway 

Spring Cloud Gateway爲Spring生態系統上的一個API網關組件，主要提供一種簡單而有效的方式路由映射到指定的API，併爲他們提供安全性、監控和限流等等 

Spring Cloud Gateway原理如下：

 

5.1.0.4 Sentinel

集成Sentinel從流量控制、熔斷降級、系統負載等多個維度保護服務的穩定性。

5.1.0.5  Spring Cloud Config

俗稱的配置中心，配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集羣配置，目前支持本地存儲、Git以及Subversion。

 

5.1.0.6 Spring Cloud Bus

 事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。

 

5.1.0.7 Spring Cloud Sleuth

日誌收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作，爲Spring Cloud Alibaba應用實現了一種分佈式追蹤解決方案。

5.1.0.8  Spring Cloud Task

主要解決短命微服務的任務管理，任務調度的工作，比如說某些定時任務晚上就跑一次，或者某項數據分析臨時就跑幾次。

 

 

 

 

5.2 數據庫層

某某系統平臺採用mysql數據庫管理數據，mysql數據庫具有很好的性能，開源，免費滿足項目需求。

 

5.2.1 基於mysql的數據庫備份和恢復方案

Recovery Manager（RMAN）是一種用於備份(backup)、還原(restore)和恢復(recover)數據庫的 Oracle 工具。它能夠備份整個數據庫或數據庫部件，如表空間、數據文件、控制文件、歸檔文件以及Spfile參數文件。RMAN也允許您進行增量數據塊級別的備份，增量RMAN備份是時間和空間有效的，因爲他們只備份自上次備份以來有變化的那些數據塊。

備份策略如下所示：

 

圖 61 數據庫備份示意圖

全庫備份

數據庫每天都進行一次全庫備份，備份設備與實時運用設備分離，備份時間選擇在業務系統不繁忙的夜間完成，備份後可以選擇備份數據的保留時間，在一定階段後備份數據可實現滾動，在驗證下一存儲數據合法性後存儲壓縮以節約存儲介質。

實時增量熱備

mysqldump備份成sql文件

假想環境：
MySQL   安裝位置：C:\MySQL
論壇數據庫名稱爲：bbs
MySQL root   密碼：123456
數據庫備份目的地：D:\db_backup\

腳本：


rem *******************************Code Start*****************************
@echo off

set "Ymd=%date:~,4%%date:~5,2%%date:~8,2%"
C:\MySQL\bin\mysqldump --opt -u root --password=123456 bbs > D:\db_backup\bbs_%Ymd%.sql

@echo on
rem *******************************Code End*****************************

將以上代碼保存爲backup_db.bat
然後使用Windows的“計劃任務”定時執行該腳本即可。（例如：每天凌晨5點執行back_db.bat）

說明：此方法可以不用關閉數據庫，並且可以按每一天的時間來名稱備份文件。

通過%date:~5,2%來組合得出當前日期，組合的效果爲yyyymmdd,date命令得到的日期格式默認爲yyyy-mm-dd(如果不是此格式可以通過pause命令來暫停命令行窗口看通過%date:~,20%得到的當前計算機日期格式)，所以通過%date:~5,2%即可得到日期中的第五個字符開始的兩個字符，例如今天爲2020-02-05,通過%date:~5,2%則可以得到02。（日期的字符串的下標是從0開始的）

 

5.3 服務相關

4.4.1、認證系統 

採用雙token的方式完成jwt。其中accessToken 用於用戶身份認證。refreshToken用於當accessToken失效時重新生成。

用戶登錄：

 

token認證訪問（accessToken失效，refreshToken有效）

 

accessToken和refreshToken 都失效

 

 

4.4.2日誌系統

 

Logstash ：主要是用來日誌的蒐集、分析、過濾日誌的工具，支持大量的數據獲取方式。一般工作方式爲c/s架構，client端安裝在需要收集日誌的主機上，server端負責將收到的各節點日誌進行過濾、修改等操作在一併發往elasticsearch上去。

4.4.3回話治理

此處的會話是指Netty 會話管理。實現Channel自定義會話管理，如會話監控、會話超時、會話重建等。

4.4.4DNS劫持處理

移動端產品在實際用戶環境下會面臨 DNS 劫持、耗時波動等問題，這些 DNS 環節的不穩定因素，導致後續網絡請求被劫持或是直接失敗, 對產品的用戶體驗產生不好的影響。 DNS 有 LocalDNS VS HTTP DNS之分 在長期的實踐中，互聯網公司發現 LocalDNS 會存在如下幾個問題： 域名緩存: 運營商 DNS 緩存域名解析結果，將用戶導向網內緩存服務器; 解析轉發 & 出口 NAT: 運營商 DNS 轉發查詢請求或是出口 NAT 導致流量調度策略失效; 爲了解決 LocalDNS 的這些問題，業內也催生了 HTTP DNS 的概念，它的基本原理如下: 原本用戶進行 DNS 解析是向運營商的 DNS 服務器發起 UDP 報文進行查詢，而在 HTTP DNS 下，我們修改爲用戶帶上待查詢的域名和本機 IP 地址直接向 HTTP WEB 服務器發起 HTTP 請求，這個 HTTP WEB 將返回域名解析後的 IP 地址。 比如 DNSPod 的實現原理如下:

 

相比 LocalDNS, HTTP DNS 會具備如下優勢: 根治域名解析異常: 繞過運營商的 DNS，向具備 DNS 解析功能的 HTTP WEB 服務器發起查詢; 調度精準: HTTP DNS 能夠直接獲取到用戶的 IP 地址，從而實現準確導流; 擴展性強: 本身基於 HTTP 協議，可以實現更強大的功能擴展。

 

5.4 組件視圖

 

 

 

 

 

 

 

5.4.1 組件功能

1) brower這裏的是客戶端統稱，代表pc端

2) Controller 控制器，所有的請求都會交到此處進行處理

3) Database數據庫

4) View 用戶端看到的數據

5) 事務模型

6 開發架構視圖

 

其中service可以進行無限擴展，放在不同的服務器上面，提示系統的併發性能，以及可用性，例如其中同訪問的service1掛機的時候，客戶的請求自動切換到相同訪問的其他service1上面去，提高了可用性。

6.1 項目工程劃分

如圖

 

├── blade-auth -- 授權服務提供

├── blade-common -- 常用工具封裝包

├── blade-gateway -- Spring Cloud 網關

├── blade-ops -- 運維中心

├ ├── blade-admin -- 服務監控

├ ├── blade-develop -- 代碼生成

├ ├── blade-flow -- 工作流

├ ├── blade-flow-design -- 工作流設計器

├ ├── blade-log -- 日誌模塊

├ ├── blade-resource -- 資源模塊

├ ├── blade-turbine -- 監控控制檯

├ ├── blade-xxljob -- 分佈式任務調度

├ ├── blade-xxljob-admin -- 分佈式任務調度後端

├ ├── blade-zipkin -- 分佈式鏈路追蹤

├ └──

├── blade-service -- 業務模塊

├ ├── blade-desk -- 工作臺模塊

├ ├── blade-system -- 系統模塊

├ └── blade-user -- 用戶模塊

├── blade-service-api -- 業務模塊api封裝

├ ├── blade-desk-api -- 工作臺api

├ ├── blade-dict-api -- 字典api

├ ├── blade-scope-api -- 數據權限api

├ ├── blade-system-api -- 系統api

└── └── blade-user-api -- 用戶api

項目後端模塊介紹，

1）blade-gateway起到的了對所有客戶端的請統一過濾、轉發的作用，同時只對客戶端暴露一個接口即可。減少了由於服務器遷移帶來的端口的修改問題，它統一服務對外的接口。

2）blade-auth 對用戶信息進行認證和授權。

3）Nacos 所有的服務包括balde-auth，blade-gateway，blade-desk，都需要在Nacos 服務上註冊，從而通過註冊中心統一發現和管理這些服務，監控其運行情況。

4）service 業務層邏輯都在此服務上。

6.2 關鍵代碼展示

6.2.1 註冊登錄

OAuth2.0的引入：
抽象驗證流程
由於OAuth1過於複雜，之後對OAuth進行了改造引入了Oauth2.0。OAuth的授權過程如下：

 

 

(A) 客戶端從資源擁有者那裏請求授權。授權請求能夠直接發送給資源擁有者，或者間接地通過授權服務器這樣的中介，而後者更爲可取。

(B) 客戶端收到一個訪問許可，它代表由資源服務器提供的授權。

(C) 客戶端使用它自己的私有證書到授權服務器上驗證，並出示訪問許可，來請求一個訪問令牌。

(D) 授權服務器驗證客戶端私有證書和訪問許可的有效性，如果驗證通過則分發一個訪問令牌。

(E) 客戶端通過出示訪問令牌向資源服務器請求受保護資源。

(F) 資源服務器驗證訪問令牌的有效性，如果驗證通過則響應這個資源請求。

上面只是一個抽象的驗證流程，根據上面的抽象流程演化出四種驗證模式：
授權碼模式
授權碼模式和上述的 抽象驗證模式流程比較相似：

 

(A) web客戶端通過將終端用戶的user-agent重定向到授權服務器來發起這個流程。客戶端傳入它的客戶端標識符、請求作用域、本地狀態和一個重定向URI，在訪問被許可（或被拒絕）後授權服務器會重新將終端用戶引導回這個URI。

(B) 授權服務器驗證終端用戶（藉助於user-agent），並確定終端用戶是否許可客戶端的訪問請求。

(C) 假定終端用戶許可了這次訪問，授權服務器會將user-agent重定向到之前提供的重定向URI上去。授權服務器爲客戶端傳回一個授權碼做獲取訪問令牌之用。

(D) 客戶端通過驗證並傳入上一步取得的授權碼從授權服務器請求一個訪問令牌。（需要帶上ClientId和Secret，ClientId和Secret是通過平臺授予）

(E) 授權服務器驗證客戶端私有證書和授權碼的有效性並返回訪問令牌。

授權碼模式（implicit grant type）
User-Agent子態適用於客戶端不能保存客戶端私有證書的App（純客戶端App，無Server參與）。因爲可純客戶端的程序不能保存密鑰

 

(A) 客戶端將user-agent引導到終端用戶授權endpoint。客戶端傳入它的客戶端標識符、請求作用域、本地狀態和一個重定向URI，在訪問被許可（或被拒絕）後授權服務器會重新將終端用戶引導回這個URI。

(B) 授權服務器驗證終端用戶（通過user-agent）並確認終端用戶是許可還是拒絕了客戶端的訪問請求。

(C) 如果終端用戶許可了這次訪問，那麼授權服務器會將user-agent引導到之前提供的重定向URI。重定向URI會在URI片斷{譯者注：URI片斷是指URI中#號之後的內容}中包含訪問令牌。

(D) user-agent響應重定向指令，向web服務器發送不包含URI片斷的請求。user-agent在本地保存URI片斷。

(E) web服務器返回一個web頁面（通常是嵌入了腳本的HTML網頁），這個頁面能夠訪問完整的重定向URI，它包含了由user-agent保存的URI片斷，同時這個頁面能夠將包含在URI片斷中的訪問令牌（和其它參數）提取出來。

(F) user-agent在本地執行由web服務器提供的腳本，該腳本提取出訪問令牌並將它傳遞給客戶端。

密碼模式
密碼模式就是將密碼託管給第三方App，但是必須要保證第三方App高度可信。

 

（A）用戶向客戶端提供用戶名和密碼。

（B）客戶端將用戶名和密碼發給認證服務器，向後者請求令牌。

（C）認證服務器確認無誤後，向客戶端提供訪問令牌。

客戶端模式
這種模式不需要終端用戶的參與，只是Client和Server端的交互。通常只用於Client狀態的獲取。

 

（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。

（B）認證服務器確認無誤後，向客戶端提供訪問令牌。

授權流程
這裏以授權碼方式流程說明，主要流程分爲兩步，獲取授權碼和通過授權碼獲取資源票據：

 

（A）用戶訪問客戶端，後者將前者導向認證服務器。

（B）用戶選擇是否給予客戶端授權。

（C）假設用戶給予授權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個授權碼。

（D）客戶端收到授權碼，附上早先的"重定向URI"，向認證服務器申請令牌。這一步是在客戶端的後臺的服務器上完成的，對用戶不可見。

（E）認證服務器覈對了授權碼和重定向URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。

 

 

6.2.2 訪問授權

用戶通過瀏覽器發起請求，請求到達服務器，通過Nginx轉發到指定的服務，請求到網關服務，通過網關的轉發，去獲取相應的服務，在獲取訪問之前，如果請求被授權攔截，那麼不要先獲取授權信息，成功之後獲取到相應的服務，服務器返回數據給客戶端。

訪問流程如下：

 

 

6.2.3  REST風格接口

一種軟件架構風格、設計風格，而不是標準，只是提供了一組設計原則和約束條件。它主要用於客戶端和服務器交互類的軟件。基於這個風格設計的軟件可以更簡潔，更有層次，更易於實現緩存等機制。

REST 描述了一個架構樣式的互聯繫統（如 Web 應用程序）。REST 約束條件作爲一個整體應用時，將生成一個簡單、可擴展、有效、安全、可靠的架構。由於它簡便、輕量級以及通過 HTTP 直接傳輸數據的特性，RESTful Web 服務成爲基於 SOAP 服務的一個最有前途的替代方案。用於 web 服務和動態 Web 應用程序的多層架構可以實現可重用性、簡單性、可擴展性和組件可響應性的清晰分離。開發人員可以輕鬆使用 Ajax 和 RESTful Web 服務一起創建豐富的界面

運維子平臺後臺才用的swaggerui作爲接口界面。

 

 

6.2.3.1 模型管理接口

接口截圖預覽

（1）模型管理api

 

（2）模型映射（列表）api

 

（3）獲取token的api的調試

 

7 開發技術使用規則

 

【根據系統開發期質量屬性對開發採用的技術進行約定】

7.1 設計及編碼規範

7.1.1 編碼規則

1）類名使用 UpperCamelCase 風格，必須遵從駝峯形式，但以下情形例外：DO / BO / DTO / VO / AO

2）方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須遵從 駝峯形式

3）常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。

4）抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類命名以它要測試的類的名稱開始，以 Test 結尾

5）枚舉類名建議帶上 Enum 後綴，枚舉成員名稱需要全大寫，單詞間用下劃線隔開。

7.1.2  數據庫設計規範

  1）數據表命按照模塊劃分，頭部是模塊打頭

  2）適當進行冗餘便於業務代碼和性能

7.1.3 異常處理規則

1）finnaly與try塊不同的是——finally塊中的語句總是會被執行，無論是try塊中的語句成功執行還是你在catch塊中處理了一個異常。因此所有開啓的資源都能夠確保被關閉。

2）將異常和它的描述一併拋出

3）優先捕獲更加明確的異常

4）不要捕獲throwable

8 部署架構視圖

7.1規劃：

LB-01:192.168.1.191 nginx+keepalived-master
LB-02:192.168.1.192 nginx+keepalived-backup
VIP：192.168.1.99

OS：CentOS 7.4 X64

 

可能需要修改

 

 

8.1 日誌文件約定

日誌是按照不同模塊進行存放。個模塊之間是按照循環方式創建日誌，日誌達到一定數量舊的日誌數據被丟棄，同時日誌按照不同級別進行存放

 

9 項目本期的安全系統設計

9.1 需求分析

隨着安全系統建設越來越大，除了需要協調各個安全系統之間的問題之外，由於安全相關的數據量越來越大，有些關鍵的安全信息和告警事件常常被低價值或無價值的告警信息所淹沒，原有安全系統不有滿足所有系統的安全需求，一些全局性的、影響重大的問題很難被分析和提煉出來。爲了從大量的、孤立的單條事件中準確的發現全局性的、整體的安全威脅行爲，需要一個平臺使得整個安全體系的檢測能力更加準確，更加集中於影響重大的焦點問題。

9.2 信息安全設計原則

信息安全建設是一個系統工程，系統專用網絡系統安全體系建設應按照“統一規劃、統籌安排，統一標準、相互配套”的原則進行，採用先進的“平臺化”建設思想，避免重複投入、重複建設，充分考慮整體和局部的利益，堅持近期目標與遠期目標相結合。

在進行信息系統安全方案設計、規劃時，應遵循以下原則：

9.2.1 整體安全原則（木桶原理）

一個由許多塊木板組成的木桶，如果組成木桶的這些木板長短不一，那麼這個木桶的最大容量不取決於長的木板，而取決於最短的那塊木板。同樣，一個由許多信息安全設備組成的信息安全防禦系統，其信息安全防禦水平取決於針對某種信息安全風險性能最低的信息安全設備。

應用該觀點，分析網絡的安全及具體措施。安全措施主要包括：行政法律手段、各種管理制度（人員審查、工作流程、維護保障制度等）以及專業措施（識別技術、存取控制、密碼、低輻射、容錯、防病毒、採用高安全產品等）。一個較好的安全措施往往是多種方法適當綜合的應用結果。一個計算機網絡，包括個人、設備、軟件、數據等。這些環節在網絡中的地位和影響作用，也只有從系統綜合整體的角度去看待、分析，才能取得有效、可行的措施。即計算機信息安全應遵循整體安全性原則，根據規定的安全策略制定出合理的信息安全體系結構。

9.2.2 積極防禦原則

隨着黑客技術的提高，對信息安全也提出更高的要求。防禦黑客除了傳統的邊界防禦設備外，還需具備智能化、高度自動化、響應速度快的信息安全產品，配備技術力量雄厚、響應及時的本地化服務隊伍，才能做好各種預防檢測工作，達到防患於未然。

9.2.3 多重保護原則

任何安全防禦措施都不是絕對安全的，都可能被攻破。但是建立一個多重安全保護系統，各層保護相互補充，當一層保護被攻破時，其它層保護仍可保護信息的安全，才能夠有效抵禦各種安全風險。

9.2.4 一致性原則

一致性原則主要是指信息安全問題應與整個網絡的工作週期（或生命週期）同時存在，制定的安全體系結構必須與網絡的安全需求相一致。安全的網絡系統設計（包括初步或詳細設計）及實施計劃、網絡驗證、驗收、運行等，都要有安全的內容及措施，實際上，在網絡建設的開始就考慮信息安全對策，比在網絡建設好後再考慮安全措施，不但容易，且花費也小得多。

9.2.5 易操作性原則

安全措施需要人去完成，如果措施過於複雜，對人的要求過高，本身就降低了安全性。其次，措施的採用不能影響系統的正常運行。不能夠違背信息化建設必須以應用系統爲基礎，滿足業務高效、易操作的原則。

9.2.6 可擴展性原則

由於網絡系統及其應用擴展範圍廣闊，隨着網絡規模的擴大及應用的增加，網絡脆弱性也會不斷增加。一勞永逸地解決信息安全問題是不現實的。同時由於實施信息安全措施需相當的費用支出。因此充分考慮系統的可擴展性，根據資金情況分步實施，既可滿足網絡系統及信息安全的基本需求，亦可節省費用開支。

9.2.7 標準化原則

在軟件、硬件、網絡、安全和制度建設等方面都必須遵守國家和行業的相關法規、標準和規範。充分考慮工作特點，補充和完善符合實際的組織業務信息標準。

9.3 信息安全總體設計

信息安全系統是整體的、動態的。信息安全系統符合MPDRR模型（M-management，P-protect，D-detection，R1-responce，R2-recovery），因此，要真正實現一個系統的安全，就需要建立一個從保護、檢測、響應到恢復的一套全方位的安全保障體系：

 

信息安全方案基於MPDRR模型構建，符合信息安全系統整體性和動態性的特點，是一個統一的、可擴展的安全體系平臺。

9.4 信息系統分層安全方案

網絡的全面解決方案包括物理安全、網絡安全、系統安全、應用安全、信息安全及數據層安全等各個方面。

 

9.4.1 物理層安全方案

保證計算機信息系統各種設備的物理安全是保障整個網絡系統安全的前提。物理安全是保護計算機網絡設備、設施以及其它媒體免遭地震、水災、火災、雷擊等自然災害，人爲的破壞或誤操作及各種計算機犯罪行爲導致破壞的過程。

嚴格禁止內部辦公網用戶撥號上網，避免單點破網，被黑客“偷渡”入網。

9.4.2 網絡層安全方案

• 內部局域網與外單位網絡、內部局域網與不信任域網絡之間可以通過配備防火牆來實現內、外網或不同信任域之間的隔離與訪問控制，服務器區與不同信任域之間的隔離與訪問控制。
• 根據具體應用，也可以配備應用層的訪問控制軟件系統，針對局域網具體的應用進行更細緻的訪問控制。

9.4.3 信息安全評估

對於黑客的攻擊，除了被動防禦外，還應做到主動預防。信息安全性掃描分析系統通過實踐性的方法掃描分析網絡系統，檢查系統存在的弱點和漏洞，提出建議補救措施和安全策略的報告，根據掃描報告結果來配置或修改網絡系統，達到增強信息安全性的目的。操作系統漏洞掃描系統是從操作系統的角度，以管理員的身份對獨立的系統主機的安全性進行評估分析，找出系統配置、用戶配置的安全弱點，建議補救措施。

9.4.4 系統層安全方案

• 對於Windows NT網絡系統，可採取以下措施:
• 使用NTFS文件系統，它可以對文件和目錄使用ACL存取控制表;
• 系統管理員賬號由原先的“Administrator”改名，使非法登錄用戶不但要猜準口令，還要先猜出用戶名;
• 對於提供Internet公共服務的計算機，廢止Guest賬號，移走或限制所有的其它用戶賬號;
• 打開審計系統，審計各種操作成功和失敗的情況，及時發現問題前兆，定期備份日誌文件;
• 及時安裝補丁程序。

與此同時，利用相應的掃描軟件對其進行安全性掃描評估、檢測其存在的安全漏洞，分析系統的安全性，提出補救措施。最後對管理人員應加強身份認證機制及認證強度。建議使用增強身份驗證系統，比如基於令牌的一次性口令認證系統等。

9.4.5 應用層安全

應用系統通常包括數據庫系統及專爲某些應用開發的系統。對於數據庫系統的安全，通常需要注意以下方面：

用戶分類：不同類型的用戶應該授予不同的數據庫訪問，管理權限。比如：數據庫系統登陸權限，資源管理權限，數據庫管理員權限，遠程訪問權限等。

數據分類：對每類用戶他能夠使用的數據庫是不同的，要進行數據庫分類。不同的用戶訪問不同的數據庫系統。

審計功能：DBMS提供審計功能對維護數據庫的安全是十分重要的，它用來監視各用戶對數據庫施加的動作。可以通過用戶審計和系統審計兩種方式來發現數據庫使用過程中出現的問題，從而找到安全隱患。

數據庫掃描：利用數據庫漏洞掃描軟件可以對數據庫的安全狀況進行完整的分析，並給出修補漏洞，增強安全性的建議。週期性的對數據庫進行這種掃描可以降低人爲造成的（有意或無意的）數據庫的安全風險。

對於非常機密的數據，可以考慮以加密的形式存儲數據。

數據庫備份與恢復：因爲數據在存儲，傳輸過程中可能出現故障，同時計算機系統本身也可能發生一些意料之外的事情，如果沒有事先採取數據備份措施，將會導致慘重的損失。因此數據庫的備份與恢復也是數據庫的一個安全功能，它必須提供。數據庫系統的備份可以採取多種方式進行。

對於專爲某項應用開發的系統，也應該進行安全配置，儘量做到只開放必須使用的服務，而關閉不經常用的協議及協議端口號。還有就是對應用系統的使用要加強用戶登錄身份認證。確保用戶使用的合法性，嚴格限制登錄者的操作權限，將其完成的操作限制在最小的範圍內。並充分利用應用系統本身的日誌功能，對用戶所訪問的信息做記錄，爲事後審查提供依據。

9.4.6 數據層方案

要保護部門間的數據在處理傳輸存儲過程中不被泄露，必須對數據進行加密。數據加密的方法有從鏈路層加密、網絡層加密及應用層加密。鏈路層加密機主要根據鏈路協議（Frame Relay、X.25、DDN、PSTN），採用相應類型的加密機；網絡層加密由於是在網層上，因此它對鏈路層是透明的，與鏈路是何種協議無關；應用層加密主要適用於具體的加密需求，針對具體的應用進行開發。使用單位可以根據自身網絡特點及應用需求選擇合適的加密方法。對本系統，建議採用網絡層加密設備和應用層加密軟件，來保護數據在網絡上傳輸的安全性。