1.5 为何演进

对于演进式架构，一个常见的问题是关于其名称的：为什么叫作“演进式”架构，而不是其他名称？随便举几个例子，比如增量式、持续式、敏捷式、响应式或应急式等，但是它们每个都不够准确。我们所定义的演进式架构包含了两个关键特征：增量和引导。

持续式、敏捷式和应急式都捕捉到了随时间变化的概念，这确实是演进式架构的一个关键特征，但它们都没有明确地表示出架构如何变化，或者期望的最终态架构是什么样子的。虽然这些术语都暗示了环境变化，但都没描述出架构应有的样子。而“演进式架构”的定义中“引导”的部分反映了我们想要的架构，即终极目标。

相比“可适应”这个词，我们更倾向于“演进式”，因为我们感兴趣的是那些可以破釜沉舟历经变化的架构，而不是那些随着修修补补卷入了无数的偶发复杂性的架构。“适应”意味着一种只要系统能够运行，而不追求解决方案优雅或长久的方式。为了构建能够实实在在演进的架构，架构师必须支持彻底的变化，而不是一时的权宜之计。“演进”是这样一个过程：建立一个适用的并能在其所处的不断变化的环境中持续运行的系统。系统可能存在个别的适应性，但是架构师应该关心的是一个整体可演进的系统。

架构师可以详述的另外一个对比是演进式架构和应急式设计，以及为什么没有“应急式架构”这个东西。对于敏捷软件开发，一个常见的误解就是所谓的没有架构：“让我们开始写代码吧，架构会随着代码的不断编写而出现。”然而，这取决于问题的难易程度。拿物理建筑来说，如果你要建的是一个狗窝，那么你不需要建筑学知识，直接去五金店买些木材钉在一起就可以了，如果你要建的是一栋50层的写字楼，那么建筑学知识就是必需的！类似地，如果你要建的是一个用户较少的小众目录系统，那么可能用不到大量的前期规划。但是，如果你正在设计一个需要为大量用户提供高性能要求的软件系统，那么前期规划是必要的。敏捷架构的目的不是没有架构，而是没有无用的架构：如果不能为软件开发过程增加价值，那么就没必要搞那些繁文缛节。

软件架构中另一个复杂的因素是架构师必须针对不同类型的基本复杂性进行设计。在评估优劣时，往往不是从容地对比简单和复杂系统，而是要面对千奇百怪的复杂系统。换句话说，每个系统都有一套独特的成功标准。当我们讨论微服务等架构风格时，每一种风格都只是复杂系统的起点，每个系统都会成长为独一无二的样子。

类似地，如果架构师设计的是一个非常简单的系统，那么他也能够承受不关注架构考量的后果。然而，复杂的系统需要有目的的设计，而且需要一个起点。而“应急式”的意思是，你可以从零开始，而架构则为系统的所有部分提供了“脚手架”或结构，必须有一些东西才能开始。

“应急式”的概念也意味着团队可以慢慢地将他们的设计推向理想的架构方案。然而，就像建造房屋一样，没有完美的架构，只有架构师不同的权衡结果。架构师可以用不同的架构风格来解决大多数问题，并获得成功。但是，总有一些是更适合这个问题而不会有太多的阻力和弯路的。

演进式架构的一个关键是在支持长期目标所必需的结构与治理和不必要的形式与摩擦之间取得平衡。