微前端、数据网格、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年，微前端将成为一个成熟的架构，并为前端社区所理解。我不期望微前端将永远用于所有的前端项目，但许多公司真的可以从这种架构模式中受益。
AsyncAPI解决了restfulapi与事件驱动架构和事件源不一致。越来越多的微服务使用导致更多的公司实施EDAs，这导致了EDAs然而，这些改进需要同步的请求/响应API转移到专门为异步通信而建立的转移API。
丹尼尔布莱恩特说:我在客户聊天中听说过这件事。几乎所有人都大力采用。AsyncAPI/OpenAPI人们在寻找类似的东西AsyncAPI的东西。”
ThoughtWorks的Zhamak Dehghani数据网格的概念首次在一篇文章中讨论。发人深省的概念是，传统数据仓库或单个数据池的陷阱可以通过使用面向领域的数据所有权来避免。
Thomas Betts我们过去没有跟踪数据系统的结构，但我很感兴趣的是，这是否遵循将单个数据分解为微服务以提高大数据系统的灵活性的趋势。
InfoQ询问Dehghani对数据网格现状和未来的看法。
扎马克·德赫尼：互联分权是数字经济、社会和组织发展的基本趋势。云、微服务、API、集装箱化、领域驱动设计等技术使运营世界分散化成为可能。但不幸的是，数据世界一直被不合时宜的集权模式所支配。数据网格是对分析数据管理失效模式的直接响应，旨在使组织在成为数据驱动组织时实现跨越式发展，顺应互联分散的趋势。
在接下来的一两年里，我希望看到数据网格得到更广泛的应用，并分享更多的实施案例研究。我预计许多早期的实现将创建定制的工程工具和技术，我希望这将导致开源工具或云供应商产品的激增，以满足数据网格的技术需求。
我看到这个行业的问题是什么是数据网格。在新的一年里，它正在转变为如何进行数据网格。当然，随着利用率的提高，如何在未来几年正确进行数据网格。
鉴于数据网格需要围绕数据所有权和治理进行组织改革，高管和领导大力支持的项目组织可以真正实现这种模式。
我们还看到了围绕管理软件开发生命周期的创新。Policy as Code这是一个明显的趋势，有助于将结构置于所需的系统状态。这是基于基础设施作为代码的思想，并为系统结构水平带来类似的好处。布莱恩特认为这项政策是KubeCon与云供应商讨论的代码。
无服务器是一个总能引发健康讨论的话题。InfoQ编辑们认为没有服务器还没有跨越差距，有些人反对这个想法。这与微服务的反应有关，因为越来越多的团队意识到，没有服务器和微服务系统的结构并不是每个问题的正确解决方案。
这导致了对正确构建的分布式系统和模块化整体健康的讨论。
Jan Stenberg最近在观察DDD在欧洲会议上讨论的无服务器和分布式系统：
Stenberg：对我来说，一个有趣的观点是Gojko Adzic谈到无服务器，他很热情，但指出即使是一个很简单的Hello World应用程序也是高度分布的。这需要熟练的开发人员；这会影响无服务器的成本效益吗？
格伦福德J迈尔斯在20世纪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显然已经跨越了鸿沟，但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
本文：http://jiagoushi.pro/node/982
讨论:请加入知识星球或者微信圈子【首席架构师圈】
| 微信公众号 | 关注微信公众号【首席架构师智库】 | |
| 微信小号 | 希望加入的群：架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化，产品转型。 | |
| 知识星球 | 向大咖提问，近距离接触，或者获得私密分享。 | 点击加入知识星球【首席架构师圈】 |
| 微信圈子 | 志趣相投的同好交流。 | 点击加入微信圈子【首席架构师圈】 |
| 喜马拉雅 | 路上或者车上了解最新黑科技资讯，架构心得。 | 点击，收听【智能时刻，架构君和你聊黑科技】 |
| 知识星球 | 认识更多朋友，职场和技术闲聊。 | 点击加入知识星球【知识和技术】 |