对进化式体系结构实施阶段性方法

有几个软件工具和仪表板可以帮助规划、监视和验证体系结构的发展。

传统上，软件体系结构和设计阶段被视为初始阶段。在这种方法中，体系结构决策被认为在系统的整个生命周期内都有效。凭借时代的智慧和对行业变革的反应，我们开始将建筑视为一种进化。这种发展需要一套不同的方法来指导持续规划，通过持续集成、仪表板和工具来促进，从而为系统的发展提供指南。本文重点介绍支持这一旅程的这些方法和工具。

我们正处在一个快速变化的环境中。正如丽贝卡·帕森斯(Rebecca Parsons)在一次关于演进架构的演示中所讨论的那样，这些变化跨越了业务模式、需求和客户期望。技术版图也经常发生变化。从更广泛的意义上讲，这些变化正在以前所未有的速度发生，并对我们的环境产生影响。

例如，让我们来看看技术--它变化得很快，到达消费者手中的速度也比以往任何时候都快。汽车设计时间正在从几年前的60个月缩短到现在的24个月。在过去的10年里，智能手机的普及率达到了极高的水平。软件，这一切的关键因素，变化得更快。有时，我们使用的软件框架在发布时不再相关。

当我的同事提到视频图形库(Videogular)时，我遇到了这样的情况。这是一个在角度版本8中可用的库。当我在角度版本10中构建应用程序时，我注意到旧的库不再受支持。这意味着我需要使用一个新的图书馆，名为NGX-Videogular。我相信你会有自己的例子。

在这种不断变化中，作为架构师和技术领导者，我们面临着做出架构决策并确保遵循这些原则以及系统不会随着时间的推移而恶化的挑战。就像所有持续不断的事物一样，进化架构也在这种背景下发挥作用。

正如《构建演化体系结构》一书中所描述的，演化体系结构支持跨多个维度的指导性增量更改。就像马丁·福勒(Martin Fowler)在序言中所说的那样，建筑是刻在石头上的东西，需要定义和遵循的愿景受到了敏捷方法的挑战。作为对敏捷方法的响应，体系结构实践显示出变化的迹象。

建筑师扮演的角色与其说是前期结构设计师，不如说是一系列知情的、及时做出的重大决策的监督者。

架构在很大程度上仍然是一种可能的艺术-考虑云定价等财务约束。

这种反应还源于这样一种认识，即软件系统可以随着时间的推移而变化，包括核心或基本元素的变化。通过进化--就像生物一样--这些系统可以拥有更长的寿命。到目前为止，这种价值远远超过了挑战，推动着架构师的发展。当敏捷方法出现时，也观察到了类似的变化。传统的方法是建筑师在早期阶段进入画面，而不是晚些时候到达，以进行整合和接受。作为专家和领导者，我们不可避免地会协助团队顺利驾驭进化浪潮。我们需要传播架构知识，创造一种以身作则的行动文化，这是理所当然的。你可能会注意到，许多公司不再有指定的架构师-相反，团队中的高级工程师以一种更分散的方式发挥作用。

敏捷方法遵循交互式方法或较短的Sprint生命周期，其中每个迭代都涉及从需求、设计、构建、集成到验收的各个阶段。让我们来看一下迭代的一些细节。

在传统的方法中，建筑师的参与深度过去是沿着第一张图中的曲线进行的。在迭代方法中，每次迭代都会挤入所有阶段。这种迭代方法是很好的演化促进器，因为它可以将大的需求分解成小的用户场景。此外，持续交付为演进架构提供了一定的指南。

当我们深入研究这幅图的细节时，我们意识到，较小的更改意味着许多规划、集成和验收的考虑被分成较小的块。从另一方面来说，这意味着架构决策也需要被分解成更小的块。所以，看起来我们让进化发生了，释放了魔鬼！但我们该如何应对这种变化呢？我们的主要职责是制定和指导技术决策。这会改变我作为建筑师的角色吗？

人们经常提到，最优秀的员工会重新定义他们的角色。是的，带着增长的心态，我们需要引领变革！

