「软件架构」InfoQ 软件架构和设计趋势报告2020年4月

关键点

• 需要关注的新软件架构趋势包括微前端、数据网格、AsyncAPI和作为代码的策略（Policy as Code）。目的的多样性表明，创新在架构景观的许多不同领域都在发生。
• 随着微服务变得越来越普遍，开始使用微服务架构的阻力也越来越大。更多的公司正在研究正确构建分布式系统或创建现代、模块化单体的基本原理，他们的想法是，可能需要在稍后的时间将它们分为微服务。
• GraphQL显然已经跨越了鸿沟，唯一的争论是它被采用的范围有多广。在扩展GraphQL并使其普遍适用于大型企业方面仍有创新。
• 人们对低代码/无代码平台越来越感兴趣，这使得非开发人员能够定制系统。
• 跟踪的几个架构概念仅适用于某些情况。因此，他们在采纳曲线上没有自然的进展。示例包括函数式编程和事件驱动架构。

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

InfoQ软件架构和设计主题图强调了主要的软件架构概念及其在业界的应用现状。InfoQ和QCon都专注于图表的左侧，涵盖了创新者和早期采用者之间的软件趋势状态。我们也在寻找最终“跨越鸿沟”并被大多数公司采纳的想法。

InfoQ负责软件架构和设计（A&D）的编辑定期讨论主题图的状态，确定我们应该涵盖的任何新趋势，并注意到在采用图中已有项目方面的任何重大变化。本文提供了我们内部讨论的一些要点，为主题图上显示的简单文本添加了必要的注释。

本次讨论的参与者包括：

• InfoQ主编Charles Humble
• InfoQ新闻经理Daniel Bryant
• Thomas Betts，InfoQ架构与设计主编
• Jan Stenberg，InfoQ架构与设计编辑

在过去的一年里，我们看到了在A&D领域出现的显著想法，每一个都解决了不同的软件趋势。例如，随着微服务被越来越广泛地采用，从业者发现了更多的优点和缺点，模式出现了，以加强已经运行良好的内容，并使下一代微服务更加成功。

创新者

创新者中的四个新趋势包括微前端、AsyncAPI、数据网格和代码即策略。

微型前端

Micro前端旨在为UI层带来microservices的相同好处。通过将复杂的系统分解成更小、更易于管理的部分，团队可以快速开发和发布新的特性和功能。

在出现在InfoQ播客上之后，我们联系了Luca Mezzalira，《构建微前端》（Building Micro Frontends）一书的作者，他对未来一两年我们的预期提出了自己的看法。

Luca Mezzalira:微型前端不是一个新趋势，但它们在2019年获得了吸引力。 仍有许多最佳实践有待发现，社区非常活跃。在过去的8-10个月里，我们开发了新的框架、技术和文档，使所有开发人员都能更容易地使用微前端。 我不认为微前端是前端开发的银弹，但我真的相信它是对单页应用程序和服务器端渲染架构的一个极好的补充。 当我们有几十个开发人员在一个大的业务领域中一起工作的项目时，微前端会发光，我们希望通过划分成多个子域来降低复杂性，独立部署应用程序的不同部分，而不会造成跨团队的通信和协调开销。 一些组织开始接受他们，到2020年，我希望看到更多的案例研究，解释这些公司是如何采用这种模式的，以及他们遇到了哪些利弊。 我相信在2020年，微前端将成为一个成熟的架构，并为前端社区所理解，我不期望微前端将永远用于所有的前端项目，但有许多公司可以真正受益于这种架构模式。

异步API

AsyncAPI解决了restfulapi与事件驱动架构和事件源之间的不一致。越来越多的微服务的采用已经导致更多的公司实施EDAs，这导致了EDAs的发展。但是，这些改进需要从同步的请求/响应API转移到专门为异步通信而构建的API。

丹尼尔布莱恩特说他“在客户聊天中听说了这件事。几乎所有大力采用AsyncAPI/OpenAPI的人都在寻找类似AsyncAPI的东西。”

