《架构之美》读书笔记（一）
1、引言
建筑师、音乐家、作家、计算机设计者、网络设计者、软件开发者都在使用架构一词，在其他地方也可能会听到这个词，但是他们产生的结果是不同的。建筑和交响乐有很大的区别，但是它们都有架构。进一步说，所有的架构师都在谈论他们工作的美妙，以及结果的美妙。一名建筑架构师可能会说一个建筑应该提供舒适的工作、生活环境，看起来应该是美丽的；音乐家可能会说音乐应该可以可以演奏的，有一个可以识别的主题，听起来应该是美丽的；软件架构师可能会说一个系统对于用户来说，应该是有好的、响应快速的，可维护的，没有致命性的错误，容易安装，可靠地，和其他系统之间的通信应该是标准方式，而且它也应该是美丽的。
2、什么是架构
一个好的系统架构应该显示出概念的完整；话句话说，它会伴随一系列的设计规则，这些规则的目标是减少复杂性，这些规则是进行详细设计和系统验证的指导。规则可能会代表一种模式，例如管道和过滤器。
在现在的架构师看来，架构应该包括下面的一些内容：
- 它包括用户要求的功能。
- 它在用户要求的日程上是可完成的。
- 它的功能是适当的。
- 它是可靠地。
- 对用户来说，它是可用的、安全的。
- 它是牢固的。
- 它不是太贵。
- 它符合法律的标准。
- 它应该比前辈和竞争对手存活更长的时间。
当然了，我们没有见过完美的满足上述特性的复杂系统。架构是一个权衡的结果，改进了这个特性，可能就会消弱另外一个特性。架构师一定要通过发现特定系统的重要关注点，已经满足这些关注点高效运行的条件，来决定那些是需要满足的。
3、架构师角色
在设计，建设或者是重建一个建筑的时候，我们会指定关键的设计者作为“架构师”，给他们更多的职责。一名架构师会绘制建筑的初始草图，用来显示建筑的外观和内部格局。拿草图和用户进行讨论，直到所有的关注点都被满足，以及草图显示的内容就是用户想要的结果。草图是抽象的。
在用户和架构师对这些抽象达成一致之后，架构师回去准备更加详细的图纸，可能包含详细的文档。这些详细的图纸会包括建筑的细节，例如：水管道，建筑原料，窗户的配置，电线的走线等等。
架构师很少会简单的把详细图纸交给建筑工人就完事的。对于一些重大的工程，架构师会跟踪项目，定期检查工作，可能会提出一些改进意见，或者是接受一些建筑工人和客户的建议。在架构师管理项目的时候，直到他确定大体上满足计划和详细设计为止，才认为是完成。
4、软件架构师角色
软件开发项目在进行软件架构的时候也需要同样的角色，就像建筑行业的传统架构师一样的角色。但是，对于软件系统，不可能有一个完全清晰的架构让你去实现。在软件项目中定义一个架构要做什么是非常困难的，要不建筑行业的定义架构要难，主要因为三个因素：
- 缺乏惯例，建筑业的历史有上千年，可以参考更多的历史建筑；软件业只有几十年的历史，而且设计都不是公开的。
- 无法确定的产品特性，建筑是物理存在的，可以有确切的定义。软件是一中抽象的产品，无法定义确切的摸样。
- 系统的复杂性
一个大点的软件项目，通常包括多个架构师，很多都是在一个领域有特长，例如：数据库、网络，他们会组成一个团队进行工作。
5、如何建立软件架构
第一个关注点不是系统的功能。
说对了，进行架构的第一个关注点不是系统的功能。
假设，我们雇佣你设计一个web应用。你是先问我们一些关于页面布局和导航树，还是问我们下面的这些问题呢？
- 主机放在那里？主机环境有什么技术限制吗？
- 你希望运行在Windows Server上还是LAMP上呢？
- 需要支持多少的并发用户？
- 应用需要什么样的安全？数据是否需要保护？应用是内网用还是外网用？
- 下面的这些如何区分优先级？例如：用户量重要还是响应时间更重要？
依据这些问题的回答，以及一些其他的问题回答，你可以构建一张系统的架构草图。到现在为止我们还没有开始讨论系统的功能。
每个系统都有它自己的质量关注点。例如：性能、安全等。
功能：产品给用户提供什么样的功能。
改变性：软件将来会发生什么样的变化，那些变化是不可能的。
性能：性能有什么要求。。
容量：有多少并发用户？系统需要存储多少数据？