InfoQ 2022 年趋势报告：架构与设计篇

每年，InfoQ 的编辑们都会讨论我们在整个软件开发领域所观察到的情况，并编制一些趋势报告，每份报告都有自己的采用曲线图。这有助于编辑团队将报告重点放在创新性技术和想法上，同时也让我们的读者对于需要关注的主题有个全局的认识。

该报告主要有两部分。第一部分是你正在阅读的这份书面报告，包括趋势图和过去一年中个别新增加或有变化的条目的详细介绍，以及 InfoQ 编辑们的概括性分析。

报告的第二部分是InfoQ播客上的一集内容。感兴趣的读者可以收听编辑们的部分对话，以及来自我们专家小组的一些轶事。

趋势图更新

2021 年，我们研究了架构师实现其设计的许多方式，考虑了主要的“非功能性需求（-ilities）”。今年，我们将“安全设计”添加到了该列表中，并在早期采用阶段就考虑。安全一直是一个考量因素，在设计一个系统及其组件时，及早并反复考虑安全问题越来越重要。

架构可能不是 DevSecOps 这个三元混合词的一部分，但它是这个理念的一个底层构件。网络安全和软件架构之间也有很多相似之处，这一点我们在 InfoQ 播客中与Maxime Lamothe-Brassard讨论过。

我们考虑过添加“可扩展性设计”，但最终认为，可以从“弹性设计”和其他适应可扩展性的趋势之下捕获到这些信息。在大流行的第二年，在线服务消费继续增长，企业必须能够扩大规模才能满足需求。

eBPF，即扩展的伯克利包过滤器，是对 Linux 内核进行编程的一种方式。它允许开发者在运行时向操作系统添加功能。我们已经把 eBPF 作为一个创新趋势，并将在未来几年观察其采用情况。Liz Rice 在最近一期InfoQ播客中对该技术做了很好的概要介绍。

将”下一代 GraphQL“改为”GraphQL Federation“，因为它是各公司在其现有 GraphQL 实现之上所做的最重要的工作。

“数据网关”被删除，取而代之以“数据+架构”。另外，“架构师电梯”被替换为“架构决策记录”。下文会详细讨论这些变化。

Dapr 和 WebAssembly 都从创新变为早期采用。

有几个条目被删除了，因为在过去几年里没有被采用，也没有足够的创新，包括开放应用模型（OAM）和 RSocket&Reactive Streams。

数据+架构

我们看到了一个变化，从数据只在系统存储或传输层被考虑，到数据成为系统定义的一个元素。这在人工智能/ML 系统中尤其明显。这些系统是基于数据构建的，在事件源这样的设计模式中也是如此。有时，它表现为一个明确定义的概念，如数据网格，我们将把它作为一个独立的创新趋势继续关注。更多时候，架构师们只是考虑数据的方式不同而已，所以我们在今年的趋势图上增加了“数据+架构”。

在InfoQ播客的采访中，Neal Ford 和 Mark Richards 谈到了在他们的新书 Software Architecture: the Hard Parts 中加入数据相关章节的必要性。Neal 说：

我们想确保我们提供了更全面的信息，因为我们坚信，数据加架构将是未来几年备受关注的主题之一。这也是我们现在在做的很多专业工作的主题——处理好这种关系，并使之成为一种顺利的工作关系，需要 DBA 和架构师之间的合作，还要使这些实践成为我们在架构和设计中习以为常的实践。

数据+架构包含了一些搜索引擎友好的术语，比如在趋势图上被它取代的数据网关。它还包括数据质量等概念，以及试图解决“我们如何确保我们使用的数据是正确的？我们如何知道它是否符合我们的预期？”这个问题的工具。这个问题不处理，其后果可能是灾难性的。

InfoQ 编辑 Eran Stiller 供职于Badook，他在工作中会考虑数据质量问题。他对这个问题的看法如下：

现如今的公司越来越依赖人工智能和机器学习算法。他们利用这些算法改善客户体验，预测销售和库存水平，并获得对其业务的宝贵洞察力。在某些情况下，它们甚至在没有人类干预的情况下完全自动化地做出决定。这些算法依赖于数据。如果数据好，用它构建的模型就可用。但遗憾的是，我们的数据会随着时间的推移而变化，其质量也在下降。数据收集出现错误，数据管道可能在不经意间对我们的数据造成破坏，而我们之前对数据所做的假设可能随着时间的推移不再有效，可能会造成灾难性的商业后果。

 

例如，房地产公司Zillow最近减记了5亿多美元，因为它用于预测房价和驱动其商业决策的数据模型未能适应不断变化的现实。

 

此外，世界各地的监管机构，如欧盟，正在对人工智能算法的创建和使用方式进行监管。最近，美国国会也出台了类似的《算法责任法案》。这些法规的一个关键部分将是确保用于推导算法的数据是正当的。

 