现在让我们更深入地研究一下。与土木工程不同，在土木工程中，您不能在以后改变基础，现在众所周知的是，即使是数据库也可以通过重构方法(如托管迁移)进行发展。然而，随着时间的推移，软件变得越来越难更改。如果我们把建筑和设计看作是导航导航系统，就像西蒙·布朗所描述的地图一样，我们应该能够在地图上分布导航点。可进化性，这一新能力，对许多其他架构质量属性有影响。

所有维持和繁荣的系统都有一定的指导原则。例如，铁路由轨道和信号系统引导。同样，交通管理系统也支持导航，带有方向指示器。通过考虑所有利益相关者，交通控制仪表盘使监管员能够采取必要的行动。

同样，我们需要建立一个支持进化的系统，包括导轨、指示器和仪表盘。在体系结构术语中，这通常被称为治理。但与之前不同的是，这些系统还描绘了不断变化的环境、对系统的影响，以及治理是否有效。例如，混沌猴子(Chaos Monkey)等系统就更进一步，淘汰了那些落后于基准的系统。

既然我们都同意改变是不可避免的，而且我们理解了导轨的必要性，让我们来看看执行细节。我们如何计划这样的改变呢？我们如何管理变革？我们应该把这些部署在哪里？哪些工具可能会派上用场？

软件生态系统由工具、框架、库、最佳实践和团队组成。我们使用的编程平台通常由应用程序编程接口(API)方面的转换来指导。新的指导原则，即反应性宣言，将响应性、弹性、弹性和信息驱动作为关键方向。

可进化性要求通过API定义轴，实现跨多个维度的渐进式、引导式更改。从治理的角度来看，进化架构建议将健身功能作为提供持续指导系统的一种方式。

健身功能为治理提供了基础。进化计算适应度函数是一种特殊类型的目标函数，用于总结设计解决方案相对于其目标的表现。体系结构适宜性功能提供对某些体系结构特征的评估。这些功能需要分布在整个系统中，以评估系统特征及其演变。系统范围的适应度函数只不过是各个适应度函数的组合，包括体系结构度量、集成测试、监视器、流程度量、合同/接口测试和单元测试。我们可以将这一点扩展到以下三个方面：

让我们来看看规划。像对象流程图(OPM)这样的领域模型图是一个很好的起点。这样的可视化使我们能够使范围变得清晰，并获得对外部和内部接口的洞察力。这使我们能够继续进行一些早期决策，比如初始架构愿景和两个层次的分解。

有了基本的分解，我们就可以在逐个冲刺的基础上规划一个考虑接口和组件的路线图。从分解过程中，我们还可以捕捉到最小可行解决方案的关键元素。这种理解使我们能够识别哪些元素是有风险的，如果后来改变，结果是昂贵的。

在敏捷的世界里，最好的方法之一是遵循基于风险和成本的体系结构(RCDA)。根据这种方法，风险和成本是帮助我们确定每个用户故事或功能的重要性的因素。这种方法还促进了与管理者的共同语言。除了需求驱动的用户情景之外，用户情景还需要在架构用户情景之间保持平衡。

以下是来自投标和提案管理解决方案的此类路线图的一个示例。正如您可能注意到的，我们选择从一系列软件元素开始，这些元素在以后更改起来风险很大，成本也很高。我们还考虑了可测试性。

计算的性能起着关键作用。从风险评估的角度来看，计算速度慢于预期占主导地位。因此，这被认为是一个重要的里程碑。要进行有意义的计算，投标细节和提案细节是必需的。因此，他们被认为是推动者。基于这种平衡特性和使能器的方法，我们计划了在计算中结束的第一个冲刺。在Sprint 3的末尾，我们可能会发现需要改进的计算。这是整合冲刺的前提，我们试图稳定并确保进化在控制之中。

类似地，当我们处理外部接口更改时，我们需要确保它在下一个即时冲刺中得到支持。一旦所有消费者都开始使用新界面，就可以无缝淘汰旧界面。这就是API发挥主要作用的地方。同样，在更改数据库表的情况下，在不干扰工作系统的情况下仔细重构，并像气球一样一步一步地将其充气。

