一般地，對于軟件系統的需求而言，分為兩類：功能性需求和非功能性需求。軟件系統的架構設計既要滿足軟件的功能性需求，還要滿足軟件的非功能性需求。特別地， 系統架構對軟件非功能性需求的支撐成為架構的質量屬性。本文描述了軟件的10個質量屬性， 但不意味著每個質量屬性都會在架構設計中呈現，可以挑選對產品最重要的質量屬性，然后進行實現。

1 可伸縮性

隨著用戶或請求數量的增加，系統運行和操作的能力也隨之增加。在云平臺上，可伸縮性可以通過機器的水平或垂直縮放或者簡單地附加 AutoScalingGroup 來實現。

流量模式: 了解系統的交通模式。盡可能多地產生機器是不劃算的，即使它的利用率不高。

• 日行模式: 特定地區的交通在早上增加，晚上減少。
• 全局/區域模式: 區域大量使用應用程序。
• 突發流量: 許多用戶都在請求資源，但是只有少數幾臺機器可以為突發的流量提供服務。這些可能發生在高峰期或人口密集地區。

自動縮放: 能夠迅速產生一些機器，以處理流量的爆發，當需求正在減少時，優雅地收縮。

延遲: 能夠盡快為請求提供服務。這還包括優化算法和在用戶位置附近復制系統，以減少請求的往返。

2 可用性

它以正常運行時間的百分比來衡量，并定義了系統正常運行和正常工作的時間比例?？捎眯允艿较到y錯誤、基礎設施問題、惡意攻擊和系統負載的影響。

部署標記: 部署應用程序組件的多個獨立副本，包括數據存儲區

區域部署: 將后端服務部署到一組地理節點中，每個節點都可以服務任何區域中的任何客戶端請求。

3 可擴展性

可擴展性度量擴展了系統的能力和實現擴展所需的工作。擴展可以通過添加新功能或修改現有功能來實現，該原則規定在不損害當前系統功能的情況下進行增強。

模塊化/可重用性: 可重用性和可擴展性使得技術可以以更少的開發和維護時間轉移到另一個項目，同時增強了可靠性和一致性。

可插拔性: 能夠輕松地插入其他組件，比如微內核架構。

4 一致性

一致性保證每個讀操作返回最近的寫操作。這意味著在執行每個操作之后，所有節點的數據都是一致的，因此，，無論它們連接到哪個節點，所有客戶端都可以同時看到相同的數據。一致性提高了數據的新鮮程度。

5 彈性

系統可以從容地處理意外故障和惡意故障并進行恢復，檢測故障并快速有效地恢復對于保持彈性是必要的。

可恢復性: 準備的過程和功能能夠在發生意外更改后將服務返回到初始運行狀態。意外的更改包括應用程序的軟刪除或硬刪除或錯誤配置。災難恢復包括了旨在防止或盡量減少災難性事件造成的數據丟失和業務中斷的最佳實踐，涵蓋了從設備故障和局部停電到網絡攻擊、民事緊急情況、犯罪或軍事攻擊以及自然災害。

設計模式:

• 隔離: 將應用程序的元素隔離到池中，以便在一個池失敗時，其他元素繼續運行。
• 斷路器: 當連接到遠程服務或資源時，處理可能需要花費不同時間來修復的故障。
• 選舉: 通過選舉一個實例作為負責管理其他實例的領導者，協調分布式應用程序中協作任務實例集合執行的操作。

6 易用性

可用性可以描述為一個系統的能力，為其用戶提供一個條件，以執行任務的安全有效，同時擁有良好的用戶體驗。它是指特定的消費者能夠使用軟件在量化的環境中以有效、高效和滿意的方式實現量化目標的程度。

易訪問性: 讓具有最廣泛特征和功能的人可以使用該軟件。這包括失聰、失明、色盲等用戶。

易學性: 用戶學習如何使用軟件有多容易？

API 契約: 對于內部團隊，理解 API 契約有助于輕松接入任何系統。

