架构之美读书笔记01

　　1、什么是架构

　　一个好的系统架构应该显示出概念的完整；话句话说，它会伴随一系列的设计规则，这些规则的目标是减少复杂性，这些规则是进行详细设计和系统验证的指导。规则可能会代表一种模式，例如管道和过滤器。

　　在现在的架构师看来，架构应该包括下面的一些内容：

• 　　它包括用户要求的功能。
• 　　它在用户要求的日程上是可完成的。
• 　　它的功能是适当的。
• 　　它是可靠地。
• 　　对用户来说，它是可用的、安全的。
• 　　它是牢固的。
• 　　它不是太贵。
• 　　它符合法律的标准。
• 　　它应该比前辈和竞争对手存活更长的时间。

　　当然了，我们没有见过完美的满足上述特性的复杂系统。架构是一个权衡的结果，改进了这个特性，可能就会消弱另外一个特性。架构师一定要通过发现特定系统的重要关注点，已经满足这些关注点高效运行的条件，来决定那些是需要满足的。

　　2、架构师角色

　　在设计，建设或者是重建一个建筑的时候，我们会指定关键的设计者作为“架构师”，给他们更多的职责。一名架构师会绘制建筑的初始草图，用来显示建筑的外观和内部格局。拿草图和用户进行讨论，直到所有的关注点都被满足，以及草图显示的内容就是用户想要的结果。草图是抽象的。

　　在用户和架构师对这些抽象达成一致之后，架构师回去准备更加详细的图纸，可能包含详细的文档。这些详细的图纸会包括建筑的细节，例如：水管道，建筑原料，窗户的配置，电线的走线等等。

　　架构师很少会简单的把详细图纸交给建筑工人就完事的。对于一些重大的工程，架构师会跟踪项目，定期检查工作，可能会提出一些改进意见，或者是接受一些建筑工人和客户的建议。在架构师管理项目的时候，直到他确定大体上满足计划和详细设计为止，才认为是完成。

　　3、软件架构师角色

　　软件开发项目在进行软件架构的时候也需要同样的角色，就像建筑行业的传统架构师一样的角色。但是，对于软件系统，不可能有一个完全清晰的架构让你去实现。在软件项目中定义一个架构要做什么是非常困难的，要不建筑行业的定义架构要难，主要因为三个因素：

• 　　缺乏惯例，建筑业的历史有上千年，可以参考更多的历史建筑；软件业只有几十年的历史，而且设计都不是公开的。
• 　　无法确定的产品特性，建筑是物理存在的，可以有确切的定义。软件是一中抽象的产品，无法定义确切的摸样。
• 　　系统的复杂性

　　一个大点的软件项目，通常包括多个架构师，很多都是在一个领域有特长，例如：数据库、网络，他们会组成一个团队进行工作。

　　4、如何建立软件架构

　　第一个关注点不是系统的功能。

　　说对了，进行架构的第一个关注点不是系统的功能。

　　假设，我们雇佣你设计一个web应用。你是先问我们一些关于页面布局和导航树，还是问我们下面的这些问题呢？

• 　　主机放在那里？主机环境有什么技术限制吗？
• 　　你希望运行在Windows Server上还是LAMP上呢？
• 　　需要支持多少的并发用户？
• 　　应用需要什么样的安全？数据是否需要保护？应用是内网用还是外网用？
• 　　下面的这些如何区分优先级？例如：用户量重要还是响应时间更重要？

　　依据这些问题的回答，以及一些其他的问题回答，你可以构建一张系统的架构草图。到现在为止我们还没有开始讨论系统的功能。

　　每个系统都有它自己的质量关注点。例如：性能、安全等。

　　功能：产品给用户提供什么样的功能。

　　改变性：软件将来会发生什么样的变化，那些变化是不可能的。

　　性能：性能有什么要求。。

　　容量：有多少并发用户？系统需要存储多少数据？