本文转载自微信公众号《大数据DT》，作者DavidD.Clark。转载本文请联系大数据DT公众号。01什么是建筑？建筑是一个过程、一个结果和一门学科。作为一个过程，它涉及将组件与设计元素组合以形成一个有目的的实体。因此，它描述了一组由其形式定义的实体。对于我们所熟知的“哥特式大教堂”的建筑形式，其特点是具有一系列公认的设计元素和方法。目的可能是建造礼拜场所，但“哥特式大教堂”实际上意味着更多。最后，建筑学作为一门学科是建筑师受训要做的事情。计算机科学领域借用了设计物理对象（例如建筑物和城市）的学科的术语，并包括广泛认可的培训和认证过程。建筑学的所有三个方面都适用于“真正的建筑学”和计算机科学。1.我对过程的定义有两个重要方面：将组件组合在一起并为一个目的应用它们。将组件放在一起：这就是计算机科学家在考虑模块、接口、依赖性、分层、抽象和组件重用时所做的事情。这些是受过训练的计算机科学家在考虑设计挑战时要考虑的设计模式。为一个目的而应用：设计过程必须由工件的预期目的决定，例如，医院而不是监狱，低功耗处理器而不是超级计算机，制动踏板挂在汽车网络中的制动器上而不是互联网。作为体系结构的一部分，设计人员必须解决系统不能做什么（或不能做什么）与它将做什么的问题。在计算机科学中，系统设计中存在一种众所周知的危险，称为第二系统综合症，即首先构建一个可能会做好某些事情的系统，然后再想出一个试图做好所有事情的系统。一种趋势是在事情做得很好的地方选择替代品。2.结果在建筑设计实践中，设计通常会产生一个结果。也有一些例外，例如排屋，其中一种设计被建造了很多次，但大多数建筑物只有一种。在描述结果时，术语架构通常表示一类设计，以其最显着的特征（例如飞扶壁）为代表。该术语适用于这个抽象类，尽管架构师必须在架构团队接手之前将建筑描述到非常精细的水平。当计算机科学家重复使用架构这个术语时，他们稍微重新定义了它。关于互联网，有许多基于相同设计的不同网络：我们称为“互联网”的公共全球网络，属于企业、军队等的专用网络，以及金融网络等专用网络。在这种情况下，术语体系结构仅描述了构建内容的一部分，并且给定示例的大部分设计过程发生在后期阶段，可能由不同的组描述。3.作为一门学科，“真正的”建筑师——设计建筑的人——去学校学习这门手艺。作为外行人，了解他们的成长过程对我们也很有启发。建筑学（相对于结构工程）不是一门基于基础科学和工程原理的设计学科。建筑师通常不关心结构工程之类的问题，而将其留给其他人。当然，技术方面的考虑可能需要尽早进入设计过程，因为建筑师要处理能源效率或抗震等问题，但建筑师主要在设计过程中接受培训。他们不学习工程，而是学习建筑。他们通过案例研究学习，查看大量建筑物以了解它们适合（或不适合）的程度、它们是否满足用户需求、它们在视觉上是否吸引人、如何处理设计权衡等等。在计算机科学中，我们倾向于期望设计基于强大的工程基础、约束理论、首选设计选项等，但（至少在过去）系统架构的大部分业务更像是架构师的工作（例如，从以前的设计中学习，询问哪些有效，哪些无效，询问设计是否符合目标）。我们在理论和实践上培养计算机科学家，但通常不赞成研究以前的设计，我们认为这些设计“不科学”或“不基于第一性原理”。我个人对尝试使架构更加严谨感到兴奋，但不应使用诸如“凭直觉设计”之类的短语来反对我们今天所做的事情。我们的学科是设计学科，就像建筑学一样，我们应该努力超越它，而不是否定它。那么，如果互联网的架构不是一个完整的规范，而只是那个规范的一部分，那么架构中包括什么？我们可以谈谈不包括在内的内容。看看所有基于互联网技术的不同网络的例子，或者全球互联网的不同领域，看看它们有什么不同。我们看到了性能、弹性、移动容忍度、对安全性的关注等方面的差异。此级别的设计决策建立在核心架构之上，但并非由核心架构指定。那么，我们应该在这个核心架构中看到什么？02网络架构要素我确定了几个可以确定特定问题是否上升到架构级别的标准：为了系统正常工作，是否需要就该问题达成一致？一致性;就问题达成一致是否方便；问题是否定义了系统的基本模块化或功能依赖性；或者问题随着时间的推移是否稳定是否重要。1.我们必须就系统正常工作达成一致的问题。例如，互联网架构是基于数据包的使用，并假设数据包头始终具有相同的格式（不同的设计可能允许在不同的地区使用不同的格式，在这种情况下，架构可能会选择描述为所需的转换提供了哪些架构支持）。另一个例子是当我们最初设计互联网时，我们认为设计依赖于一个单一的全球地址空间。现在很清楚，这种假设是不必要的，也不需要就地址的统一含义达成全球协议。网络地址转换设备或“NAT盒”允许Internet边缘区域使用私有地址空间，并仅在数据包传输到公共Internet时将这些地址转换为全球可路由地址。有趣的是，一旦Internet架构师意识到他们可以使用具有不同地址空间的区域来构建网络，就不会急于扩展该体系结构以提供任何关于如何互连不相交的地址空间的支持或指导。2.共识问题我们不要求应用程序使用域名系统(DNS)，但由于几乎所有应用程序设计者都使用它，所以它已被强制成为Internet的一部分，即使DNS不是最初设计的。同样，虽然通信应用程序不一定使用TCP，但许多应用程序都依赖它，以至于它也是Internet的强制性部分。3.系统的基本模块化计算机科学用模块这个词来描述系统的子组件：一个模块有一个特定的接口，通过它可以连接到系统的其他部分，而模块下面的内部结构接口是隐藏的，不能从模块外部访问。模块的设计者通常保持接口规范不变，因为其他模块可能依赖于该接口，但可以自由更改模块的内部结构，因为这些是模块私有的。互联网协议（IP）规范定义了三个模块接口。它定义了两层接口：服务接口（在其上构建更高级别的服务）和IP层下的技术接口。它还定义（隐式地和部分地）AS接口：Internet中不同AS之间的接口。服务接口是Internet的尽力而为数据包级传递模型：如果端节点发送数据包，数据包中包含有效的目标IP地址，则在给定当前网络能力的情况下，Internet的路由器将转发到由定义的目标接口IP地址。服务接口隐藏了有关如何使用特定技术在Internet中提供通信路径的所有细节。因此，这个服务接口定义了网络和端节点之间的抽象接口。此接口的技术细节取决于用于连接到端节点的特定网络技术并因这些技术而异，因此这些细节不是体系结构规范的一部分。4.功能依赖架构的一个方面是明确设计的功能依赖。我将使用Internet来说明这意味着什么。互联网的基本操作很简单。路由器在后台计算路由表，因此它们知道到Internet各个部分的路由。收到数据包后，它们会寻找最佳路由并在该路由上发送数据包。虽然在Internet中发生了很多事情，但在内核上，这就是它所做的一切。Internet的正常运行必然取决于路由器的正常运行。但是互联网还需要什么来提供服务呢？事实上，互联网的早期架构师试图限制使用的服务或运行的组件数量，以确保数据包流量。早期的设计目标如下：“如果两台计算机连接到网络，并且每台都知道对方的地址，那么它们应该能够通信。不需要其他任何东西”。这种设计偏好可以表示为“最少功能依赖性”的目标。一些互联网设计方案具有更多的功能依赖性——它们依赖于更多的服务来启动和运行以实现基本通信的成功。当出现问题时，他们正在（可能）以更少的弹性来换取功能。5.系统中被视为持久的方面在像Internet这样的系统中，我们知道很多事情都会发生变化。事实上，改变、升级和替换系统各个方面的能力是成功长寿的关键。但就某些方面似乎是持久性的而言，将它们指定为设计的一部分提供了稳定点，系统的其余部分可以围绕这些稳定点向前发展。03总结：关于架构的思考我已经对我提到的架构这个词有了一个基本的概念。在我看来，一个关键原则是架构简单性。在计算机科学的背景下，系统架构不应试图描述系统的每个方面。这种建筑的概念似乎与建筑物的概念不同。当建筑设计师将蓝图交给建筑商时，规格已经完整到细节——不仅是形状和结构，还有电源插座的位置。但我认为大多数决策都不是架构性的。就像我之前说的，建筑物的架构和像互联网这样的人工制品的架构之间的区别之一是，有许多网络使用相同的互联网技术构建，而不仅仅是一个。如果Internet技术可以在不同的环境中使用，将会带来明显的好处：商业产品会更便宜，可能会更成熟，几乎所有计算机系统都会有相关的软件，等等。但是，这些网络可能对安全性没有相同的要求，弹性和其他方面，因此架构的力量不在于定义应如何构建网络（如架构计划描述应如何构建建筑物），而是在于允许满足这些要求，也许满足这些需求不同环境下的不同方式。套用爱因斯坦的话，我认为建筑应该尽可能小，但不能太小。有人可能会争辩说，正如我所描述的，互联网架构最基本的方面是它对简单性的偏爱。考虑到这一点，考虑到架构解决的需求，我们认为网络系统架构的范围应该只包括落在我在这里列出的框架内的那些方面。关于作者：DavidD.Clark是麻省理工学院(MIT)计算机科学与人工智能实验室的高级研究科学家。80年代，任互联网架构组主席，长期主持互联网的设计和未来互联网技术的研究。本文节选自《互联网的设计和演化》，经发布者授权发布。
