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