软件架构领域正在爆发一场新的革命。Gartner权威发布2023年十大技术趋势之一“可持续IT架构”，可持续架构得到越来越多从业者的认可。创建和维护可持续的软件架构对于架构师和工程师来说也是一个巨大的挑战。1持续架构介绍今天，定义一个前期架构的价值要小得多，但系统仍然必须满足其具有挑战性的质量属性；软件利益相关者仍然有复杂、冲突和重叠的需求；仍有许多设计选项需要理解和权衡；也许我们比以往任何时候都更需要解决交叉问题，以便系统满足利益相关者的需求。这些挑战与长期困扰软件架构师的挑战相同。但是，必须改变在当今环境中使用软件架构来应对这些挑战的方式。敏捷性和DevOps实践正在从根本上改变IT专业人员（包括软件架构师）的工作方式。软件架构的实践可能会改变，但我们相信它比以往任何时候都更重要。虽然软件架构仍然是产品交付成功的重要因素，但它需要不断发展以应对系统通常作为一组并行且基本独立的组件（微服务）开发的环境。在这种软件开发风格下，让一个架构师或一小群技术主管做出所有关键决策，就像过去一样，最终只会让架构师负担过重并导致开发停滞。这种软件交付方法需要更多的人以更小的增量执行架构工作，比以往任何时候都更加关注价值的早期交付。让我们用物理建筑类比来理解软件架构的重要性。在这个假设的场景中，我们受雇在加利福尼亚州科罗纳多建造标志性的德尔科罗马多酒店的复制品。在1959年著名的电影《热情如火》中出现过，这家酒店实际上代表了南佛罗里达州的塞米诺尔里兹酒店。这部电影的一位富有的粉丝想在佛罗里达拥有一家酒店的复制品。建造最初的酒店并非易事。工程于1887年3月开始，原建筑计划在施工期间不断修改和添加。酒店于1888年2月开业，至今仍未完全完工，在其132年的历史中，酒店已多次翻新和升级。那么我们要用这个项目做什么呢？敏捷开发人员可能希望立即开始构建。相比之下，企业架构师会说，鉴于酒店的复杂历史，立即建造它会造成大量浪费。相反，他想做很多前期规划，并根据当前的建筑技术和实践制定五年建设计划。然而，这两种方法都可能不是理想的。连续架构的目标是弥合这两种方法之间的差距，以获得更好的整体结果。2持续架构的定义满足以下六个简单标准的架构可以称为持续架构：准则1：以产品思维而非项目思维设计架构。从产品的角度构建比简单地设计销售点解决方案更有效，并且团队更容易关注客户需求。准则2：关注质量属性，而不仅仅是功能需求。质量属性需求驱动架构。规则3：仅在绝对必要时才做出设计决策。架构设计基于事实，而不是猜测。设计和实现可能永远不会使用的功能是毫无意义的，而且是在浪费时间和资源。原则4：为变革设计架构，使用“小权力”。大的、单一的、紧密耦合的组件很难改变。相反，使用小型且松散耦合的软件元素。原则5：为构建、测试、部署和操作设计架构。大多数架构方法只关注软件构建活动，但我们认为架构师还应该关注测试、部署和操作以支持持续交付。准则6：完成系统设计后，开始对团队进行组织建模。团队的组成方式驱动着系统的架构和设计。这六个原则、基本活动和工具可以帮助我们进行架构活动并定义软件架构的关键组件，例如：系统上下文影响架构关键功能需求驱动架构质量属性架构和设计决策架构蓝图有趣的是，一个组件软件架构不是孤立存在的，而是相互关联的（见图1）。创建软件架构需要在需求、决策、蓝图甚至最终架构工件（可执行代码本身）之间进行一系列权衡。▲图1软件架构的关键组成部分3连续架构与其他架构方法的区别那么连续架构与其他架构方法有什么区别呢？首先，我们不认为它是一种方法论，而是一套指南、工具、技术和思想，可以看作是架构师有效处理持续交付项目的工具集。使用这些指南、工具、技术和想法没有预设的顺序或过程可遵循，完全取决于每个架构师。我们发现它们非常适合我们从事的项目和产品，而且它们本质上是动态的和高度适应性的。我们希望读者能受到启发，改编持续架构工具集的内容，并用新的想法扩展工具集，为快速交付健壮有效的软件项目提供架构支持。我们坚信，利用连续架构方法可以帮助架构师解决和消除瓶颈。持续架构的目标是通过在整个过程中系统地应用架构观点和原则??来加速软件开发和交付过程。因此，我们能够创建一个可持续的系统，在很长一段时间内为组织创造价值。与主要关注软件交付生命周期(SDLC)的软件设计和构建方面的大多数传统软件架构方法不同，如原则5所述，持续架构为构建、测试、部署和构建的整个过程带来了架构视角。设计架构的操作。它的存在是为了尽可能避免大架构超前综合症，架构团队不再需要创建复杂的工件来描述技术功能，软件开发人员也不再无所事事地等待。它帮助架构师创建有弹性的、适应性强的、灵活的架构，这些架构可以作为可执行代码快速实施、测试并部署到生产中，以便系统的用户可以提供反馈，这是对架构的最终验证。此外，持续架构方法侧重于交付软件而不是文档。与传统的架构方法不同，我们将工件视为一种手段，而不是目的。4持续架构提供的指南和工具我们并不是要定义特定的架构方法或开发过程。我们的主要目标是分享一套在实践中行之有效的核心原则和工具。事实上，应用连续架构就是理解原则和概念并将它们应用到您自己的环境中。这样做，读者可以自由决定使用哪些工具以及如何解释必要的活动。我们定义了这种基于价值的方法，以应对当前在敏捷和持续交付的实用主义中建立坚实架构基础的挑战。然而，这并不意味着使用持续交付是使用持续架构的先决条件。同样，我们意识到有些公司可能还没有准备好在所有方面采用敏捷方法。即使公司完全致力于敏捷，在某些情况下（例如采用第三方软件包时）其他方法也可能更合适（见图2）。▲图2连续架构的应用这是否意味着连续架构在这种情况下不可用？绝对不。持续架构的好处之一是它的工具与其他软件开发方法很好地集成，而不仅仅是敏捷开发。持续架构也在两个维度上运行：软件交付的规模和速度（见图3）。软件交付速度的维度决定了在加速交付周期的世界中如何采用架构实践。虽然规模维度侧重于操作层面，但我们认为持续架构的原则可以在所有产品规模上稳定应用，但关注程度和所需工具会有所不同。▲图3连续建筑维度
