重要要点
- 值得关注的新软件架构趋势包括微前端，数据网格，AsyncAPI和策略即代码。各种各样的目的表明，创新正在建筑景观的许多不同领域中发生。
- 随着微服务变得越来越普遍，从微服务架构开始的阻力越来越大。越来越多的公司正在考虑正确构建分布式系统或创建现代的模块化整体的基础，以为将来可能需要将其分解为微服务。
- GraphQL显然已经跨越了这个鸿沟，唯一的争论是它被广泛采用。在扩展GraphQL并将其普遍应用于大型企业方面仍存在创新。
- 对低代码/无代码平台的兴趣日益浓厚，它可以使非开发人员能够定制系统。
- 跟踪的几个体系结构概念仅适用于某些情况。因此，他们在采用曲线上没有自然发展的趋势。示例包括功能编程和事件驱动的体系结构。
创新者 早期采用者 早期主流用户 成熟主流用户
良好的软件体系结构的目标是帮助管理复杂的系统。为了响应分布式系统，事件驱动的体系结构和大数据，软件体系结构的最新创新希望能够利用正在出现的最佳实践，还可以帮助指导工程师摆脱常见的陷阱。
InfoQ软件体系结构和设计主题图重点介绍了主要的软件体系结构概念及其在行业中的当前采用状态。InfoQ和QCon都集中在图表的左侧，涵盖了创新者和早期采用者之间的软件趋势状态。我们还将寻找最终会“跨越鸿沟”并为大多数公司所接受的想法。
创新者
创新者中的四个新趋势包括微前端，AsyncAPI，数据网格和策略即代码。
微型前端
微前端旨在将微服务的相同优势带到UI层。通过将复杂的系统分解为更小，更易于管理的部分，团队可以快速开发和发布新功能。
在出现在InfoQ Podcast中之后，我们联系了Building Micro Frontends的作者Luca Mezzalira，对他对未来一两年的期望提出了自己的想法。
卢卡·梅扎里拉（Luca Mezzalira）：微型前端并不是新趋势，但它们在2019年获得了关注。
仍然有很多最佳实践可供发现，社区非常活跃。在过去的8到10个月中，我们制作了新的框架，技术和文档，使微型前端对所有开发人员而言都更加易于使用。
我不认为微型前端将成为前端开发的灵丹妙药，但是我确实相信它是单页面应用程序和服务器端渲染体系结构的绝佳补充。
当我们在大型业务领域中与数十名开发人员一起工作的项目时，微前端会发光，我们希望通过划分为多个子域来降低复杂性，独立部署应用程序的不同部分，而不会在团队之间造成通信和协调开销。
几个组织开始接受它们，我希望在2020年能看到更多的案例研究，以解释这些公司如何采用该范式以及遇到了哪些PRO和CON。
我相信，到2020年，微型前端将成为一种既定的体系结构，并且会被前端社区理解。我不希望微型前端能用于所有的前端项目，但是有很多公司可以真正从这种体系结构范例中受益。
异步API
AsyncAPI解决了静态 API与事件驱动的体系结构和事件源之间的不一致。微服务的采用日益广泛，导致更多公司实施了EDA，这也带动了EDA的发展。但是，这些改进需要从同步的请求/响应API过渡到专门为异步通信而构建的API。
丹尼尔·布莱恩特（Daniel Bryant）表示，他“在客户聊天中偶然听到了这一消息。几乎所有采用Swagger / OpenAPI的人都在看类似AsyncAPI的东西。”
数据网格
ThoughtWorks的Zhamak Dehghani在一篇文章中首先讨论了数据网格的概念。引人深思的概念是，通过拥抱面向领域的数据所有权，可以避免传统数据仓库或整体数据湖的陷阱。
托马斯·贝茨（Thomas Betts）表示：“过去我们没有跟踪数据架构，但是我有兴趣看看这是否遵循了将整体式细分为微服务以提高大数据系统敏捷性的趋势。”
InfoQ向Dehghani询问了她对Data Mesh的当前和未来状态的看法。
Zhamak Dehghani：互联分权是我们数字经济，社会和组织发展的潜在趋势。在过去的十年中，诸如云，微服务，API，容器化和域驱动设计之类的技术已使运营世界的分散化成为可能。但是，不幸的是，数据世界已被集中式的过时范式所支配。数据网格是对分析数据管理失败模式的直接响应，旨在超越组织，使其成为数据驱动的，并与相关的分散化趋势保持一致。
在接下来的一两年中，我希望看到更多地采用Data Mesh，并共享更多的实施案例研究。我希望许多早期的实现将创建自定义的工程工具和技术，我希望这将导致开源工具的发展或云提供商产品的扩展，以满足Data Mesh的技术需求。
我看到业界的问题是什么是Data Mesh，在新的一年中将更改为How to do Data Mesh，当然，随着采用率的增长，接下来的几年中将如何更改Data Mesh。
鉴于Data Mesh需要围绕数据所有权和治理进行组织变革，因此在高层管理人员和领导层的大力支持下，面向工程的组织才能真正实现这一范例。
政策即代码
我们还在管理软件开发生命周期方面看到了创新。作为代码的策略是将结构置于所需系统状态周围的显着趋势之一。这建立在将基础结构作为代码的思想之上，并为体系结构级别带来了类似的好处。在KubeCon和云厂商中，科比看到了Code所谈论的Policy 。
早期采用者
无服务器
总是引发健康讨论的一个主题是无服务器。InfoQ编辑认为无服务器还没有解决这个问题，并且也有人反对这种想法。这与对微服务的抵制有关，因为越来越多的团队意识到无服务器和微服务体系结构并不是要解决每个问题的正确解决方案。
这导致了关于正确构建的分布式系统和模块化整体的健康讨论。
Jan Stenberg观察到在最近的DDD Europe会议上讨论的无服务器和分布式系统：
Stenberg：对我来说有趣的一点是Gojko Adzic 谈论了无服务器，并且非常热情，但他指出，即使是非常简单的“ Hello World”应用程序也是高度分布式的。这将需要熟练的开发人员；这会影响无服务器的成本效益吗？
Vladik Khononov 建议阅读 1970年由Glenford J. Myers写给所有对微服务感兴趣的人的Composite / Structured Design。他说，尽管本书没有提及微服务一词，但本书中讨论的基本设计原则与微服务相同。
Stenberg还认为模块化单片应添加到早期采用者中：
Stenberg：提到了Kamil Grzybek，Randy Shoup等人，也提到了Stefan Tilkov，后者在2015年声称很难构建模块化的整体，因此建议在需要时使用微服务。
但这有点奇怪。怎样构建一个设计良好的模块化应用程序才能成为“早期采用者”？是否有类似“新生代”的早期采用者？
谦虚：有了无服务器，我认为它没有越过鸿沟，我实际上看到了一些反对它的传闻。我认为这是对微服务（或更确切地说，人们意识到微服务并非解决每个问题的答案）的更广泛的反对–我们在QCon London上就该主题进行了演讲。我认为这很可能会保留一些小众方法。我们认为我们应该跟踪/谈论整体的回归吗？
布莱恩特：我最初确实想知道“无服务器”是否越过了鸿沟，但我认为没有。有很多报告（例如）表明了该领域的巨大增长机会，这也使我认为它仍然处于Early Adopter中。
贝茨：一年前，人们谈论的是构建完全无服务器的系统，而且这种炒作已经减少。诸如AWS Lambda或Azure Functions之类的单个无服务器功能可能已经跨越了鸿沟，但是完全无服务器的架构还没有，而且可能永远不会获得广泛采用。
低码和无码
低代码和无代码解决方案有望将更多功能交付最终用户，而无需开发人员参与。尽管业内资深人士可能对供应商的推动力持怀疑态度，但使用这些平台的开发人员试验已经明显增加。
谦虚：我在低代码平台上有点愤世嫉俗。我认为这主要是供应商的推动，也是我以前见过的。话虽如此，我希望看到更多开发人员尝试使用低代码平台，部分原因是Microsoft重新推出了其PowerApps，Flow，Power BI和Power Platform产品的推动。我还发现Google收购AppSheet很有趣。这些平台正在成为大生意，我认为这是我们应该关注的趋势。
Betts：（轻量级）工作流程和决策自动化平台应保留在Early Adopter中。这与低代码/无代码平台有很强的相关性，对于主题图而言，这可能是一个更好的通用术语。这些平台针对的是非开发人员，因此是在购买中，而不是在基础上发展。挑战围绕着集成，而不是围绕一个平台构建主要系统。
Stenberg：低代码使我想起了我的年轻同事，他们在90年代的大学里只因为过时的OO而教过4GL。
我看不到现代工作流程引擎（如Zebee）属于低代码（但它们可能属于“工作流程和决策自动化平台”）。他们正在处理核心业务工作流程，您想让域知道您的核心业务正在平稳运行，并且您不想通过监视来发现问题。
GraphQL
GraphQL显然已经跨越了这个鸿沟，但是InfoQ编辑者的问题是它属于早期多数还是晚期多数。尽管将GraphQL作为一种技术的使用已达到后期多数，但我们仍在看到创新，其中GraphQL影响围绕可伸缩性的体系结构决策并在整个系统中创建凝聚性语言。
谦虚：我认为GraphQL坚定地跨越了鸿沟。Dylan在最新的网络趋势报告中将其列为“多数后期” 。
贝茨：我认为GraphQL已经跨越了鸿沟。采用的级别已将其从仅在API层实现的东西带到了系统设计的中心方面。这可能与TypeScript的采用最为相似，因为在这种情况下，团队认识到在整个系统中使用强类型构造的好处。
软件构架伦理
科比提出了一个问题，我们是否应该在这个队列中跟踪道德。“我越来越多地在SACON和QCon上看到道德操守会议和履历。” 我们最终决定不在此主题图上包含道德规范，因为它可以在“ 软件文化和方法”主题图上得到更好的体现。
Humble指出QCon和InfoQ多年来一直在讨论道德问题：
谦卑：我认为我们倾向于将伦理学视为文化话题，但这是跨领域的。我们绝对应该继续对此进行跟踪并进行报告。我为能在QCon London和相应的eMag的道德操守上迅速完成这项工作而感到自豪，并且我认为鉴于每个人的生活中普遍存在的软件，继续讨论它非常重要。
贝茨认为道德是建筑师作为技术负责人的一个方面：
贝茨：虽然我为人们对道德规范的认识和讨论有所增加感到鼓掌，但我不确定在A＆D主题图表上是否需要提及道德规范。但是，我确实认为技术领导者必须考虑道德的许多方面，并且我希望看到一些有关A＆D中道德考虑的InfoQ文章。我一直认为，在这方面提供指导的最好的人是真正了解它的实践者。没有积极的领导，设计最终将变得被动，并被迫遵守不可避免的政府法规，例如GDPR和CCPA。
其他话题
图表的其余部分基本上保持不变。响应式编程，HTTP / 2和gRPC跨越了这个鸿沟，但是所有其他项目都没有动。对于A＆D来说，这是可以预期的，与编程语言趋势相比，好的创意需要更长的时间才能成熟，并且寿命更长。
作为参考，下面显示了2019年初的主题图。2020版是本文的开头。