敏捷、DevOps和云中的可持续架构

创建和维护可持续的软件架构对于架构师和工程师而言是一项挑战。为了迎接挑战，他们需要通过预先设计尝试满足每一个需求，提供每一种功能，并规划每一个系统组件，而这需要在实施之前完善架构设计。另一方面，他们也可以让敏捷开发引导架构设计，从而构建软件架构的雏形，这样做可以在前期架构规划匮乏的情况下，让开发团队开始软件的功能交付。但遗憾的是，在交付可持续架构方面，这两种方法都不是百发百中。

持续架构 (CA Continuous Architecture ) 方法在前期设计和架构雏形之间提供了一种有意义的折衷方案，同时它也是敏捷、DevOps 和云时代实现可持续架构性的有效途径。

一、什么是持续架构

持续架构是一种方法，但不是非常正式的方法论，它可以很容易地与具体环境相适应。

如上图所示，持续架构基于以下六个简单原则，描述了在敏捷、DevOps 和云世界中如何不断完善软件架构：

构建产品：将项目演化为产品。构建产品的过程比仅仅为项目设计解决方案更有效，这样可以使团队更多专注于客户需求。

关注质量，而不是功能需求。通过质量驱动系统架构的构建。

非必要不设计：基于事实而不是猜测来设计架构。设计和实现永远不会使用的功能只是浪费时间和资源，毫无意义。

拥抱架构变化——利用“小力量”。大的、单体的、紧密耦合的组件随着架构发展很难改变，相反，利用小型、松散耦合的软件元素，能更加灵活多变地适应架构变化。

架构设计需要考虑：构建、测试、部署和运维等多方面因素。大多数架构方法只关注软件构建活动，但架构师和工程师更需要关注测试、部署和运维，以支持持续交付。

架构设计决定组织结构：团队的组织方式会推动系统的架构和设计。

这些原则提供了架构设计的思维方式，但不一定要照抄。以下四项基本内容也需要考虑：

关注质量：这是优秀架构设计应该着力解决的跨领域需求。

推动架构决策：架构决策是架构活动的主要工作单元。

明晰技术债务：对技术债务的理解和管理是可持续架构的关键。

实施反馈循环：在软件开发迭代中了解架构决策对开发的影响。自动化是有效反馈循环的关键方面。

此外，持续架构包括一个架构“工具箱”，其中囊括一整套经过验证的工具，例如决策日志、实用程序树和架构策略。软件架构师和工程师可以根据具体环境，维护与和扩展工具箱里的内容。

二、质量是可持续性的关键
在软件架构的背景下，我们所说的可持续性到底是什么意思呢？可持续的软件架构专注于满足已知的、当前的需求，同时不影响满足未来、未知需求的能力。也就是适合当下面向未来。由于质量需求推动架构设计工作（持续架构原则 2），因此满足质量需求是创建可持续架构的有效方法。

遗憾的是，质量需求并不像功能需求那样有据可查，它们可能被记录为简单的项目列表：例如，指出“系统必须快速”或“系统必须具有可扩展性”，但不会告诉软件架构师和工程师如何设计满足这些要求。

为了更好地描述质量要求，我们可以使用 ATAM Scenarios 和 Utility Trees 方法，具体如下所示：

该方法依赖于场景中的三个关键属性：

“刺激”描述了系统的任何外部因素，例如来自用户或者系统的故障，这种刺激会对应用场景进行重新定义。

“响应”描述了预期系统对刺激的响应。

“测量”通过提供一个可测量的目标（可以是一个范围）来进一步定义对刺激的响应。

还有几个质量属性对于阐述数字时代的可持续软件架构也很重要，它们包括：安全性、可扩展性、性能以及弹性。软件架构师和工程师不见得对其有深刻的理解，或者在系统设计中优先考虑这些因素。然而，质量属性相关的要求是架构设计过程的关键组成部分。

二、架构决策和技术债务
推动架构决策是持续架构中的一项基本活动，因此架构决策是从业者的主要工作单元。几乎每个架构决策都需要做出权衡。例如，为优化质量属性要求（例如性能）的实现而做出的决定可能会对其他质量属性（例如可用性或可维护性）的实现产生负面影响。同时加速软件系统的交付而做出的决策可能会增加技术债务，这些债务需要在未来的某个时候“偿还”，并可能影响系统的可持续性。最后，架构决策还会影响系统的成本，可能需要做出妥协以满足分配给该系统的预算。

