下载掌阅APP，畅读海量书库
立即打开
演进的机制和架构师设计软件时所做的决策都源自下述定义：
演进式软件架构支持跨多个维度的引导式增量变更。
该定义由三个部分组成，我们接下来会深入讨论。
一旦团队选定了重要的架构特征，他们就希望引导架构的变更方式，以保护这些特征。为此，我们借用演进计算中的一个概念：适应度函数。适应度函数是一种目标函数，用于计算潜在的解决方案与既定目标的偏差。在演进计算中，适应度函数用来判定一个算法是否随着时间的推移而改进。换句话说，随着每个算法变体的产生，适应度函数基于算法设计者定义的“适应度”决定每种变体的“适应度”。
在演进式架构中有类似的目的：随着架构的演进，我们需要一种机制来评估变更对重要架构特征的影响，并防止这些架构特征随时间腐化。适应度函数的隐喻涵盖了多种机制，用来保证架构朝着我们期望的方向变化，包括度量、测试和其他验证工具。每当架构师明确一种想要在演进中保护的架构特征时，他们可以定义多个适应度函数来提供防护。
以往，架构涉及的一部分工作常常被视为治理活动，直到最近架构师才接受了通过架构实现变更的思想。架构适应度函数允许在组织需求和业务功能的上下文中制定决策，同时为其明确性和可测试性奠定基础。演进式架构不是一种无组织、不负责任的软件开发方式。恰恰相反，它是一种能够在业务的高速变化和稳定的系统及架构特征之间寻求平衡的方式。适应度函数驱动架构设计决策，使得架构能够适应业务和技术环境的变化。
我们将在第2章详述如何使用适应度函数来指导演进。
增量变更描述了软件架构的两个方面：团队如何增量地构建软件，以及如何部署它。
在开发过程中，允许小步、增量变更的架构更容易演进，因为对于开发人员来说，这意味着变化范围更小。对于部署而言，增量变更则涉及模块化水平、业务功能之间的耦合度，以及它们在架构中的映射。有如下用例。
假设有一个大型的小工具商家PenultimateWidgets（意为“倒数第二小工具”），其产品黄页背后采用了微服务架构和现代工程实践。其中一个功能是用户可以给不同的小工具评星打分。而PenultimateWidgets的其他服务也需要评分功能（例如客服代表、物流提供商评价等），所以它们都在复用这个星级评分服务。某天，该服务团队在现有功能的基础之上发布了一个新版本，新版本允许给出半星评分——一个微小而重要的升级。其他需要评分的服务不必强制升级，可以根据需要酌情跟进。PenultimateWidgets的DevOps实践包含了架构级监控，不仅可以监控各个服务，还可以追踪服务间路由。当运维团队观测到一段时间内没有任何人访问某个特定的服务时，他们会自动将该服务从系统中移除。
这就是一个在架构级别进行增量变更的例子：如有需要，新老服务可以并存。团队可以选择适当的时机（或按需）来进行迁移，老版本则会自动被当作垃圾回收。
增量变更的成功离不开一系列持续交付实践的配合。并不是所有情况下都需要这些实践，但它们通常相辅相成。我们将在第3章讨论如何实现增量变更。
没有单独的系统。世界是一个整体。系统的边界取决于讨论的主题。
——Donella H. Meadows
古希腊物理学家逐渐学会了基于不动点来分析宇宙，最终形成了经典力学（ https://oreil.ly/jHoLH ）。然而在20世纪初，更精细的仪器和更复杂的现象使得该定义向相对论逐渐转化。科学家意识到他们曾以为彼此孤立的现象实际上是互相作用的。自20世纪90年代以来，受此启发的架构师更多地将架构视为多维度的。而持续交付将运维也囊括了进来。然而，软件架构师往往只关注技术架构（即软件部分如何组织在一起），但那只是软件项目的一个维度。如果架构师想要构建可演进的架构，那么必须考虑系统中会被变更影响的所有的内连部分。如同我们从物理学家那里学到的，万物都是相关联的，架构师必须知道软件项目是多维的。
为了构建可以演进的软件系统，架构师不能只考虑技术架构。例如，如果项目包含关系型数据库，那么数据库实体之间的结构和关系也会随时间演变。类似地，架构师不希望系统演进的过程中暴露安全漏洞。这些都是不同系统维度的例子——架构的各部分彼此之间通常相对独立。部分维度常常被我们称为架构关注点（即前文提到的“特性”），但维度的含义要更广泛些，包含了传统意义上的技术架构以外的许多东西。每个项目都有一些维度是架构师在演进架构时必须考虑的。下面是一些影响现代软件架构可演进性的常见维度：
技术
架构中的实现部分：框架、依赖库和实现语言。
数据
数据库模式、表结构、优化计划等。通常由数据库管理员处理这部分架构。
安全
定义安全策略、指导方针，并确定发现缺陷的工具。
运维和系统
关注架构如何映射到现有的物理或虚拟基础设施：服务器、机器集群、交换机、云资源等。
上述的每个视角都可以构成一个架构维度——一种旨在支持特定视角的划分方式。架构维度的概念涵盖了传统的架构特征，以及任何参与软件构建的角色。它们中的每一个都构成了一种架构视角，而我们希望即使发生问题演变和环境变更，这些棱角仍得以留存。
当架构师以架构维度的方式思考问题，它就提供了一种机制，通过评估每个重要的架构维度响应变更的方式，架构师可以分析不同架构的可演进性。随着系统与相互冲突的关注点（可伸缩性、安全、分布式、事务等）交织得愈发紧密，架构师必须跟踪更多的维度。只有结合所有重要维度来思考系统演进，才能构建出可演进的系统。
项目的整个架构范围不仅包含软件需求，还包含其他维度。我们可以使用适应度函数来保护这些特性不被架构和生态系统演进、时间推移所改变，如图1-2所示。
图1-2：架构包含需求及其他维度，它们都可以用适应度函数保护
在图1-2中，架构师确定将可审计性、数据、安全、性能、合法性以及可伸缩性作为关键架构特征。随着业务需求的不断变化，每个架构特征都可以通过适应度函数来保护其完整性。
在关注架构整体的重要性的同时，我们也意识到，架构演进大多需要关注技术架构模式，以及诸如耦合和内聚这样的主题。我们将在第5章讨论技术架构上的耦合如何影响演进，并在第6章谈及数据耦合的影响。
耦合不仅适用于软件项目中的结构元素。很多软件公司近来惊奇地发现团队结构对架构也有影响。我们会讨论软件中的各种耦合，也会在第9章讨论团队结构带来的影响。
演进式架构有助于回答致力于现代软件开发生态系统的架构师的两个常见问题：长期规划如何应对层出不穷的变化？架构构建完成后，如何防止其随时间推移而退化？让我们进一步探索这两个问题。