架构之美第五章-架构概述

           建筑师、音乐家、作家、计算机设计师、网络设计师和软件开发者都在使用“架构”这个术语，其他人也用（你有没有听说过“食物架构”？），然而不同的用法其结果也不同。建筑与交响乐完全不同，但都有架构。而且，所有的架构师都在谈论他们工作中的美，以及因此而导致的结果。建筑师可能会说，一座建筑应该提供适合工作或生活的环境，而且它应该看起来很美。音乐家可能会说，音乐应该能演奏，包含能够辨明的主题，而且它应该听起来很美。软件架构师可能会说，系统应该对用户友好、响应及时、可维护、没有重大错误、易于安装、可靠，应该通过标准的方式与其他系统通信，而且也应该是美的。

         这本书为你提供了一些美丽架构的详细例子，它们来自于各类计算机系统。相对来说，计算机是比较年轻的一个学科。因为年轻，所以不像建筑、音乐或写作等领域那样，有那么多的例子；也因为年轻，则需要更多的例子。我们希望这本书能满足这种需要。

        在你开始研究这些例子之前，我们希望你考虑以下两个问题：

1) 什么是架构？

2) 美丽的架构都有哪些特性？

你会在这一章中看到架构的不同定义，每个学科都有自己的定义，所以我们将首先探讨不同学科中的架构有何共同点，以及人们试图用架构解决哪些问题。具体来说，架构有助于确保系统能够满足其利益相关人的关注点，在构想、计划、构建和维护系统时，架构有助于处理复杂性。

然后我们将介绍架构的定义，展示如何将这个定义应用于软件架构，因为软件是本书后面大部分例子关注的核心。这个定义的关键在于，架构由一组结构组成，这些结构的设计目的是让架构师、构建者，以及其他利益相关人看到他们的关注点是如何得到满足的。在本章末尾，我们将讨论美丽架构的特性，并引用一些例子。美的核心在于概念完整性—即一组抽象和规则，在整个系统中尽可能简单地应用它们。

        在讨论中，我们将“架构”作为一个名词，它意味着一组工件，包括像蓝图和构建规范这样的文档。这些工件描述了要构建的对象，在这种描述中，该对象被视为一组结构。某些人也把“架构”作为一个动词，用来描述创建这些工件的过程，包括由此而导致的
工作。然而，正如Jim Waldo和其他人曾指出的，没有什么过程可以保证你学了以后就能创造出好的系统架构，更不必说美的架构了（Waldo 2006），所以我们将更关注工件，而非过程。
      架构：“建造的艺术或科学；特别是设计和建造人类使用的建筑时的艺术或实践，同时考虑到美学因素和实用因素。”—《The Shorter Oxford English Dictionary》（小型牛津英语字典，第5版）

        在所有学科中，架构都提供了一种方式来解决共同的问题：确保建筑、桥梁、乐曲、书籍、计算机、网络或系统在完成后具有某些属性或行为。换言之，架构既是所构建系统的计划，确保由此得到期望的特性，同时也是所构建系统的描述。维基百科上说：“根据这方面已知最早的著作，即Vitruvius的‘On Architecture’，好的建筑应该美观（Venustas）、坚固（Firmitas）、实用（Utilitas）；架构可以说是这三方面的一种平衡和配合，没有哪一个方面比其他方面更重要。”
        我们谈到交响乐的“架构（architecture）”，反过来，又将架构（architecture）称为“凝固的音乐”。—Deryck Cooke, 《The Language of Music》（音乐的语言）
        好的系统架构展示了架构完整性。也就是说，它来自于一组设计规则，这组规则有助于减少复杂性，并可以用于指导详细设计和系统验证。设计规则可能包含特定的抽象，这些抽象总是以同样的方式使用，诸如虚拟设备等。这些规则可能表现为一种模式，如管道和过滤器。在最理想的情况下，存在一些可以用于验证的规则，如“在设备失效时，所有某一类的虚拟设备都可以用任何其他同类的虚拟设备代替”，或“所有竞争同一资源的进程必须具有相同的调度优先级”。
当代的架构师可能会说，待构建的对象或系统必须具有以下特征：
• 具备客户要求的功能。
• 能够在要求的工期内安全地构建。

• 性能足够好。

• 可靠的。
• 可用的，并且使用时不会造成伤害。
• 安全的。
• 成本是可以接受的。
• 符合法规标准。
• 将超越前人及其竞争者。
        我们将计算机系统的架构定义为一组最小的特征集，它们决定了哪些程序将运行，以及这些程序将得到什么结果。—Gerrit Blaauw 和Frederick Brooks, 《Computer Architecture》（计算机体系结构）
        我们从来没有看到过一个复杂系统能够很好地满足上述特征。架构是一种折中—决定改进其中一个特征常常会对其他特征产生负面影响。架构师必须确定怎样做是足够好的，方法就是发现特定系统的重要关注点，以及充分满足这些关注点的条件。架构观点中的常见思想是结构，每种结构都由各种类型的组件及其关系构成：它们如何组合、相互调用、通信、同步，以及进行其他交互。组件可以是建筑中的支架横梁或内部腔室、交响乐中的旋律、故事中的章节或人物、计算机中的CPU和内存、通信栈中的层或连接到一个网络上的处理器、协作的顺序过程、对象、编译时的宏、构建时的脚本。每个学科都有自己的一套组件和组件间的相互系。

         从更大的范围来说，术语“架构”总是意味着“不变的深层次结构”。—Stewart Brand, 《How Buildings Learn》
         面对不断增长的系统复杂性，以及它们内部和相互之间的交互，由一组结构形成的架构提供了对付复杂性的主要手段，目的是确保得到的系统具备所要求的特征。结构为我们提供途径，将系统化解为一些交互的组件。每种结构都是为了帮助架构师理解如何来满足特定的关注点，如可变性或性能。展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关                
网络架构：构成一个网络的通信设备、协议和传输链路，以及它们的组织方式。