7 可觀測性

可觀測性是收集關于程序執行、模塊內部狀態及組件間通信的數據的能力。為了提高可觀測性，可以使用各種測試跟蹤技術和工具。

日志記錄: 在每個請求中生成不同類型的日志: 事件日志、事務日志、消息日志和服務器日志。

警報和監控: 準備監控儀表板，創建 SLI (服務水平指示器)并設置關鍵警報。

L1/L2/L3: 為 L1/L2設置隨叫隨到的支持流程。L1支持包括與客戶交互，L2支持 L1路由到它們的工單，并幫助進行故障排除。L3是支持的最后一環，通常包括一個解決技術問題的開發團隊。

8 安全性

軟件保護信息和數據，使人或其他產品或系統有相應的數據訪問類型和授權水平。這一系列特征包括機密性(數據只能被授權訪問) ，完整性(軟件防止未經授權訪問或修改軟件或信息) ，不可否認性(能否證明已經發生的行為或事件) ，問責性(能否追蹤用戶的行為)和真實性(驗證用戶的身份)。

可審核性: 審核并跟蹤系統活動，以便在發生安全性缺陷時，可以確定缺陷的機制和程度。遠程存儲審計跟蹤(可以防止入侵者掩蓋其蹤跡。

合法性:

• 遵守: 遵守 GDPR、 《個保法》等關于數據保護的法律法規。
• 隱私: 對公司內部員工隱藏事務的能力(加密的事務，甚至 DBA 和網絡架構師也看不到它們)。

身份驗證: 確保用戶身份的安全性要求。

授權: 確保用戶只能訪問應用程序中的某些功能(通過用例、子系統、網頁、業務規則、字段級別等)。

9 持久性

持久性是軟件可服務性的解決能力，能夠較長時間地滿足用戶的需求。

復制: 涉及共享信息，以確保冗余資源之間的一致性，從而提高可靠性、容錯性或可訪問性。

容錯性: 容錯性是一種特性，它使系統能夠在某些組件出現一個或多個故障時繼續正常運行。

可歸檔性: 數據是否需要在一段時間后歸檔或刪除？(例如，客戶數據將在三個月后被刪除，或被標記為過時，并存檔在備用數據庫中，以便將來訪問。)

10 敏捷性

敏捷已經成為當今描述當代軟件方法的流行語，相關的敏捷團隊可能是一個能夠適應變化的團隊。

可維護性: 應用更改和增強系統有多容易？表示開發人員可以修改軟件以改進、糾正或使其適應環境和需求變化的有效性和效率程度。

• 可測試性: 開發人員和其他人員測試軟件的容易程度
• 易于開發: 開發人員在不引入缺陷或降低現有產品質量的情況下修改軟件的程度

可部署性: 在提交部署之后到代碼投入生產的時間。

可安裝性: 易于在所有必要的平臺上安裝系統。

可升級性: 在服務器和客戶端上從此應用程序/解決方案的以前版本輕松/快速升級到較新版本的能力。

可移植性: 系統是否需要在多個平臺上運行？(例如，前端是否需要針對 Oracle 和 SAP 運行？）

可配置性: 最終用戶可以輕松地更改軟件配置的各個方面(通過可用的接口)。

兼容性: 產品、系統或組件在共享相同的硬件或軟件環境時，與其他產品、設計或成員交換信息并執行所需功能的程度。

小結

了解了軟件架構中的10個質量屬性，我們可能需要考慮哪一個質量屬性更是適合自己的產品或項目。那么，如何在項目中繼續采用這些特性呢？

一旦了解了功能性需求，嘗試找出系統中可能給這些功能增加障礙的瓶頸。如何找到瓶頸呢？可以試著回答幾個這樣的問題:

• 系統能否在100M以上用戶規模的基礎上運行？
• 系統能處理10,000個并發請求嗎？
• 是否以安全的方式處理數據？
• 是否可以在不影響現有工作特性的情況下輕松地添加更多特性？
• ......