数据网格

ThoughtWorks的Zhamak Dehghani在一篇文章中首次讨论了数据网格的概念。发人深省的概念是，通过采用面向领域的数据所有权，可以避免传统数据仓库或单一数据池的陷阱。

Thomas Betts说：“我们过去没有跟踪数据体系结构，但我很感兴趣的是，这是否遵循了在大数据系统中为提高灵活性而将单体数据分解为微服务的趋势。”

InfoQ询问Dehghani对数据网格的现状和未来的看法。

扎马克·德赫尼：互联分权是我们数字经济、社会和组织发展的一个基本趋势。在过去的十年中，云、微服务、API、容器化和领域驱动设计等技术使得运营世界的分散化成为可能。但不幸的是，数据世界一直被不合时宜的集权模式所支配。数据网格是对分析性数据管理失效模式的直接响应，旨在使组织在成为数据驱动型组织时实现跨越式发展，顺应互联分散化趋势。 在接下来的一两年里，我希望看到数据网格得到更广泛的采用，并分享更多的实施案例研究。我预计许多早期的实现将创建定制的工程工具和技术，我希望这将导致开源工具的激增或云提供商产品的扩展，以满足数据网格的技术需求。 我看到这个行业的问题是什么是数据网格，在新的一年里，它正在转变为如何进行数据网格，当然，随着采用率的增长，在接下来的几年里如何正确地进行数据网格。 鉴于数据网格需要围绕数据所有权和治理进行组织变革，得到高管和领导层大力支持的面向工程的组织可以真正实现这一模式。

代码即策略（Policy as Code）

我们还看到围绕管理软件开发生命周期的创新。Policy as Code是一个显著的趋势，有助于将结构置于所需的系统状态。这建立在基础设施作为代码的思想之上，并为体系结构级别带来类似的好处。布莱恩特把政策看作是KubeCon和云供应商谈论的代码。

早期采用者

无服务器

一个总能引发健康讨论的话题是无服务器。InfoQ的编辑们觉得无服务器还没有跨过鸿沟，也有一些人反对这个想法。这与对微服务的回击有关，因为越来越多的团队意识到无服务器和微服务体系结构并不是每个问题的正确解决方案。

这导致了关于正确构建的分布式系统和模块化整体的健康讨论。

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

Stenberg：对我来说，一个有趣的观点是Gojko Adzic谈到了无服务器，他非常热情，但是指出即使是一个非常简单的“Hello World”应用程序也是高度分布式的。这需要熟练的开发人员；这会影响无服务器的成本效益吗？ 弗拉迪克霍诺诺夫推荐阅读复合/结构化设计，由格伦福德J迈尔斯在70年代为每个对微服务感兴趣的人写的。他说，虽然这本书没有提到微服务这一术语，但书中讨论的基本设计原则与微服务相同。

Stenberg还认为，模块化的巨石应该添加到早期采用者中：

Stenberg：提到Kamil Grzybek、Randy Shoup和其他人，也提到Stefan Tilkov，他在2015年声称很难构建模块化整体，因此建议在需要时使用微服务。 但这有点奇怪。如何构建一个设计良好的模块化应用程序成为早期采用者？有没有像“新一代”这样的先行者？

Humble：对于无服务器，我不认为它已经跨越了鸿沟，我实际上看到了一些轶事推回来反对它。我认为这是对微服务的一种更广泛的回击（或者更准确地说，人们意识到微服务并不是解决所有问题的答案）——我们在伦敦QCon就这个话题进行了讨论。我认为这很可能是一种利基方法。我们认为我们应该追踪/谈论巨石的回归吗？

布莱恩特：我最初确实想知道“无服务器”是否已经跨越了鸿沟，但我不认为它已经跨越了鸿沟。有很多报告（例如）指出了这个领域的巨大增长机会，这也使我认为它仍处于早期采用阶段。

