2020年的InfoQ软件架构和设计趋势报告

by

• Thomas Betts, Charles Humble, Daniel Bryant, Jan Stenberg

摘要：

该报告是InfoQ编辑团队对2020年软件架构和设计演化的概述，主要关注于基础架构模式、框架使用情况以及设计技能。

核心要点

• 要关注的新软件架构趋势包括微前端、数据网格、AsyncAPI以及策略即代码（Policy as Code）。各种各样的目标表明，在架构的很多不同领域中，创新正在不断涌现。
• 随着微服务变得越来越普遍，开始使用微服务架构的阻力却越来越大。越来越多的公司正在研究正确地构建分布式系统的基础原理，或者是创建现代化的、模块化的单体应用，他们的想法是将来可能需要将它们拆分为微服务。

• GraphQL显然已经跨过了鸿沟，唯一尚有争论的地方是它的采用到了何等广泛的程度。在GraphQL的扩展性方面，依然还有一些创新，以便于使其能够在大型企业中普遍适用。

• 人们对于low-code/no-code平台越来越感兴趣，借助它们，非开发人员也能对系统进行定制。

• 我们所跟踪的一些架构理念只能适用于特定的场景。因此，在采用曲线上它们没有一个自然的进展。这方面的示例包括函数式编程和事件驱动架构。
  

好的软件架构的目标是帮助管理复杂的系统。为了应对分布式系统、事件驱动架构和大数据，软件架构方面的最新创新希望能够利用正在出现的最佳实践，并且指导工程师远离常见的陷阱。

InfoQ软件架构和设计的主题图（Software Architecture and Design Topic Graph）关注了主要的软件架构概念及其当前在行业中的采用现状。InfoQ和QCon都会关注图片左侧的内容，它们涵盖了创新者（Innovators）和早期采用者（Early Adopters）的软件趋势状态。同时，我们也会寻找那些最终“跨越了鸿沟”并被大多数公司所采用的理念。

负责软件架构和设计（Architecture and Design，A&D）的InfoQ编辑会定期讨论这个主题图的状态，识别我们应该关注的新趋势，并且指出目前已经在图中的条目的重要变化。本文提供了我们内部讨论的一些重点，并为主题图中所显示的内容添加了必要的注释。

本次讨论的贡献者包括：

• Charles Humble：InfoQ的总编。
• Daniel Bryant：InfoQ的新闻主管。
• Thomas Betts：InfoQ软件架构和设计的主编。
• Jan Stenberg：InfoQ架构和设计的编辑。

在过去的一年中，我们在软件架构和设计领域看到了一些值得注意的新想法，其中每种想法都对应了一组不同的软件趋势。例如，随着微服务被越来越广泛地采用，实践者发现了它的更多优点和缺点，于是出现了一些模式，帮助我们强化那些运行的很好的方面，并使下一代微服务更加成功。

创新者

在创新者方面包括四个新的趋势：微前端（Micro frontends）、AsyncAPI、数据网格（AsyncAPI）和策略即代码（Policy as Code）。

微前端

微前端将微服务能够带来的收益引入到了UI层。通过将复杂的系统拆分为更小、更易管理的部分，团队可以更快地开发和发布新特性和新功能。

继出现在InfoQ Podcast上之后，我们再次联系到了Building Micro Frontends一书的作者Luca Mezzalira，了解他对未来一两年内的展望。

Luca Mezzalira：微前端并不是一个新的趋势，但是在2019年它获得了很大的发展动力。

目前，依然有很多最佳实践需要去发掘，而且社区非常活跃。在过去的8-10个月中，我们开发出了新的框架、技术和文档，使得微前端技术对所有开发人员更加友好。

我并不认为微前端会是前端开发的银弹，但是我确实希望它能成为单页应用和服务器端渲染架构的一个很好的补充。

在项目中，如果有数十个开发人员在一个大型的业务领域中一同工作的话，我们希望能够划分多个子域来降低复杂性，独立地部署应用的各个组成部分，避免跨团队创建通信和协调的开销的话，那么微前端就用了用武之地。

有很多组织已经开始接受这项技术，在2020年，我希望能够看到更多的案例研究，阐述这些公司是如何使用该范式的以及他们发现了哪些优点和缺点。

我相信在2020年，微前端会成为一个被认可的架构并且能够被前端社区社区所理解，我并不期望微前端会用到所有的前端项目中，但是确实有很多公司能够从这种架构范式中收益。

AsyncAPI

AsyncAPI解决了restful API和事件驱动架构（EDA）与事件溯源之间的不一致性。随着微服务采用的不断增多，导致更多的公司实现了EDA，从而出现了关于EDA的改进。但是，这些改进需要将同步的、请求/响应的API转换成专门为异步通信构建的API。

Daniel Bryant说到，他在“一次与客户聊天的时候听说了这件事情，几乎所有采用了Swagger/OpenAPI的人都在关注像AsyncAPI这样的技术”。

数据网格

