作者丨PierrePureur译者丨崔浩计划丨赵云审校丨梁策，孙淑娟开篇文章创建和维护可持续的软件架构对于架构师和工程师来说是一个挑战。为了迎接挑战，他们需要通过前期设计来满足每一个需求，提供每一个功能，规划每一个系统组件，这就需要在实施之前完善架构设计。另一方面，他们也可以让敏捷开发来指导架构设计，从而构建软件架构的原型。这样，开发团队就可以在没有前期架构规划的情况下，开始软件的功能交付。不幸的是，这两种方法都不是交付可持续建筑的完美方法。持续架构（CAContinuousArchitecture）方法在前期设计和架构原型制作之间提供了一种有意义的折衷，也是在敏捷、DevOps和云时代实现可持续架构的有效途径。什么是持续架构？持续架构是一种方法，但不是一种非常正式的方法，可以很容易地适应特定情况。摘自：《持续架构实践》（持续架构实践），作者MuratErder、PierrePureur和EoinWoods如上图所示，持续架构描述了如何基于六个简单原则在敏捷、DevOps和云世界中持续改进软件架构：构建产品：将项目发展为产品。构建产品的过程比仅仅为项目设计解决方案更有效率，这让团队可以更专注于客户需求。关注质量，而不是功能需求。以质量驱动体系架构建设。除非必要，否则不要设计：根据事实而不是猜测来设计架构。设计和实现永远不会使用的功能只是浪费时间和资源，毫无意义。拥抱架构变化——利用“小权力”。大型的、单体的、紧密耦合的组件很难随着架构的发展而改变。相反，使用小型、松散耦合的软件元素可以更灵活地适应架构变化。架构设计需要考虑构建、测试、部署和运维等诸多因素。大多数架构方法只关注软件构建活动，但架构师和工程师需要更多地关注测试、部署和操作以支持持续交付。架构设计决定组织结构：团队的组织方式驱动系统的架构和设计。这些原则提供了一种思考架构设计的方法，但不必照搬它们。还需要考虑以下四个基本事项：关注质量：这是一个优秀的架构设计应该重点解决的交叉需求。驱动架构决策：架构决策是架构活动的主要工作单元。清除技术债务：理解和管理技术债务是可持续架构的关键。实施反馈循环：了解架构决策在软件开发迭代期间对开发的影响。自动化是有效反馈循环的一个关键方面。此外，ContinuousArchitecture包括一个架构“工具箱”，其中包含一整套经过验证的工具，例如决策日志、实用程序树和架构策略。软件架构师和工程师可以根据具体环境维护和扩展工具箱的内容。质量是可持续性的关键在软件架构的上下文中，可持续性到底是什么意思？可持续的软件架构侧重于满足已知的当前需求，同时不影响满足未来未知的容量需求。即适合当下，面向未来。由于质量要求驱动架构设计工作（连续架构原则2），满足质量要求是创建可持续架构的有效方式。不幸的是，质量需求不像功能需求那样被详细记录，它们可能被记录为简单的项目列表：例如，声明“系统必须快速”或“系统必须可扩展”，但没有告诉软件架构师和工程师设计以满足这些要求。为了更好地描述质量要求，我们可以使用ATAM场景和效用树方法，如下所示：来源：MuratErder和PierrePureur作者：《持续架构：基于敏捷和云中的可持续架构》（持续架构：敏捷和以云为中心的世界中的可持续架构）该方法依赖于关于场景中的三个关键属性：“刺激”描述了系统的任何外部因素，例如来自用户或系统的故障，这种刺激将重新定义应用场景。“响应”描述了预期系统对刺激的响应。“测量”通过提供可测量的目标（可以是一个范围）进一步定义对刺激的反应。几个质量属性对于制定数字时代的可持续软件架构也很重要，包括：安全性、可扩展性、性能和弹性。软件架构师和工程师不一定对它们有深刻的理解，或者在系统设计中优先考虑它们。然而，与质量属性相关的需求是架构设计过程的关键组成部分。架构决策和技术债务驱动架构决策是持续架构中的一项基本活动，因此架构决策是从业者的主要工作单元。几乎每个架构决策都需要权衡。例如，为优化质量属性要求（如性能）的实现而做出的决策可能会对其他质量属性（如可用性或可维护性）的实现产生负面影响。为同时加速软件系统交付而做出的决定可能会增加技术债务，这些技术债务将需要在未来的某个时间点“偿还”，并可能影响系统的可持续性。最后，架构决策也会影响系统的成本，可能需要做出妥协以满足分配给该系统的预算。由于团队无法控制的限制，权衡不是最优的，决策取决于利益相关者的反馈。创建和维护可持续架构的关键是持续做出架构决策并做出有意识的权衡，同时根据需要进行调整。记录架构决策（包括所有相关约束）也非常重要，因为创建可持续架构本身就是在给定约束的情况下为团队找到最佳解决方案。因此，更重要的是记录团队的选择、决策的理由以及所做的权衡。同时，在最终决策之前，还需要评估和记录逆转决策的成本，因为某些决策可能需要在未来的某个时间点被逆转，以保持系统的可持续性。持续架构原则3提醒我们根据事实而不是猜测来设计架构，事实可能会随着时间而改变，影响我们已经做出的决定。最后，将决策日志保存在与源代码相同的存储库中，可确保架构决策的记录保持最新和准确。架构策略选择和应用架构策略是解决质量属性需求的绝佳方式。架构策略是一种经过验证的技术，源自卡内基梅隆大学软件工程研究所(SEI/CMU)的研究。架构策略是一种设计决策，它影响软件架构处理特定质量属性的程度。架构策略通常（但遗憾的是并不总是）记录在目录中，以促进架构师对知识和工具的重用。例如，下图显示了处理可扩展性故障的策略：来源：MuratErder、PierrePureur和EoinWoods作者：《持续架构实践》（ContinuousArchitectureInPractice）在创建和维护软件系统时，架构策略的使用有助于系统的可持续性，因为此类设计基于高质量模块。构建可持续的软件系统如上所述，在当前敏捷、DevOps和云计算的背景下，软件架构师和工程师通常很难在大型前期设计和架构原型之间找到良好的折衷。交付第一次迭代并定义质量属性要求需要多少架构设计？团队如何构建“前期”架构来应对不可避免的需求变化？为回答这些问题，可持续架构方法建议从“最小可行”出发，从连续架构的角度思考，根据连续架构的原则3“设计是不必要的”，从少量的架构决策中设计实际需求。通过这种方法，团队可以快速创建一个可以发布到生产环境中的可行软件系统。然后根据需要继续做出设计决策，以处理新的需求和变化。此外，向所有系统利益相关者传达计划、进度和决策也很重要。使用最小可行架构策略是将软件产品以更低的成本快速推向市场的有效方式。但我们所说的“最小可行架构”到底是什么意思？简单地说，创建最小可行架构包括以下步骤：初始设计架构用于满足软件系统的要求，以便快速创建可用于生产的可行系统。随着时间的推移，最小可行架构可以不断扩充以满足额外的需求。因此，在架构设计中保持灵活性至关重要，而利用持续架构原则4（“拥抱架构变化——利用小力量”）是实现这一目标的绝佳方式。软件架构师和工程师在构建系统时倾向于考虑最坏的情况。例如，他们可以通过估算系统将能够处理的交易（交易）的最大数量，然后在估算的数量上加上“安全边际”来评估可伸缩性需求。由于客户提供的交易数据可能是一种乐观的猜测，团队可能会构建新系统来处理不切实际的交易数量，并为设计增加不必要的复杂性。因此，架构启动时最好根据实际预估的最小值来架构系统，并根据实际数据变化调整架构。这种方法创建了一个更具可持续性的软件系统，并且比基于最坏情况设计的系统更具成本效益。此外，可持续架构包括处理系统故障和监控关键质量属性（如可扩展性和弹性）的机制。总结软件架构由质量属性要求驱动，包括安全性、可扩展性、性能和弹性，这些对于数字时代的可持续软件架构非常重要。今天的架构设计是一个持续的决策过程，不断地重新审视以支持软件产品的可持续交付。在敏捷、云和DevOps时代，架构已成为团队的责任。通过持续的架构方法和最小可行架构策略，您可能离实现目标更近了一步。部分改编自《持续架构实践》（ContinuousArchitectureInPractice），作者MuratErder、PierrePureur和EoinWoods；MuratErder和PierrePureurCuiHao的译者《持续架构：基于敏捷和云中的可持续架构》（ContinuousArchitecture:SustainableArchitectureInAnAgileandCloud-CentricWorld）的译者简介，社区编辑，高级架构师，拥有18年的软件开发和架构经验，以及10年的分布式架构经验。他曾经是惠普的技术专家。乐于分享，撰写了多篇阅读量超过60万的热门技术文章。《分布式架构原理与实践》作者。原标题：SustainablearchitecturesinaworldofAgile,DevOps,andcloud,byPierrePureur
