系统架构评估

软件质量属性

---

1. 性能 (Performance)

性能是指系统的响应能力，性能测试经常要使用基准测试(Benchmark Test).

提高性能的办法：

异步化 - 使用消息系统 和 batch处理

缓存 - 有多重缓存策略，本地缓存，分布式缓存同步，缓存服务器。

系统分割（水平和垂直分割）- 

数据库读写分离 - 

性能测试的办法：基准测试

基准测试（benchmarking）是一种测量和评估软件性能指标的活动。你可以在某个时候通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。这是基准测试最常见的用途。(Reference: http://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:  http://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 最佳实践： http://www.infoq.com/cn/articles/ebay-scalability-best-practices

10. 可监控性 （Monitorability ）

这个是我自己想出来的，因为监控真的也是太重要了。没有监控的系统，就像是一辆没有仪表盘的汽车，你不知道车速，不知道油量，也不知道车况，车子也许也还能跑，但会跑的很不安心。这就是老大们总喜欢让下面的人开发各种各样的dashboard，这样有什么问题就一目了然了，而下面的人，如果你足够聪明的话，在没有人要求的情况下，就能发现那些值得监控的点，并做成dashboard，这样老大们会对你刮目相看的。

关于具体的监控和日志，请参看我另一篇博文： http://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

I dentify 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