数据网格的概念最初是由ThoughtWorks的Zhamak Dehghani在一篇文章中首先引入的。这个值得思考的理念认为通过采用面向领域的数据所有权，可以避免传统数据仓库和单体数据湖的缺陷。

Thomas Betts说，“我们过去没有跟踪过数据架构，但是我很感兴趣的是，为了增强大数据系统的敏捷性，我们是否会遵循将单体分解为微服务的趋势。”

就数据网格的现状和未来状态的问题，InfoQ征询了Dehghani的想法。

Zhamak Dehghani：连接的去中心化是数字经济、社会和组织的一个潜在趋势。在过去的十多年中，像云、微服务、API、容器化以及领域驱动设计等技术使运维领域的去中心化成为可能。但是，令人遗憾的是，数据领域还被过时的集中式范式所主导。数据网格是对分析型数据管理失败模型的直接回应，目标是让组织在数据驱动方面实现跨越式发展，与连接去中心化的趋势保持一致。

在未来的一两年中，我希望看到数据网格被更广泛地采用，有更多的实现案例研究被共享出来。我预期很多的早期实现将会创建定制的工程工具和技术，我希望这能导致开源工具的蓬勃发展或云供应商产品的扩展，从而满足数据网格的技术需求。

在新的一年中，我发现行业中的问题已经从数据网格是什么变成了如何实现数据网格，当然随着采用的不断增加，未来几年的问题将会变成如何正确地实现数据网格。

鉴于数据网格需要围绕数据的所有权和治理进行组织上的变更，那些拥有高管和领导强大支持的面向工程的组织可以真正实现这种范式。

策略即代码

在软件开发生命周期的管理方面，我们也看到了创新。策略即代码（Policy as Code）是一个很显著的趋势，它有助于为系统所需的状态构建结构。它建立在基础设施即代码的思想之上，在架构级别能够带来类似的好处。Bryant看到KubeCon和云供应商都在讨论策略即代码的话题。

早期采用者

Serverless

有一个话题总能激发有益的讨论，那就是serverless。InfoQ的编辑们认为serverless还没有跨越鸿沟，而且这个想法也遇到了一些反对的声音。这与对微服务的反对有关，因为越来越多的团队意识到，serverless和微服务架构并不是所有问题的正确解决方案。

这引发了对正确构建分布式系统和模块化单体的有益的讨论。

Jan Stenberg观察到在最近的DDD欧洲会议上讨论了serverless和分布式系统：

Stenberg：对我来说，很有趣的一点在于Gojko Adzic非常热情地谈到了serverless，但是他指出，即便是一个非常简单的“Hello World”应用也是高度分布式的。这需要熟练的开发人员，这样会影响到serverless的成本效益吗？

Vladik Khononov推荐阅读组合/结构化设计，这是Glenford J. Myers在上世纪70年代所写的，适用于每个对微服务感兴趣的人。他说，尽管这本书没有提到微服务这个术语，但是本书所讨论的基本设计理念是与微服务相同的。

Stenberg还认为模块化单体应该添加到早期采用者中：

Stenberg：请参考Kamil Grzybek、Randy Shoup以及其他人的观点，另外还有Stefan Tilkov早在2015年就声称构建模块化单体非常困难，如果需要的话，推荐直接采用微服务。

但是，这有点奇怪。构建一个设计良好的模块化应用程序怎么会成为早期采用者呢?有没有“新一代”的早期采用者?

Humble：我并不认为serverless已经跨越了鸿沟，实际上我听到了一些反对它的声音。更广泛地来看，我认为这是对微服务的反对（或者，更精确的说，人们意识到微服务并不是所有问题的答案），我们在QCon伦敦上针对这个话题有一个讨论。我认为这还是一种有利的方式。试想一下，我们应该跟踪或者讨论重回单体的方式吗？

Bryant：我最初确实想知道serverless是否已经跨越了鸿沟，但是我现在认为它并没有。有大量的报告（样例）指出这个领域有巨大的增长机会，这也让我认为它依然处于早期采用者状态。

Betts：一年前，人们还在谈论构建完全serverless的系统，现在这种炒作已经减弱了。单独的serverless特性，如AWS Lambda或Azure Functions，可能已经跨过了鸿沟，但是完全的serverless架构还没有，甚至可能永远不会得到大多数人的采用。

Low-Code和No-Code

Low-code和no-code方案承诺将更多的功能交付给最终用户，并且不需要开发人员的参与。虽然业界资深人士可能会对厂商的背后推动力表示怀疑，但使用这些平台来进行试验的开发人员已经明显增多。

Humble：我对low-code平台持怀疑态度，我认为和以往我看到的东西一样，这是厂商的另一波推广。我希望看到更多的开发人员尝试low-code平台，这很大程度上是微软对其PowerApps、Flow、Power BI和Power Platform产品的新一轮推广。我还发现谷歌收购AppSheet是一件很有意思的事情。这些平台正在成为很大的一项事业，我认为这是我们应该关注的一个趋势。