尽管我们可能没有遵循微服务方法，但我们发现遵循反应式服务的原则(如不遵循共享数据)并使用消息队列来共享数据是有益的。这里展示了一个使用一个六边形和两个不同服务的例子，这两个服务分别使用了.NET和Python Flask法。这也让我们可以在不干扰增长的情况下混合技术。

在集成过程中，关键是要实现像集成和测试管道这样的检查点。这些检查点是适应性功能的关键元素，它们被实现为链接在一起的单元测试、集成测试、接口或合同级测试的组合。超过容忍度将意味着集成将停止，并在仪表板中标记红色警报。这些红色警报会触发团队立即采取行动。给出了一个映射适应度函数以实现内置质量控制的例子。

在执行时，我们更接近生产环境。尽管保持开发和生产环境相同是很好的做法，但在许多情况下，可能会有差异。作为执行的一部分，我们创建监视器，包括诊断或日志的运行状况检查。通常，遥测日志有不同的形式。分析它们有助于我们深入了解软件的功能，例如，最常用的功能和最容易出错的区域。大多数服务现在都提供一些健康检查，可以使用谷歌分析(Google Analytics)等工具进行分析。

我们可能需要集成多个工具，包括像Jira这样的规划工具、测试框架(包括Selence)以及Robot框架的集成--来自Jenkins和Wiki的仪表板。它们作为管道链接在一起，以集成一定级别的验收测试。同样重要的是要理解这样一个事实，仪表板不仅仅是为了可见性，也是敏捷团队每天都要检查的。对指导方针的重大偏离将意味着团队专注于通过放下手中的所有其他事情并解决问题来使其正确。与所有支持进化的工具相比，文化方面起着重要的作用。团队中的每个人都需要意识到，忽视导航系统的影响将意味着完全丧失进化能力。

理想的方法应该包括一个仪表盘和日志，让我们能够看到大局，并在需要时更深入地挖掘。某些工具，如Structure 101或Sonar，允许进行架构依赖分析的某些方面。作为架构师，我们还应该有一个指导决策的度量框架。示例表示涉及允许零容忍的外部接口。在技术决策、内部接口和框架的情况下，允许一定的容忍度以实现灵活性。

众所周知，测试是一个可以为质量提供主要输入的单一元素。一个主要的观察是架构师或“领导”在测试中扮演着重要的角色。他们需要指导测试驱动的方法，并持续评估适应度函数。通常，经理可能不会重视集成测试。在这种情况下，我们发现让实习生或新团队成员参与构建集成测试是有益的。这是一种使我们能够促进这些团队成员采用这种文化的方法。

一种高级方法是将测试失败连接到仪表板。根本原因分析可以通过遵循鱼骨分析来整合。不过，考虑到所有的基础设施，一个偏向于行动的团队的重要性不可低估。

进化架构被认为是持续的软件工程之旅的一个主要元素。为了促进进化架构，我们需要在旅程的各个阶段放置健身功能。在规划、集成/部署和执行的不同方面均匀分布所有这些功能是在我们发展的同时管理变化的关键。该链可以由基于风险和成本的体系结构(RCDA)指导。一个仪表盘将所有这些和它提供的批判性可视化结合在一起，再加上一种基于对行动的偏见的文化，这是基本的。

Eltjo Poort，Hans van Vliet，“RCDA：作为风险管理和成本管理学科的架构”，“系统和软件杂志”，2012年5月。

Nick Rozanski和Eóin Woods，《软件系统架构：使用观点和观点与利益相关者合作》。

AbHilash Gopalakrishnan在构建软件系统和新兴技术计划方面拥有20多年的经验。他喜欢在研究、技术和商业的交汇点工作。作为一名热情的未来主义者，他既喜欢建筑师的电梯，又喜欢亲力亲为。学习、应用和分享知识是他的激情所在。他拥有皮拉尼比拉技术与科学学院的软件系统硕士学位，以及麻省理工学院的建筑与系统工程硕士学位。他是IEEE高级成员、ACM成员和INCOSE成员。

InfoQ上上周内容的综述每周二都会发布。加入一个超过25万名资深开发人员的社区。 查看示例。

选择您所在的国家/地区，我同意InfoQ.com按照本隐私声明中的说明处理我的数据。