513
係統架構評估
軟件質量屬性
1. 性能 (Performance)
性能是指係統的響應能力，性能測試經常要使用基準測試(Benchmark Test).
提高性能的辦法：
異步化 - 使用消息係統 和 batch處理
緩存 - 有多重緩存策略，本地緩存，分布式緩存同步，緩存服務器。
係統分割（水平和垂直分割）-
數據庫讀寫分離 -
性能測試的辦法：基準測試
基準測試（benchmarking）是一種測量和評估軟件性能指標的活動。你可以在某個時候通過基準測試建立一個已知的性能水平（稱為基準線），當係統的軟硬件環境發生變化之後再進行一次基準測試以確定那些變化對性能的影響。這是基準測試最常見的用途。(Reference: https://www.blogjava.net/qileilove/archive/2012/07/05/382241.html)
2. 可靠性（Reliability)
是軟件係統在應用或係統錯誤麵前，在意外或錯誤使用的情況下維持軟件係統的功能特性的基本能力。
可靠性度量：
可靠性度量標準通常用於計算單個解決方案組件的故障概率。用於定義組件或係統可靠性的一個度量標準是平均故障間隔時間 (MTBF)。MTBF 是平均間隔時間，通常以千小時或萬小時（有時稱為“開機時間”或 POH）進行表示，即經過此間隔時間後組件出現故障並需要修複。MTBF 使用以下公式進行計算：
MTBF = (total elapsed time - sum of downtime)/number of failures
衡量可靠性的指標有容錯性和健壯性.
健壯性。保護應用程序不受錯誤使用和錯誤輸入的影響，在遇到意外錯誤事件時確保應用係統處於定義好的狀態。也就是盡可能多的考慮到異常情況，並返回給用戶有意義的錯誤信息。盡量減少“係統錯誤”之類的反饋。
主要的可靠性設計技術包括：
- 容錯設計技術：常用的軟件容錯技術主要有恢複快設計，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)
平均失效間隔時間 = 平均失效等待時間 + 平均失效修複時間。
(Reference: https://book.51cto.com/art/200902/111142.htm)
提高可用性的設計技術：
可以能過分布式並行係統來提高係統的準確率，並行係統的好處當一個節點出現問題，另一個節點任然可以工作
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
更多可以參見eBay的scalability 最佳實踐： https://www.infoq.com/cn/articles/ebay-scalability-best-practices
10. 可監控性 （Monitorability ）
這個是我自己想出來的，因為監控真的也是太重要了。沒有監控的係統，就像是一輛沒有儀表盤的汽車，你不知道車速，不知道油量，也不知道車況，車子也許也還能跑，但會跑的很不安心。這就是老大們總喜歡讓下麵的人開發各種各樣的dashboard，這樣有什麼問題就一目了然了，而下麵的人，如果你足夠聰明的話，在沒有人要求的情況下，就能發現那些值得監控的點，並做成dashboard，這樣老大們會對你刮目相看的。
關於具體的監控和日誌，請參看我另一篇博文： https://blog.csdn.net/significantfrank/article/details/25772801
評估中重要概念
敏感點（Sensitivity Point）
敏感點是一個或多個構件（或之間的關係）的特性，例如加密級別越高，安全性越好，那麼加密級別就是安全性這個質量屬性的敏感點。
權衡點（Tradeoff Point）
權衡點是影響多個質量屬性，是多個質量屬性的敏感點。例如加密級別越高，安全性越好，但可能耗費更多的處理時間，影響係統性能。則加密級別就是安全性和性能的權衡點。同樣使用緩存技術，可以提高係統性能，但是在維護緩存（同步，更新）上會增加係統的複雜度，則緩存就是性能和係統複雜度的權衡點。
風險承擔者（Stakeholders)
有架構師，開發人員，維護人員，集成人員，測試人員，性能工程師，安全專家，項目經理，產品經理，用戶，係統管理員，網絡管理員，領域代表，係統設計師。
場景（Scenarios）
一般首先要精確地得出具體的質量目標，並為之作為綁定該體係結構優劣的標準。
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.
主要評估方法
1. SAAM ( Scenarios-based Architecture Analysis Method)
可修改性是SAAM分析的主要質量屬性。
2. ATAM （Architecture Tradeoff Analysis Method)
是在SAAM基礎上發展起來的基於場景的分析方法，主要針對性能、可用性、安全性和可修改性，在係統開發之前，對這些質量屬性進行評估和折中。
整個ATAM評估過程包括九個步驟，按其編號順序分別是：
(1)描述ATAM方法 - Present 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
(2)描述商業動機 - Present Business Drivers
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
(3)描述體係結構 - Present the Architecture
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.
(4)確定體係結構方法 - Identify Achitectural Approches
Identify any predominant architecturalapproaches – for example:
–client-server
–3-tier
–proxy
–publish-subscribe
–redundant hardware
(5)生成質量屬性效用樹 - Generate Utility Tree
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.
(6)分析體係結構方法 - Analyze Architectural Approaches
(7)討論和分級場景 - Brainstorm & Prioritize Scenarios (including new added Scenarios)
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
(8) 分析體係結構方法（是第六步的重複） - Analyze Architectural Approaches (Like an iteration process)
- 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.
(9) 描述評估結果 - Present ATAM Results
- Architectural approaches
- Utility tree
- Scenarios
- Risks and “non-risks”
- Sensitivity points and tradeoffs
Utility tree
Scenarios
Risks and “non-risks”
Sensitivity points and tradeoffs
最後更新：2017-04-02 15:28:25