贝蒂斯：一年前，人们谈论的是构建完全无服务器的系统，而这种炒作已经减少。个别的无服务器特性，如AWS Lambda或Azure函数，可能已经跨越了鸿沟，但完全无服务器架构还没有，而且可能永远不会获得大多数采用。

低代码和无代码

低代码和无代码解决方案承诺将更多的功能交给最终用户，而不需要开发人员的参与。虽然业界资深人士可能对供应商的推动持怀疑态度，但使用这些平台的开发人员试验明显增多。

Humble：我在低代码平台上有点愤世嫉俗；我认为这主要是一个供应商推送，也是我以前见过的。也就是说，我预计会有更多的开发人员尝试低代码平台——部分原因是微软重新推出了其PowerApps、Flow、Power BI和Power平台产品。我还发现看到谷歌收购AppSheet很有趣。这些平台正在成为大生意，我认为这是一个趋势，我们应该保持关注。

Betts:（轻量级）工作流和决策自动化平台应该仍然是早期采用者。这与低代码/无代码平台有很强的相关性，这可能是主题图的一个更好的全称。这些平台针对的是非开发人员，因此，它们是在购买而不是构建端。挑战在于集成，而不是在一个平台上构建主要系统。

Stenberg：低代码让我想起了我年轻的同事，他们在90年代的大学里只教4GL，因为OO已经过时了。 我不认为现代的工作流引擎（如Zebee）属于低代码（但也许它们属于“工作流和决策自动化平台”）。他们正在处理核心业务工作流，您希望领域知道您的核心业务运行顺利，而不希望通过监视发现问题。

GraphQL

GraphQL显然已经跨越了鸿沟，但InfoQ编辑器的问题是，它是属于早期的还是晚期的大多数。虽然GraphQL作为一种技术的使用可能已经达到了晚期的大多数，但是我们仍然看到了创新，GraphQL正在影响围绕可伸缩性的架构决策，并在整个系统中创建一种内聚的语言。

Humble：我认为GraphQL已经牢牢地跨过了鸿沟。在最新的网络趋势报告中，迪伦占据了最后的多数。 贝茨：我想GraphQL已经跨越了鸿沟。它的采用程度已经从刚刚在API层实现的东西变成了系统设计的一个核心方面。这可能最类似于TypeScript的采用，在这种情况下，团队认识到强类型构造在整个系统中的好处。

软件架构中的伦理学

布莱恩特提出了一个问题，我们是否应该在这个队列中追踪道德规范。”我越来越多地看到SACON和QCon的伦理会议和跟踪，“我们最终决定不在这个主题图中包含伦理，因为它在软件文化和方法主题图中表现得更好。

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

Humble：我认为我们倾向于把道德作为一个文化话题，但这是一个跨越队列的话题。我们绝对应该继续追踪并报告此事。我很自豪我们很快就通过QCon London的伦理轨道和相应的eMag来覆盖它，我认为考虑到软件在每个人的生活中是多么普及，我们继续谈论它是非常重要的。

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

贝蒂斯：虽然我对提高对道德的认识和讨论表示赞赏，但我不确定是否需要在A&D专题图上公布道德。然而，我确实认为道德的许多方面必须由技术领导人来考虑，我想看一些InfoQ关于A&D中道德考虑的文章。我始终认为，在这方面提供指导的最佳人员是真正理解道德的实践者。如果没有积极的领导，设计最终会变得被动，被迫遵守不可避免的政府法规，如GDPR和CCPA。

其他主题

图表的其余部分基本保持不变。反应式编程、HTTP/2和gRPC已经跨越了鸿沟，但所有其他项目都没有移动。这在A&D中是意料之中的，与编程语言趋势相比，好的想法需要更长的时间才能成熟，寿命也更长。

以下是2019年初的主题图，供参考.2020年的版本是文章的顶部。

原文：https://www.infoq.com/articles/architecture-trends-2020