架构之美(一) （摘要）
第一章：架构概述
1.1简介
1． 此处将架构作为一种名词，以为这一组“工件”，包括像蓝图或构件规范这样的文档。
2． 架构，就是所构建系统的计划，确保由此得到期许的特性，同时也是所构建系统的描述。
3． 当代架构师可能会说，待构件的对象或系统应具有以下特性：
l 具备客户要求的功能。
l 能够在要求的工期内安全的构建。
l 性能足够好
l 安全的
l 可靠地
l 可用的，并且使用时不会造成伤害
l 成本是可接受的
l 符合法律规范
l 将超越强人及竞争者。
我们从来没有见过一个复杂的系统能够很好的满足上述特性，架构是一种折中——改进上述的某一方面往往会对其他方面造成影响。架构师需要决定如何做需要好，方法就是发现特定系统中的重要关注点，以及充分满足这些关注点的条件。
4． “架构”意味着不变的深层次结构。
5． 架构师必须做出许多设计决定，要想有用，这些决定必须用文档记录下来，供后续复审，讨论，修改，批准，然后作为后续决定和构建时的约束。对于软件系统，这些决定可能是行为上的和结构上的。
6． 我们使用“架构”这个词来代指一组有标注的图纸，他说明了描述和构建一个系统时所使用的结构。
7． 架构是系统设计的一部分，它突出了某些细节，并通过抽象省略掉了另一部分细节。关注系统组件实现的开发者可能不会关注这些组件如何装配在一起，而是关注少数组件的设计和开发，包括他们必须遵循的架构约束和可以应用的规则。
1.2创建软件架构
1． 软件架构师的首要关注点不是系统的功能
2． 成功架构师的两项关键实践：1.让利益相关人员参与 2.同时关注功能和品质。
3． 典型的利益相关人及他们的关注点：
l 投资人：关注项目是否在给定的资源和进度约束下完成。
l 架构师，开发，测试人员：关注最初的构建及以后的维护与演进
l 项目经理：组织团队，制定计划
l 市场人员：通过品质的特点实现竞争中的差异化
l 用户：包括最终用户，系统管理员，安装，部署人员，配置人员。
l 技术支持人员：关注帮助平台电话的呼入数目及复杂性。
4． 架构师了解相关利益人员的关注点后，下一步应考虑折中。例如：信息加密将增强安全性，但会损失性能。利用配置文件将增强可变性，但会降低可用性。创建系统的架构涉及许多这样艰难的折中。
5． 架构师的第一项任务，就是与相关利益关注人合作，理解这些品质关注点和约束，并为它们排列优先
6． 概念完整性是架构的重要特征：“最好是让系统……反映一组设计思想，而不是让系统包含许多好的思想，而这些思想却相互独立不协调”。这种概念完整性可以让开发者知道了一部分系统后，迅速的了解系统的另一部分。
7． 架构师通常在项目中需要考虑的关注点：
n 功能性（Functionality）
u 产品向他的用户提供哪些功能？
n 可变性(Changeability)
u 软件将来需要哪些改变？哪些改变太可能发生
n 性能（Performance）
u 产品将达到怎样的性能？
n 容量（Capacity）
u 多少用户将并发使用该系统？该系统将为多少用户保存数据?
n 生态系统（Ecosystem）
u 在部署的生态环境中，该系统将与其他系统进行哪些交互？
n 模块化（Modularity）
u 如何将编写软件的任务分解为工作指派（模块），特别的这些模块可以独立的开发，并能够准确而容易的满足彼此的需求
n 可构建性（Buildability）
u 如何将软件构建为一组组件，并能够独立实现和验证这些组件？哪些组件应该复用其他的产品，哪些应该从外部供应商处获得
n 产品化（Producibility）
u 如果产品以几种变体的形式存在，如何开发一个产品线，并利用这些变体的共性？产品线中的产品以怎样的步骤开发？
n 安全性（Security）
u 产品是否需要用户认证，或者必须限制对数据的访问？数据的安全性如何得到保证？如何抵挡攻击？
1.3架构结构
1. 架构师的主要关注点就是对系统进行组织（组织成一些结构），让每种结构有助于解答一个关注点所定义的问题。关键的结构决定将产品划分为组件，并定义了这些组件之间的关系。
2. 信息隐藏结构（整体—部分，包含，依赖）：
a) 组件与关系：主要组件是一些“信息隐藏模块”，每个模块都是针对一组开发人员的工作指派，每个模块包含了一种设计决定。
b) 如果一种设计决定可以改变，同时又不影响其他模块，我们就说这项设计决定是一个模块的秘密。
c) 模块间最基本的关系：整体—部分。如果”信息隐藏模块A”的秘密是”信息隐藏模
块B”的秘密的一部分，则A就是B的一部分（必须能在改变A的秘密的同时，不改变B的其他部分）
d) 每个模块都是一个工作指派，包含一组要写的程序。第二种信息隐藏模块结构是基于程序和模块之间的包含关系。如果模块M的一部分工作指派是要编写程序P，则M包含P。
e) 如果改变B的接口就需要A也发生改变，则我们就说A“依赖”B的接口。
f) 整体部分结构 和 包含结构 是层次状的，依赖不一定。
3. 使用结构：
a) 使用结构的组件是一些可以单独调用的程序（可以相互调用或被硬件调用，或被其他命名空间的程序调用）
b) 如果程序B必须存在并满足其规格说明，程序A才能满足其规格说明，则称为A使用了B。（也就是B必须存在 且操作正常，A才能操作正常）
c) 具有层次使用结构的系统可以同时构造一层或几层。
4. 进程结构：
a) 信息隐藏结构和使用结构是静态结构，存在于设计时和编码时，进程结构是运行时结构。
b) 参与进程结构的组件是进程。进程是运行时的事件序列，由程序控制。
c) 每个程序都作为一个或多个进程的一部分执行，一个进程中的事件序列的执行独立于另一进程中的事件序列，除非这两个进程彼此同步（例如一个进程等待来自另一个进程的信号或消息）
5. 访问结构
a) 系统中的数据可能划分成为具有属性的段，如果程序对段中的任何数据拥有访问权，就对该段中的所有数据拥有了访问权。
6. 结构小结：
| 结构 |
组件 |
关系 |
关注点 |
| 信息隐藏结构 |
信息隐藏模块 |
整体—部分 包含 |
可变性 模块化 可构建性 |
| 使用结构 |
程序 |
使用 |
产品化 生态系统 |
| 进程结构 |
进程（任务，线程） |
提供工作 取得资源 共享资源 包含在模块中 …… |
性能 可变性 容量 |
| 数据访问结构 |
程序和数据访问 |
有权访问 |
安全性，生态系统 |
1.4好的架构
1． 对于一组给定的功能需求和品质需求，没有唯一的正确架构。应对架构进行评估，确定其是否满足需求。
2． 架构评估常见的两种方式：
i. 第一种是确定架构的属性，通常通过建模或模拟系统的一个或多个方面。如：通过性能建模来评估吞吐量和伸缩性。通过失效树模型评估可靠性和可访问性。
ii. 第二种方式是通过对架构师提出质询来评估该架构（使用最广泛）。
1. 架构折中分析方法（ATAM，是质询方法的变体），他寻找架构不能满足品质关注点的风险。ATAM使用场景分析，每种场景模拟了不同利益相关人员对系统的品质关注点，架构师分别解释该架构如何支持每一种场景。
2. 主动复审是另一种质询方法，他要求架构师向复审者提供架构师认为重要且需要回答的问题，然后复审者利用已有的架构文档和描述来回答这些问题。
1.5 美丽的架构
1. 判断架构是否足够好：是否有可能指导开发者和测试者构建一个系统，并满足利益相关人的功能和质量关注点。
2. 超越足够好的架构：
i. 实用性：每天被许多人使用
ii. 可构建性：具有定义良好的使用结构的架构，支持增量式构建，具有定义良好的模块接口，本来就很好测试的架构。
iii. 持久性：经历了时间考验，预期到变更的需要，允许期望的修改能够容易而有效的进行。避免“衰老地平线”。
iv. 架构特征，使得使用，构建，测试这些架构的开发人员和测试人员 及由它而形成的系统的使用者感到愉悦。