GMTC 全球大前端技术大会(北京站)门票 9 折特惠购票最后 10 天,点击立减 ¥480 了解详情
写点什么

2020 年 InfoQ 趋势报告:架构与设计

2020 年 5 月 09 日

2020年InfoQ趋势报告:架构与设计

本文要点:


  • 我们关注的新软件架构趋势包括微前端、数据网格、AsyncAPI 以及策略即代码(Policy as Code)。各种各样的迹象表明,在架构的很多不同领域中,创新正在不断涌现。

  • 微服务变得越来越普遍,但使用微服务架构的阻力却越来越大。越来越多的公司正在研究正确地构建分布式系统的基础原理,或者是创建现代化的、模块化的单体应用,以方便将来将它们拆分为微服务。

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

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

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



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


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


负责架构与设计(Architecture and Design,A&D)的 InfoQ 编辑会定期讨论这个概览图,识别我们应该关注的新趋势,并且指出现有条目的重要变化。本文提供了我们内部讨论的一些重点,并为概览图中所显示的内容添加了必要的注释。


本次讨论的贡献者包括:



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


创新者

在创新者方面包括四个新的趋势:微前端(Micro frontends)、AsyncAPI、数据网格(Data Mesh)和策略即代码(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 GrzybekRandy 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 提出了一个问题,我们是否应该在这条话题中跟踪道德准则。“我越来越多地看到在SACONQCon上关于伦理的演讲和话题。”我们最终决定不在生命周期概览图中包含道德规范,而将其包含到文化与方法的概览中


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


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


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


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


其他话题

概览图的其余部分基本没有变化。反应式编程、HTTP/2 和 gRPC 已经跨越了鸿沟,其他项目都没有变化。这恰好也是架构与设计领域所期望的,因为与编程语言趋势相比,好的思想需要时间成长和更长的生命周期。


作为参考,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


2020 年 5 月 09 日 16:143237

评论

发布
暂无评论
发现更多内容

不要在nodejs中阻塞event loop

程序那些事

node.js Event 事件循环 程序那些事 nodejs event

时间约束帮助我写作

Justin

方法论 创意 习惯养成 28天写作

【WOW.js】Animate.css的黄金搭档

学习委员

CSS 动画 js 28天写作 2月春节不断更

【并发编程的艺术】详解单例模式的实现方式(Java)

程序员架构进阶

设计模式 Java内存模型 七日更 28天写作 2月春节不断更

就算知道了答案,真的会改变吗?「幻想短篇 25/28」

道伟

28天写作

话题讨论|过年回家你带电脑吗?

熊斌

话题讨论 28天写作

持续进步的不二法宝-PDCA

Ian哥

28天写作

第十周 模块分解作业

简简单单

第三章:产品解决方案作业

让时间说真话

产品经理

安卓开发软件有哪些?分析Android未来几年的发展前景,吐血整理

欢喜学安卓

android 程序员 面试 移动开发

云原生动态周报 | Google推出VM Manager

华为云原生团队

Docker 开源 云原生 开源项目 华为云

史上最清晰的Tarjan算法详解

华为云开发者社区

算法 静态分析 语法树 Tarjan 数据流

产品经理训练营第0期-第三次作业

孙行者

第0期 产品经理训练营 问题

机器学习·笔记之:Matrices and Vectors

Nydia

产品训练营第二章作业(二)

Arnold

大背景 (28天写作 Day25/28)

mtfelix

28天写作 新能源汽车 新能源革命 碳中和

第三章: 产品解决方案作业

让时间说真话

产品经理 产品经理训练营

创业失败启示录|样茶里的商机

青城

28天写作 创业失败启示录 青城 2月春节不断更

python爬虫入门-通过茅台脚本讲些爬虫知识,应用和价值

大佬sam

Python python 爬虫 2月春节不断更

安卓开发交流!一线互联网移动架构师筑基必备技能之Java篇,Android岗

欢喜学安卓

android 程序员 面试 移动开发

Python 中 sorted 如何自定义比较逻辑

zikcheng

Python sorted cmp

高性能缓存 Caffeine 原理及实战

vivo互联网技术

Java Caffeine 本地缓存

ModelArts AI Gallery与HiLens Kit联合开发丨行人社交距离风险提示Demo

华为云开发者社区

华为云 modelarts hilens 行人 社交距离

第三章:产品解决方案作业

让时间说真话

产品经理

第十周 学习总结

简简单单

传统线程同步通信技术

武哥聊编程

Java 多线程 28天写作

第五周作业

oooh-la

OpenAI将k8s扩展至7500个节点以支持机器学习;Graph Diffusion Network提升交通流量预测精度

京东科技开发者

区块链 开源

产品经理训练营作业 02

KingSwim

开发质量提升系列:标准模板(中)

罗小龙

最佳实践 方法论 28天写作

持续交付

lidaobing

持续交付 28天写作

openEuler Developer Day 2021

openEuler Developer Day 2021

2020年InfoQ趋势报告:架构与设计-InfoQ