由于团队无法控制的约束，权衡不能做到最佳，并且决策依赖于利益相关者的反馈。创建和维护可持续架构的关键使持续做出架构决策并做出有意识的权衡，同时还要根据需要进行调整。

保持对架构决策（包括所有相关约束）的记录也非常重要，因为创建可持续架构本身就是在团队受约束的情况下为其找到最佳解决方案。因此，记录团队的选择、决策的基本原理以及权衡决定就显得尤为重要了。同时，在最终决策之前还需要评估和记录逆转决策的成本，因为为了保持系统的可持续性，未来的某个时间点可能需要逆转一些决策。持续架构原则 3 提醒我们，要根据事实而非猜测来设计架构，而事实可能会随着时间改变，从而影响我们已经做出的决定。最后，将决策日志与源代码保存在同一存储库中，确保架构决策记录保持最新和准确。

三、架构策略
选择和应用架构策略是解决质量属性要求的绝佳方法。架构策略是一种经过验证的技术，起源于卡内基梅隆大学软件工程学院 (SEI/CMU) 的研究。架构策略是一种设计决策，它影响软件架构处理特定质量属性的程度。架构策略通常（但不幸的是并非总是）记录在目录中，以促进架构师对知识和工具的重用。例如，下图展示用于处理可伸缩性故障的策略：

在创建和维护软件系统时，使用架构策略有助于系统的可持续性，因为这样的设计是基于高质量模块来架构的。

四、构建可持续的软件系统
正如上文所提到的，在当前敏捷、DevOps 和云计算的背景下，软件架构师和工程师通常很难在大型前期设计和架构雏形之间找到一个好的折衷方案。需要多少次架构设计才能完成第一次迭代交付并定义质量属性要求？团队又如何构建“前期”架构来应对不可避免的需求变化？

为了回答这些问题，可持续架构方法建议从“最小可行架构”的角度进行思考，按照持续架构原则 3“非必要不设计”从少量架构决策设计实际要求。通过这种方法，团队可以快速创建一个可行的软件系统，该系统可以发布到生产环境中。然后继续根据需要做出设计决策，以处理新需求和变更。此外，将计划、进度和决策传达给所有系统利益相关者也很重要。

使用最小可行架构策略是一种以更低成本快速将软件产品推向市场的有效方法。但我们所说的“最小可行架构”到底是什么意思呢？简单来说，创建最小可行架构包括以下步骤：

最初的设计架构用来满足软件系统的需求，以便快速创建可行的系统用于生产。

然后，可以不断扩充最小可行架构，以满足随时间推移而附加的需求。

因此，保持架构设计的灵活性至关重要，利用持续架构原则 4（“拥抱架构变化——利用小力量”）是实现这一目标的绝佳方式。

软件架构师和工程师在构建系统时倾向于考虑最坏的情况。例如，他们可以通过估计系统能够处理的最大事务数（交易数）来评估可扩展性要求，然后在评估的数字上再添加一个“安全限度”。由于客户所提供交易数据有可能是一个乐观的猜测，因此，团队可能会构建新系统来处理不切实际的交易数量，并给设计增加不必要的复杂性。

所以，最好在架构启动时就基于实际估计的最小值架构系统，并根据实际数据变化调整架构。这种方法创建了一个更具可持续性的软件系统，并且比基于最坏情况设计的系统更具成本优势。此外，可持续架构还包括处理系统故障和监控关键质量属性（如可扩展性和弹性）的机制。

总结
软件架构由质量属性要求驱动，其中包括安全性、可扩展性、性能和弹性等，这些因素对于数字时代的可持续软件架构来说非常重要。当今的架构设计是一个持续不断的决策流程，这些决策被不断重新审视，以支持软件产品的可持续交付。在一个敏捷、云和 DevOps 时代，架构已成为团队要担负的责任。通过持续架构方法以及最小可行架构策略，或许会让你离目标实现更进一步。

部分内容来自穆拉特·埃代尔 (Murat Erder)、皮埃尔·普雷尔 (Pierre Pureur) 和约恩·伍兹 (Eoin Woods) 所著《持续架构实践》（ Continuous Architecture In Practice）以及穆拉特·埃代尔 (Murat Erder) 和皮埃尔·普雷尔 (Pierre Pureur) 所著《持续架构：基于敏捷和云中的可持续架构》（ Continuous Architecture: Sustainable Architecture In An Agile and Cloud-Centric World ）

起源

流派

视频

书籍

敏捷动态

培训

关于我们