软件架构领域正在爆发一场新的革命。Gartner 权威发布 2023 年十大科技趋势之一 “可持续 IT 架构”，可持续架构得到越来越多从业人员认同。创建和维护可持续的软件架构对于架构师和工程师而言也是一项巨大的挑战。

持续架构的引入

如今，定义前期架构的价值降低了很多，但系统仍必须满足其具有挑战性的质量属性；软件涉众仍然有着复杂、冲突且重叠的需求；仍有许多设计选项需要被理解和权衡；为了使系统能够满足涉众的需求，也许我们比以往任何时候更需要解决交叉问题。这些挑战与长久以来困扰软件架构师的挑战是一样的。然而，在当今的环境里使用软件架构来应对这些挑战的方式必须要改变了。敏捷性和 DevOps 实践正在从根本上改变 IT 专家（包括软件架构师）的工作方式。软件架构的实践方式可能会发生变化，但我们相信它比以往任何时候都更加重要。

虽然软件架构仍然是产品交付成功的重要因素，但它需要发展以应对这样的环境，在这种环境中，系统通常被开发为一组并行且很大程度上独立的组件（微服务）。对于这种软件开发风格，如果像过去一样采用单一架构师或由一小组技术主管做出所有关键决策，最终只会让架构师负担过重并导致开发停滞。这种软件交付方法需要由更多的人以较小的增量来执行架构工作，并且比以往更注重早期的价值交付。

让我们用物理上的建筑来类比并理解软件架构的重要性。在这个假设的场景中，我们受雇建造位于加利福尼亚州科罗纳多的标志性建筑Hotel Del Coromado 的复制品。这家酒店出现在1959 年著名的电影《热情如火》中，它实际上代表了佛罗里达州南部的塞米诺尔丽兹酒店。这部电影的一位富有的粉丝想要在佛罗里达州拥有一座该酒店的复制品。

建造原本的酒店并不是一个简单的过程。工程于1887年3月开始，原始建筑计划在施工期间不断修改和添加。酒店于1888年2月开业且尚未完全完工，在其132 年的历史中经 过多次翻修和升级。那么我们将如何处理这个项目呢？

敏捷开发人员可能希望立即开始建造。相比之下，企业架构师会说，鉴于酒店的复杂历史，立即着手建造会造成大量浪费。相反，他希望做大量的前期规划，并根据当前的建筑技术和实践制定一个五年的建设计划。

然而这两种方法可能都不是理想的方式。而持续架构的目标则是弥合两种方法之间的差距以获得更好的整体结果。

持续架构的定义

满足以下六个简单准则的架构就可以被称为持续架构：

准则 1 ：用产品思维，而非项目思维来设计架构。

从产品的角度进行构建比单纯设计点的解决方案更有效率，更容易让团队专注于客户的需求。

准则 2 ：聚焦质量属性，而不仅仅是功能性需求。

质量属性需求驱动着架构。

准则 3 ：在绝对必要的时候再做设计决策。

架构设计取决于事实，而不是猜测。设计和实施可能永远都用不到的功能是无意义的，是对时间和资源的浪费。

准则 4 ：利用 “微小的力量”，面向变化来设计架构。

大的、单体的、紧耦合的组件很难改变。相反，应该使用小且松耦合的软件元素。

准则 5 ：为构建、测试、部署和运营来设计架构。

大多数架构方法只关注软件构建活动，但我们认为架构师也应该关注测试、部署和运营，以支持持续交付。

准则 6 ：在完成系统设计后，开始为团队做组织建模。

团队的组建方式驱动着系统的架构和设计。

这六项准则、 基本活动和工具可以帮助我们进行架构活动并定义软件架构的关键组件，例如：

• 系统上下文；

• 影响架构的关键功能性需求；

• 驱动架构的质量属性；

• 架构和设计决策；

• 架构蓝图。

有趣的是，软件架构的组件并不是孤立存在的，而是相互关联的(见图1)。创建软件架构需要在需求、决策、蓝图甚至最终架构工件(可执行代码本身)之间做出一系列权衡。

图1 软件架构的关键组件

持续架构与其他架构方法的区别

那么持续架构与其他架构方法有什么不同呢？

首先，我们不认为它是一种方法论，而是一组准则，工具、技术和思想可以被视为架构师有效处理持续交付项目的工具集。使用这些准则、工具、技术和思想，没有预设的顺序或流程可遵循，完全取决于每个架构师。我们发现它们对我们运作过的项目和产品很有效，而且它们本质上是动态的且具有高适应性。我们希望读者会受到启发，适应持续架构工具集的内容，并用新的想法来扩展工具集，为快速交付健壮且有效的软件项目提供架构支持。

我们坚信利用持续架构方法可以帮助架构师处理和消除瓶颈。持续架构的目标是通过在整个过程中系统地应用架构视角和准则来加速软件开发和交付过程。因此，我们能够创建一个可持续的系统，在很长一段时间内为组织创造价值。

与大多数主要关注软件交付生命周期( Software Delivery Life Cycle ，SDLC) 的软件设计和构建方面的传统软件架构方法不同，持续架构为整个过程带来了架构视角，就如准则5所说，为构建、测试、部署和运营来设计架构。它的存在尽可能地避免了大架构超前综合征，架构团队不需要再创建复杂的工件来描述技术功能，软件开发人员也不再会陷入等待而无事可做。它帮助架构师创建弹性、高适应性且灵活的架构，这些架构可以快速实现为可执行代码，测试并部署到生产环境中，以便该系统的用户能够提供反馈，而这是对架构的最终验证。

此外，持续架构方法侧重于交付软件而不是文档。与传统的架构方法不同，我们将工件视为一种手段，而不是目的。

持续架构提供的准则和工具

我们并不是要定义一个具体的架构方法论或开发流程。我们的主要目标是分享一组在实际工作中的核心准则和工具。事实上，应用持续架构是关于如何理解准则和理念，并把它们应用到自己的环境中去。这么做的时候，读者可以自主决定使用哪些工具以及如何解读必要的活动。

为了应对当前的挑战，即在敏捷与持续交付的实用主义中建立坚固的架构基础，我们已定义了这个基于价值的方法。然而，这并不意味着使用持续交付是使用持续架构的先决条件。类似地，我们意识到一些公司可能还没有准备好在各方面都采用敏捷方法论。甚至，即使一个公司已经完全投入到敏捷工作中，某些情况下(比如采用第三方软件包时)，其他方法也可能更为合适（见图 2）。

图2 应用持续架构

这是不是意味着持续架构在这种情况下不可用呢？绝对不是。持续架构的好处之一就是，其工具可以很好地与其他软件开发方法融合，不是仅限于敏捷开发。

持续架构也在两个维度中运作：规模和软件交付速度（见图 3）。软件交付速度的维度决定着如何在这个加速交付循环的世界中采用架构实践。尽管规模维度注重于运营层面，我们相信持续架构准则可以被稳定地应用在所有的产品规模中，只是关注的层次和需要使用的工具会有所不同。

图3 持续架构的维度