軟件架構設計--期末復習

質量屬性

參考視頻：【13.5質量屬性-架構評估】

在軟件架構中，質量屬性是衡量系統設計優劣的關鍵指標，通常分為運行時屬性和非運行時屬性。以下是一些常見的質量屬性：

一、軟件架構中的質量屬性

運行時屬性：
- 性能（Performance）：系統在指定時間內處理請求的能力（如響應時間、吞吐量）。
- 可用性（Availability）：系統在需要時可正常運行的時間比例（如避免宕機）。
- 可靠性（Reliability）：系統在一定時間內無故障運行的能力。
- 安全性（Security）：保護數據和系統免受攻擊的能力。
- 可伸縮性（Scalability）：系統通過增加資源應對負載增長的能力。
- 容錯性（Fault Tolerance）：在部分故障時仍能繼續運行。
非運行時屬性：
- 可維護性（Maintainability）：系統易于修改和修復。
- 可擴展性（Extensibility）：系統支持新增功能的便利性。
- 可測試性（Testability）：系統易于驗證功能正確性。
- 可移植性（Portability）：系統在不同環境中遷移的能力。

二、12306系統中最重要的兩個質量屬性

對于中國鐵路客戶服務中心（12306）這類高并發、高負載的在線票務系統，最關鍵的兩個質量屬性是：
1. 性能（Performance）
2. 可用性（Availability）

為什么是這兩個屬性？

性能（Performance）
- 原因：
  12306在春運、節假日等高峰期需應對每秒數百萬級并發請求（如查詢余票、下單支付）。若性能不足，會導致響應延遲、交易失敗，甚至系統崩潰。
- 實際改進：
  12306通過引入分布式架構、云計算資源彈性擴展、異步處理（如排隊機制）、緩存優化（如余票信息緩存）等技術，顯著提升了吞吐量和響應速度。
可用性（Availability）
- 原因：
  系統需保障7×24小時不間斷服務，尤其是在購票高峰期，短暫的宕機會導致大量用戶無法購票，引發社會影響。
- 實際改進：
  通過多數據中心容災、負載均衡、服務降級（如流量高峰時簡化非核心功能）等策略，確保核心服務始終可用。

其他屬性的權衡

安全性：雖重要（需防止黃牛刷票、數據泄露），但相比性能和可用性，可通過獨立的安全層（如風控系統）補充。
可擴展性：是性能的支撐手段，但最終目標仍是保障高性能和高可用。

三、總結

12306作為公共服務平臺，其核心使命是在極端負載下穩定、高效地提供服務。性能確保海量請求被及時處理，可用性保障系統持續運行，二者直接決定了用戶體驗和社會效益，因此是最關鍵的質量屬性。

可靠性計算

在這里插入圖片描述

計算1：所有組件都是必需情況下，整個系統可靠性
計算2：至少一條路徑可運行的概率

在這里插入圖片描述

CPM計算最小執行時間

在這里插入圖片描述
參考視頻：【2 六時計算】

FF = 緊后工作ES - EF
最晚結束時間LF從后向前算：min(緊后工作LS)
TF = LS - ES

在這里插入圖片描述
關鍵路徑 $A \to C \to E \to F$ .最小總時間 $160$ .

軟件架構風格

在這里插入圖片描述

主程序/子程序風格

在這里插入圖片描述
如果從質量屬性上答，可以從以下幾個方面回答：

模塊化：每個子程序獨立實現，便于單獨測試和維護（可維護性）。因為每個子程序是獨立的，可以直接給其他項目使用，具有可重用性。
可擴展性：新增功能只需增加新的子程序，無需修改主程序邏輯。
清晰的控制流：主程序明確管理邏輯處理，確保每一步按預期執行。

優點

結構清晰：主程序負責流程控制，子程序專注于具體功能，邏輯分層明確。
易于開發調試：模塊化設計簡化了單元測試和問題定位。
低技術門檻：適合小型團隊或簡單業務場景。

在這里插入圖片描述

缺點

高耦合性：主程序與子程序之間依賴性強，修改主程序可能影響全局。
擴展性差：新增功能需修改主程序邏輯，難以適應復雜需求變化。
性能瓶頸：主程序集中調度可能成為單點性能瓶頸。

在這里插入圖片描述

CS風格和BS風格的4個不同點

客戶端依賴：CS需安裝獨立客戶端軟件；BS僅需瀏覽器，無需額外安裝。
維護復雜度：CS需同步更新所有客戶端；BS僅更新服務端代碼，用戶無感知。
跨平臺能力：
BS天然支持多終端（PC/移動端）；CS需適配不同操作系統。
技術側重：CS側重客戶端性能與本地計算（如C++/Java）；BS聚焦Web技術棧（HTML/JS）與網絡傳輸優化。