因此，我预测，数据质量和可靠性将成为大多数（如果不是所有）科技公司越来越关注的话题。就像测试代码一样，我们应该测试和验证我们的数据，确保它符合我们的期望。如果不这样做，我们可能会在某天早上醒来时，将我们的商业战略置于错误的预测之上，或者更糟糕，做出灾难性的全自动财务决策，这可能使我们损失数十亿美元。我相信，没人希望陷入这样的境地。

架构师与架构

在整个行业中，对架构师角色以及软件架构与设计实践的定义莫衷一是。许多公司都没有软件架构师的职位，而那些有这个职位的公司，其职责也有很大的差异。尽管如此，软件总是要设计，并且总是有一个架构。我们所面临的挑战是如何识别创新性的架构方式，以及这如何体现在软件架构师的角色中。

这个想法很难浓缩成趋势图上一个简短的概念。去年，我们有“架构师电梯”。Gregor Hohpe 的这个想法是说架构师需要在组织的多个层面上进行沟通。在此之前，我们有“架构师作为技术领导者”。这两个概念都属于早期采用的范畴。这主要是来自一种直觉，它们不一定是创新性的，但也没有被广泛采用。

今年，我们将“架构决策记录（ADR）”添加到早期采用。关于 ADR，Michael Nygard 在 2011 年发表了一篇很好的文章。大多数软件团队都熟悉“盒子和箭头”架构图，这无论是对于记录系统的期望状态还是当前状态都很有用。

然而，了解为什么做出这些设计决策通常是有好处的，这就是 ADR 的目的。通过记录决策，以及当时考虑的其他选项和所做的权衡分析，如果将来需要更新设计，ADR 就会非常有用，或者仅仅是在设计受到质疑时作为一种提醒。

构建分布式系统以及由半自主团队构建微服务有一个副作用，就是架构决策也变得分散。因此，架构师需要帮助团队执行架构任务，如权衡分析、做出正确的决策、记录和沟通这些决策。Andrew Harmel-Law认为，ADR 可以成为扩展软件架构的一个重要组成部分。

要了解更多关于架构师角色和软件架构实践的讨论，我强烈建议你听一听相应的播客。

作者简介

Thomas Betts 是 InfoQ 架构与设计版块的首席编辑，也是 InfoQ 播客的联合主持人，同时还是 Blackbaud 高级首席软件架构师。二十多年来，他一直专注于提供让客户满意的软件解决方案。他曾供职于多个行业，包括零售、金融、医疗、国防和旅游。Thomas 与他的妻子和儿子住在丹佛，他们喜欢徒步旅行以及探索美丽的科罗拉多州。

Eran Stiller 是 Badook（位于澳大利亚墨尔本）的首席软件架构师。作为一名经验丰富的软件架构师和 CTO，Eran 设计、实施和审核过多个业务领域的各种软件解决方案。凭借在软件开发领域的多年经验，以及在公开演讲和社区贡献方面的记录，微软自 2016 年起授予他微软 Azure 最有价值专家（MVP）称号，并自 2018 年起让其担任微软区域总监（MRD）。

Vasco Veloso 从事软件开发和设计已有二十多年了。从汇编到 C、C++和 Prolog，再到 Java、Scala 和 Kotlin，从大型计算机到小型计算机，从软盘到 SSD，从企业内部到云端，他都见过，做过，也用过。他带领团队齐心协力开发出精心设计的软件。他还喜欢通过教学分享知识，并继续设计软件和联网设备。在业余时间，他喜欢探索阿姆斯特丹这座城市。他喜欢摄影，并对航空业非常感兴趣。他曾驾驶过超轻型飞机，并且相信，只要保持必要的专注，他就可以继续飞行，到达目的地，并享受沿途的风景。

Daniel Bryant 在 Ambassador Labs 担任 DevRel 部门的总监，同时也是 InfoQ 的新闻经理和 QCon 伦敦大会的主席。目前，他主要致力于“DevOps”工具、云/容器平台和微服务实现。Daniel 是伦敦 Java 社区（LJC）的领导者。他为多个开源项目做贡献，为 InfoQ、O'Reilly 和 DZone 等知名技术网站撰稿，并定期在 QCon、JavaOne 和 Devoxx 等国际会议上发表演讲。

Sarah Wells 做了 20 年的开发，领导过咨询、金融服务和媒体行业的交付团队。使用基于微服务的架构构建 FT 的内容和元数据发布平台，使她对可操作性、可观察性和 DevOps 产生了浓厚的兴趣。2018 年初，她承担起了金融时报的运营和可靠性职责。最近，Wells 转而接管工程实施部门，将平台和安全工程加入其中。她在金融时报领导了多个团队，为其他工程师构建工具和服务。2021 年底，Wells 离开 FT。她决定在采取下一步行动之前休息一段时间。您可以通过 Twitter 联系她（@sarahjwells）。

原文链接：

Software Architecture and Design InfoQ Trends Report—April 2022