1. 性能 (performance)
性能是指系統的響應能力，性能測試經常要使用基準測試(benchmark test).
提高性能的辦法：
異步化 - 使用消息系統 和 batch處理
緩存 - 有多重緩存政策，本地緩存，分布式緩存同步，緩存伺服器。
系統分割（水準和垂直分割）-
資料庫讀寫分離 -
性能測試的辦法：基準測試
2. 可靠性（reliability)
是軟體系統在應用或系統錯誤面前，在意外或錯誤使用的情況下維持軟體系統的功能特性的基本能力。
可靠性度量：
可靠性度量标準通常用于計算單個解決方案元件的故障機率。用于定義元件或系統可靠性的一個度量标準是平均故障間隔時間 (mtbf)。mtbf 是平均間隔時間，通常以千小時或萬小時（有時稱為“開機時間”或 poh）進行表示，即經過此間隔時間後元件出現故障并需要修複。mtbf 使用以下公式進行計算：
<code>mtbf = (total elapsed time - sum of downtime)/number of failures</code>
衡量可靠性的名額有容錯性和健壯性.
健壯性。保護應用程式不受錯誤使用和錯誤輸入的影響，在遇到意外錯誤事件時確定應用系統處于定義好的狀态。也就是盡可能多的考慮到異常情況，并傳回給使用者有意義的錯誤資訊。盡量減少“系統錯誤”之類的回報。
主要的可靠性設計技術包括：
容錯設計技術：常用的軟體容錯技術主要有恢複快設計，n版本程式設計和備援設計。恢複快設計中包含有若幹功能相同、設計差異的程式塊，每一時刻有一個處于運作狀态，一旦某程式出現故障，則用備份程式塊予以替換。n版本設計的核心是通過設計出多個子產品或不同版本，對于相同初始條件和相同輸入的操作結果進行多數表決（防止因其中某一軟體子產品/版本的故障而提供了錯誤的服務，以實作軟體容錯）。備援設計的思路來源于硬體系統，但有所不同。軟體備援設計技術是采用多種不同路徑，不同算法或不同實作方法的子產品或系統作為備份，在出現故障時進行替換，維持系統的正常運作。
檢測技術：在無須線上容錯或不能采用備援設計技術的部分，但又有較高可靠性需要時，一般采用檢測性設計，在軟體出現故障後能及時發現并報警，明顯的缺點是不能自動解決故障。
降低複雜度設計： 軟體的複雜性與軟體可靠性有密切關系，軟體複雜性是産生軟體缺陷的重要根源。降低複雜度設計的思想就是在保證實作軟體功能的基礎上，簡化軟體結構。
3. 可用性（availability）
是系統能夠正常運作的時間比例。
可用性＝系統運作時間/(系統運作時間＋系統停機時間)
percentage
of availability = (total elapsed time - sum of downtime)/total elapsed time
可用性通常以“九”進行度量。例如，可用性級别為“三個九”的解決方案能夠在 99.9% 的時間内支援其預期功能，相當于在 24x7x365（每天
24 小時/每周七天/一年 365 天）的基礎上，每年 8.76 小時的年停機時間.
或者用公式可用度 = mttf / mtbf
mtbf (mean time between failure) = mttf (mean time to failure) + mttr ( mean time to repaire)
平均失效間隔時間 = 平均失效等待時間 + 平均失效修複時間。
提高可用性的設計技術：
可以能過分布式并行系統來提高系統的準确率，并行系統的好處當一個節點出現問題，另一個節點任然可以工作
4. 安全性（security)
是指系統在向合法使用者提供服務的同時能夠阻止非授權使用者使用的企圖或拒絕服務的能力
5.可修改性（modifiability)
是指能夠快速地以較高的性能價格比對系統進行變更的能力。包含以下4個方面
可維護性（maintainability)
可擴充性（extendibility)
結構重組（reassemble)
可移植性（portability)
6. 功能性 （functionality)
是指系統能所能完成所期望的工作的能力。
7.可變性（changeability)
是指體系結構經擴充或變更而成為新體系結構的能力。(書上的東西就是虛）
8.互操作性（inter-operation)
作為系統組成部分的軟體不是獨立存在的。經常與其他系統或自身環境互相作用。為了支援互操作性，軟體體系結構必須為外部可視的功能特性和資料結構提供精心設計的軟體入口。
9.可伸縮性（scalability)
這個書上沒有提，但是在實際大型分布式系統架構中很重要，攸關生死，沒有可伸縮性，taobao就沒辦法支撐雙11，而這裡的可伸縮性主要是指水準擴充的能力(scale out)，就是随着業務的增長，系統能夠提供平滑水準擴充以支撐業務的發展。
提高可伸縮性的辦法：
應用伺服器叢集 - 通過對叢集加減機器來調整對服務的支援能力，涉及的技術有esb，無狀态session管理，分布式緩存等...
業務垂直分割 - 對相關業務進行切分，例如将listing, selling, checkout 分拆成獨立的系統
分表分庫 - 系統的瓶頸往往出現在資料庫端，因為應用伺服器可以叢集，通常會采用分表分庫的方法來水準擴充資料庫，選取合适的資料路由算法，因為分割後，不同的資料要知道去哪個表哪個庫能找到，常用的資料路由算法有mod 和 lookup
10. 可監控性 （monitorability ）
這個是我自己想出來的，因為監控真的也是太重要了。沒有監控的系統，就像是一輛沒有儀表盤的汽車，你不知道車速，不知道油量，也不知道車況，車子也許也還能跑，但會跑的很不安心。這就是老大們總喜歡讓下面的人開發各種各樣的dashboard，這樣有什麼問題就一目了然了，而下面的人，如果你足夠聰明的話，在沒有人要求的情況下，就能發現那些值得監控的點，并做成dashboard，這樣老大們會對你刮目相看的。
敏感點是一個或多個構件（或之間的關系）的特性，例如加密級别越高，安全性越好，那麼加密級别就是安全性這個品質屬性的敏感點。
權衡點是影響多個品質屬性，是多個品質屬性的敏感點。例如加密級别越高，安全性越好，但可能耗費更多的處理時間，影響系統性能。則加密級别就是安全性和性能的權衡點。同樣使用緩存技術，可以提高系統性能，但是在維護緩存（同步，更新）上會增加系統的複雜度，則緩存就是性能和系統複雜度的權衡點。
有架構師，開發人員，維護人員，內建人員，測試人員，性能工程師，安全專家，項目經理，産品經理，使用者，系統管理者，網絡管理者，領域代表，系統設計師。
一般首先要精确地得出具體的品質目标，并為之作為綁定該體系結構優劣的标準。
scenarios are used to
–represent stakeholders’ interests (描述利益相關者的關注點）
–understand quality attribute requirements （了解品質屬性需求）
–
scenarios should cover a range of
–anticipated uses of (use case scenarios),
–anticipated changes to (growth scenarios), or
–unanticipated stresses (exploratory scenarios) to the system.
a good scenario makes clear what thestimulus is that causes it and what responses are of interest.
scenarios examples：
use case scenario
–remote user requests a database report via the web duringpeak period and receives it within 5 seconds.
growth scenario
–add a new data server to reduce latency inscenario 1 to 2.5 seconds within 1 person-week.
exploratory scenario
–half of the servers go down during normal operation withoutaffecting overall system availability.
scenarios should be as specific as possible.
可修改性是saam分析的主要品質屬性。
是在saam基礎上發展起來的基于場景的分析方法，主要針對性能、可用性、安全性和可修改性，在系統開發之前，對這些品質屬性進行評估和折中。
整個atam評估過程包括九個步驟，按其編号順序分别是：
• techniques
- utility tree generation
- architecture elicitation and analysis
- scenario brainstorming/mapping
• outputs
- architectural approaches
- utility tree
- scenarios
- risks and “non-risks”
- sensitivity points and tradeoffs
atam customer representative describes the system’s business driversincluding:
– business context for the system
– high-level functional requirements
– high-level quality attribute requirements
–architectural drivers: quality attributes that “shape” the architecture
–critical requirements: quality attributes most central to the system’s success
architect presents an overview of the architectureincluding (for example):
–technical constraints such as an os, hardware, or middle-ware prescribed for use
–other systems with which the system must interact
–architectural approaches/styles used to address qualityattribute requirements
evaluation team begins probing for and capturing risks.
identify any predominant architecturalapproaches – for example:
–client-server
–3-tier
–proxy
–publish-subscribe
–redundant hardware
identify, prioritize, and refine the most importantquality attribute goals by building a utility tree.
–a utility tree is a top-down vehicle for characterizing the “driving” attribute-specific requirements
–select the most important quality goals to be the high-level nodes (typically performance, modifiability, security, and availability)
–scenarios are the leaves of the utility tree
output: acharacterization and a prioritization of specific quality attribute requirements.
stakeholders generate scenarios using a facilitatedbrainstorming process.
–scenariosat the leaves of the utility tree serve as examples to facilitate the step.
–the new scenarios are added to the utility tree
identify the architectural approaches impacted by thescenarios generated in the previous step.
this step continues the analysis started in step 6 using thenew scenarios.
continue identifying risks and non-risks.
continue annotating architectural information.
architectural approaches
utility tree
scenarios
risks and “non-risks”
sensitivity points and tradeoffs