1. 安裝與部署方式

CS 架構	BS 架構
客戶端需要獨立安裝軟件（如桌面應用），服務器端部署服務邏輯。	客戶端無需安裝，直接通過瀏覽器訪問（如網頁應用）。
示例：早期的銀行柜臺系統、單機游戲。	示例：Gmail、在線辦公工具（如飛書）。

2. 客戶端計算負載

CS 架構	BS 架構
客戶端承擔較多業務邏輯和計算（“胖客戶端”），如數據校驗、本地緩存。	客戶端僅負責展示和簡單交互（“瘦客戶端”），核心邏輯在服務器端完成。
優勢：減少服務器壓力，適合復雜本地操作（如圖形渲染）。	優勢：輕量化客戶端，依賴服務器算力。

3. 維護與升級

CS 架構	BS 架構
客戶端需手動更新版本（用戶主動下載安裝包），維護成本高。	服務端更新后，瀏覽器自動同步最新版本，無需用戶操作。
劣勢：版本碎片化風險（如舊版本兼容性問題）。	優勢：統一用戶體驗，快速迭代。

4. 跨平臺能力

CS 架構	BS 架構
客戶端需為不同操作系統（Windows/macOS/Linux）分別開發。	瀏覽器作為統一運行環境，天然支持跨平臺訪問。
示例：Photoshop（需下載對應系統版本）。	示例：Figma（瀏覽器中直接使用）。

總結：如何選擇？

CS 適用場景：
需要高性能本地計算（如設計軟件）、離線操作（如工業控制）、復雜交互（如游戲）。
BS 適用場景：
強調便捷訪問（如電商平臺）、快速迭代（如SaaS應用）、跨平臺兼容性（如在線文檔）。

現代系統常結合兩者優勢（如“混合架構”）：

核心業務邏輯用 BS 實現（易維護），
特定功能（如文件上傳、硬件交互）用 CS 插件補充。

軟件架構設計

分層架構設計購票系統

分層架構通過將系統劃分為多個層次（如表示層、業務邏輯層、數據層等），實現職責分離和高內聚低耦合，適合購票系統的模塊化設計和高并發需求。

（1）軟件架構圖設計

（2）架構元素標注說明

客戶端（表示層）
? Web前端：基于瀏覽器的用戶界面（如React/Vue）。

? 移動端App：Android/iOS應用程序，提供購票功能。
應用服務器（業務邏輯層）
? 購票管理：處理用戶選座、鎖座、生成訂單等邏輯。

? 支付處理：集成第三方支付（如支付寶、微信支付），完成交易流程。

? 庫存管理：實時更新票務庫存，防止超賣。
數據庫/外部服務（數據層）
? 票務數據庫：存儲演出/車次信息、座位庫存等。

? 用戶數據庫：存儲用戶賬戶、訂單記錄。

? 第三方支付接口：與支付寶、微信支付等對接，完成支付驗證。

架構特點
? 職責分離：各層專注于特定功能（如表示層負責交互，業務層負責邏輯）。

? 可擴展性：可通過橫向擴展應用服務器應對高并發購票請求。

? 安全性：通過HTTPS加密通信，數據庫隔離敏感數據。

? 容錯性：數據庫主從復制、支付接口重試機制提升可靠性。

主程序/子程序風格設計購票系統

開發基于主程序子程序的購票系統
要求，名稱，該軟件架構風格優缺點，畫出該程序的軟件架構圖并在其中標注主要元素

主程序-子程序架構的優缺點

優點

結構清晰：主程序負責流程控制，子程序專注于具體功能，邏輯分層明確。
易于開發調試：模塊化設計簡化了單元測試和問題定位。
低技術門檻：適合小型團隊或簡單業務場景。

缺點

高耦合性：主程序與子程序之間依賴性強，修改主程序可能影響全局。
擴展性差：新增功能需修改主程序邏輯，難以適應復雜需求變化。
性能瓶頸：主程序集中調度可能成為單點性能瓶頸。

軟件架構圖

主要元素說明

主程序（綠色模塊）：核心調度中心，負責調用子程序并協調流程。
子程序（藍色模塊）：獨立功能單元（如用戶驗證、支付處理等）。
數據庫（橙色模塊）：存儲用戶、票務和訂單數據。

工作流程

用戶發起請求 → 主程序調用子程序鏈。
子程序返回結果 → 主程序更新數據庫并響應。
異常由主程序統一處理（如支付失敗重試）。

基于發布訂閱風格設計系統

發布-訂閱架構的優缺點

優點