Betts：（轻量级）工作流和决策自动化平台应该依然处于早期采用者状态。这与low-code/no-code有很强的相关性，对于主题图来说，这可能是更全面的一个术语。这些平台的目标是非开发者，因此它们属于购买而不是构建的范畴。它的挑战在于集成，而不是在某个平台上构建主要的系统。

Stenberg：Low code让我想起了年轻的同事，他们在90年代的大学里只学习第四代编程语言，因为面向对象已经过时了。

我并不认为现代工作流引擎（如Zebee）属于low code，（但是它们可能属于“工作流和决策自动化平台”）。它们处理核心业务工作流，我们希望领域能够知道在这些地方核心业务在平稳运行，而不希望通过监控发现问题。

GraphQL

很明显，GraphQL已经跨越了鸿沟，但是InfoQ编辑们的问题是它属于早期大众还是晚期大众。虽然GraphQL作为一项技术可能已经达到了晚期大众，但是我们仍然可以看到在可扩展性和跨系统创建内聚的语言方面，GraphQL的创新依然在影响着架构决策。

Humble：我认为GraphQL肯定已经跨过了鸿沟。Dylan在最新的web趋势报告中将其列到了晚期大众状态。

Betts：我认为GraphQL已经跨越了鸿沟。它的采用程度已经使其从单纯地实现API层，变成了系统设计的核心方面。这可能最类似于TypeScript的采用情况，团队认识到在整个系统中采用强类型构造的好处。

软件架构中的道德规范

Bryant提出了一个问题，我们是否应该在这条话题中跟踪道德准则。“我越来越多地看到在SACON和QCon上关于伦理的演讲和话题。”我们最终决定不在这个主题图中包含道德规范，因为最好将其包含到软件文化和方法的主题图中。

Humble提到了QCon和InfoQ几年来一直是如何讨论道德规范的：

Humble：我认为我们倾向于将道德作为一个文化话题，但这是一件临时插入的话题。我们绝对应该继续跟踪这一话题并就此进行报道。我很自豪我们在QCon伦敦和相关的eMag上涵盖了这一点，我认为考虑到软件在每个人生活中的普及程度，我们继续讨论它是非常重要的。

Betts将道德视为架构师作为技术领导者的一个重要方面：

Betts：虽然我很赞赏人们对道德的关注和讨论，但我不确定道德是否应该出现在A&D的主题图上。但是，我认为技术领导者必须考虑道德规范的许多方面，我希望能够在InfoQ的A&D中看到道德规范方面的文章。我始终认为，在这一领域提供指导的最佳人选是真正理解这一领域的实践者。如果没有积极主动的领导，设计最终将是被动的，并且会被迫遵守不可避免的政府规定，如GDPR和CCPA。

其他话题

图表的其余部分基本没有变化。反应式编程、HTTP/2和gRPC已经跨越了鸿沟，但是所有其他项目都没有变化。这恰好也是A&D所期望的，因为与编程语言趋势相比，好的思想需要更长的时间来成熟并且需要更长的生命周期。

作为参考，2019年初的主题图如下图所示。2020年的版本在本文的顶部。

关于作者

Thomas Betts是InfoQ软件架构和设计的主编，同时是IHS Markit的首席软件工程师，目前该公司是Informa Tech的一部分。二十多年来，他一直致力于提供令客户满意的软件解决方案。他曾在多个行业工作，包括零售、金融、医疗、国防和旅游。Thomas与妻子和儿子住在丹佛，他们喜欢徒步旅行，也喜欢探索美丽的科罗拉多州。

Charles Humble于2014年3月开始担任InfoQ.com的主编，指导我们的内容创作，包括新闻、文章、书籍、视频演示和访谈。在担任InfoQ的全职工作之前，Charles负责我们的Java报道，并担任PRPi咨询公司的首席技术官，PRPi咨询公司是一家评估研究公司，于2012年7月被普华永道收购。他全面负责 PRPi公司内部使用的定制软件的开发。他在企业软件领域工作了大约20年，曾经担任开发人员、架构师和开发主管。在业余时间，他为伦敦的Twofish创作音乐，首张专辑于2014年2月发行，他希望自己的时间能够尽可能多地与妻子和孩子在一起度过。

Daniel Bryant是Datawire的产品架构师，并且担任InfoQ的新闻主管和QCon伦敦的主席。Daniel 目前专注于“DevOps”工具、云/容器平台和微服务实现。他还是伦敦Java社区（LJC）的负责人，为多个开源项目做出贡献，为 InfoQ、DZone 和 Voxxed 等知名技术网站撰写文章，并定期出席QCon、JavaOne和 Devoxx等国际性会议。

Jan Stenberg是居住在瑞典北部的一名IT顾问，工作超过25年，他在.Net/C#和 JVM/Java 方面有着丰富的经验。他的经验范围从大型分布式和基于服务的系统到基于Web和富客户端应用程序，甚至包括硬件相关的软件。

查看英文原文：Software Architecture and Design InfoQ Trends Report—April 2020