解耦性：發布者與訂閱者無需直接交互，通過消息代理（Broker）通信，降低系統耦合。
動態擴展：可靈活新增發布者或訂閱者，無需修改現有組件。
異步通信：支持高并發場景，訂閱者按需消費消息，提升吞吐量。
廣播能力：一條消息可被多個訂閱者同時接收（如新聞分類推送）。

缺點

復雜性：需依賴消息代理（如Kafka、RabbitMQ），增加運維成本。
消息延遲：異步傳遞可能導致訂閱者接收消息不及時。
可靠性風險：消息代理若宕機，可能丟失未持久化的消息。

軟件架構圖

主要元素說明

發布者（橙色模塊）：
- 新聞發布者、廣告發布者等，負責生成事件（如新聞內容）。
消息代理（紫色模塊）：
- 核心中間件（如Kafka），管理主題（Topic），按規則路由消息。
訂閱者（綠色模塊）：
- 消費者（如用戶端、數據分析服務），訂閱特定主題并處理消息。

工作流程

發布階段：新聞/廣告發布者將消息發送到消息代理的指定主題（如 tech_news）。
路由階段：消息代理根據主題匹配訂閱者，推送消息。
消費階段：訂閱者異步接收消息（如用戶App展示新聞）。

基于管道過濾器設計系統

管道-過濾器架構的優缺點

優點

模塊化與復用性：
- 每個過濾器（如查詢、支付）獨立運行，可單獨開發、測試和復用。
高內聚低耦合：
- 過濾器之間僅通過標準數據格式（如JSON）通信，無直接依賴。
靈活擴展：
- 新增功能（如優惠券核驗）只需插入新過濾器，無需修改現有邏輯。
并行處理能力：
- 支持多用戶并發購票，不同過濾器可并行處理不同請求。

缺點

事務一致性挑戰：
- 跨過濾器的原子操作難實現（如支付成功后訂單生成失敗需回滾）。
性能瓶頸風險：
- 線性管道可能導致延遲累積（如多個過濾器串行處理）。
數據格式強約束：
- 管道間需嚴格定義數據格式，修改可能影響全鏈路。

軟件架構圖

主要元素說明

用戶終端（灰色模塊）：用戶交互入口（Web/App）。
過濾器鏈（綠色模塊）：
- 請求解析過濾器：標準化用戶輸入。
- 票務查詢過濾器：查詢可用票務數據。
- 座位選擇過濾器：鎖定用戶所選座位。
- 訂單生成過濾器：生成訂單明細。
- 支付處理過濾器：調用第三方支付接口。
- 訂單持久化過濾器：將訂單寫入數據庫。
數據庫（紫色模塊）：存儲票務、訂單和用戶數據。

工作流程

數據流動：
- 用戶請求 → 請求解析 → 票務查詢 → 座位選擇 → 訂單生成 → 支付處理 → 訂單持久化 → 返回結果。
異常處理：
- 任一過濾器失敗（如支付超時），終止流程并觸發補償（如釋放鎖定座位）。

基于事件驅動設計系統

事件驅動架構的優缺點

優點

解耦與靈活性：
- 服務（如訂單、支付、庫存）通過事件異步通信，無直接依賴，可獨立擴展和部署。
高吞吐與實時性：
- 事件隊列（如Kafka）支持高并發處理，適合秒殺等高流量場景。
容錯與可恢復性：
- 事件持久化后重試機制可保障最終一致性（如支付失敗后自動回滾庫存）。
動態擴展：
- 新增服務（如數據分析）只需訂閱相關事件，無需修改現有系統。

缺點

復雜性高：
- 需管理事件總線、消費者組、重試策略，開發與運維成本較高。
調試困難：
- 分布式追蹤復雜，事件鏈路長時問題定位耗時。
數據一致性延遲：
- 異步處理可能導致短暫的數據不一致（如庫存顯示延遲）。

軟件架構圖

主要元素說明

用戶終端（灰色模塊）：用戶購票入口（App/Web）。
API網關（橙色模塊）：請求路由、鑒權與限流。
微服務（綠色模塊）：
- 訂單服務：生成訂單并發布 OrderCreated 事件。
- 庫存服務：訂閱訂單事件，鎖定庫存并發布 StockLocked 事件。
- 支付服務：訂閱庫存事件，處理支付并發布 PaymentCompleted 事件。
- 通知服務：訂閱支付事件，發送短信/郵件通知。
- 審計服務：訂閱所有關鍵事件，記錄操作日志。
事件總線（紫色模塊）：消息中間件（如Kafka），負責事件存儲與路由。
數據庫（紅色模塊）：各服務私有數據庫（遵循領域驅動設計）。