https://www.infoq.cn/article/R7lWXd0R4VFf3E0bB\*38

本文概述了我们对当前“架构和设计”领域的看法，这个领域侧重于基础设施模式、技术框架模式的实现，以及软件架构师必须掌握的设计流程和技能。

关键要点：

• 我们看到了“演化式架构”设计需求的增长，这种架构建立在可替换性设计和关注“胶水”组件的基础之上。演化式架构支持功能性和跨功能性需求和约束的未来变化。

• “微服务”架构可能会进入晚期大众阶段，但与“正确设计分布式系统”相关的主题以及反应式和容错式设计将越来越靠近采用曲线。

• 我们预测有些架构主题永远不会转移到早期大众或晚期大众阶段，但它们当中有一些高效的针对特定用例的模式，如基于事件溯源 /CQRS 或基于 Actor 模型的系统。

• 我们看到“架构师”这个角色越来越多地偏向于技术领导力、架构模式识别和框架意识以及横切关注点设计。

• 虽然我们认为“serverless”这个术语有点含糊不清，但我们很欣赏 serverless 将重点放在设计事件驱动的系统以及自动消除某些平台问题的可能性上。

InfoQ 和 QCon 都关注处于“创新者、早期采用者和早期大众”阶段的主题。我们尝试找出符合 Geoffrey Moore 所谓的早期市场的想法。早期市场“客户群由技术爱好者和有远见的人组成，他们希望走在机遇前面，解决迫在眉睫的问题”。我们也在寻找可能会“跨越鸿沟”以便得到更广泛采用的想法。值得一提的是，技术在采用曲线上的确切位置可能会有所不同。例如，湾区公司目前广泛采用微服务架构，但在其他地方可能不是这种情况，而且对他们来说采用微服务也许不太合适。

本文概述了我们对当前“架构和设计”领域的看法，这个领域侧重于基础设施模式、技术框架模式的实现，以及软件架构师必须掌握的设计流程和技能。

从上次评审这个主题以来发生的显著变化是“微服务”已进入到后期大众。同时，根据我们内部的讨论，与“正确设计分布式系统”相关的主题以及反应式和容错式设计离采用曲线已经不远了。在Gartner 炒作周期中，微服务可能正在接近“幻灭低谷”的底部。

我们预测，有些架构主题永远不会沿着采用曲线走向早期大众或晚期大众，但它们当中包含了几种高效的架构模式——例如基于事件溯源 /CQRS 或基于 Actor 模型的系统——可以为某些组织和业务问题提供高效的解决方案。

虽然我们认为“serverless”这个术语有点含糊不清，但我们很欣赏serverless 将重点放在设计模块化、事件驱动的系统以及自动化一些底层操作平台的可能性上。我们还看到了围绕演化式架构的讨论，演化式架构将为需求和约束的未来变化提供支持。

除了技术技能（如架构模式识别和框架意识）和处理横切关注点设计的能力，我们看到“架构师”这个角色正在变得更加专注于软技能，例如技术领导力。

下图是 2018 年下半年的趋势图，2019 版位于文章的开头。

以下是 InfoQ 的三位架构和设计（AD）主题编辑之间的内部聊天记录（内容经过轻微的编辑），为图中的技术定位提供了更多相关信息。

Daniel Bryant，独立技术顾问、Datawire 产品架构师、InfoQ 新闻经理：

我认为 HTTP2 将进入早期采用者阶段，而 HTTP3 则进入创新者阶段。GraphQL（可能也包括 gRPC）可能会进入早期采用者阶段（或创新者？）。我认为混沌工程应该加入 DevOps 的行列。微服务进入晚期大众，BDD、DDD 和 TDD 也是。

我很想看到“演化式架构”出现在某个地方——可能是早期采用者？那么“架构师即技术领导者”（强调角色的非技术演变）呢？

我很想听听你们的想法，我们是否需要移动、添加或删除某些主题？

Jan Stenberg，IT 顾问，在.Net/C# 和 JVM/Java 方面拥有超过 25 年的经验：

我认为 AD 在某种程度上与 InfoQ 报道的其他主题不同。

在 AD 方面，我们没有新的或更新的架构常规基础。相反，由于新的工具、框架或智能架构的出现，已有的想法会再次流行起来，并且可能被包装和品牌化。

有一些领域可以被纳入到两个队列中。从高层面来看，它们可以被纳入到 AD 中，而技术性部分则应该被纳入到另一个队列。我认为 serverless 就是这样的一个例子，从高层面来看，它是 AD 的一个重要领域，而技术性部分则属于云队列。微前端和类似的技术则是另外一个例子，它应该属于 AD 还是 HTML5 和 JavaScript？

我认为有一些领域或架构永远不会出现在早期大众或晚期大众阶段，但它们当中却有一些我最喜欢的架构，比如基于事件溯源 /CQRS 或基于 Actor 模型的系统。我认为，在可预见的未来，它们将是少数人使用的利基架构。我不确定我们应该如何看待这些主题，或许当架构师和开发人员不再谈论它们时，它们就会消失？

以下是我对 AD 未来的看法（或许我希望这样）：

serverless。去年我听过这方面的演讲，它们给我的印象是这一领域将越来越自动化，底层基础设施的工作量将越来越少。

工作流平台（如 Camunda）。我认为它们对于具有复杂业务逻辑的微服务或分布式系统来说非常重要。

事件溯源 /CQRS。我希望它会变得更加主流，可能会进入早期采用者或早期大众阶段。

事件驱动的架构，进入早期采用者或早期大众阶段。

Actor 模型 / 反应式。去年我和 Vaughn Vernon 讨论了这件事，他认为有一天它们会成为主流，但我对此持怀疑态度。

演化式架构很有趣，我认为它进入早期采用者阶段是对的。

混沌工程。是的，它应该属于 DevOps，从 AD 角度讨论这个主题可能是一个例外。

GraphQL 和类似的工具应该属于创新者或早期采用者，它将取代 REST。

架构师即技术领导者。我在家中与各种各样的架构师会面，他们大部分人的主要工作是让商业 / 政府领域专家了解他们自己的领域，所以架构师更应该被纳入到敏捷队列中？

微服务进入晚期大众。我认为微服务很快将成为“今天的 SOA”。很多人用对了，也有很多人将它实现成了分布式单体。

DDD 进入晚期大众，但我希望它仍然会是 InfoQ 的一个有趣的主题。

BDD 进入晚期大众，或“晚期少数派”。

关于 TDD，仍然或多或少会有一些讨论。单元测试或黑盒测试或者其他，但至少会进入晚期大众。

当我在日常生活中（不是在技术大会和类似的活动中）遇到架构师、开发人员和领域专家时，我意识到，我们在这里讨论的很多概念对于他们来说是未知或非常弥散的，这也使得他们很难看到 InfoQ 的好处。大约两年前，我在开发者大会（应该是在加拿大）上听过一个演讲，Vaughn Vernon 问有多少人对 DDD 有所了解，大约有一半的观众举起了手。

当我开始成为 InfoQ 编辑时，我写了一些有关框架和库的文章，我认为这些框架和库新增的功能可能会影响架构，但随着时间的推移，我写的东西越来越关注有趣的博文和演示文稿上，只有一小部分是关于与特定架构密切相关的框架，如 Axon、Akka。

在 QCon 大会期间进行这种讨论会很棒。

Charles Humble，InfoQ 主编：

我和 Vaughn Vernon 都认为 Actor 模型很可能会成为主流——无论是直接地还是通过消息传递来实现。在 JVM 领域，Akka 在这方面做得很好，而在金融领域，基于消息传递的系统长期以来一直是实现 Actor 模型的一种流行的方式。

Actor 似乎很容易掌握和理解，也是处理大规模并行工作的一种很好的方法。我希望看到在Pony之上构建基于 Actor 模型的现代系统，并成为一个榜样，但我不得不说，我个人认为这不太可能。

关于演化式架构，Martin Fowler 去年在播客上谈到了这个问题。我很期待Thoughtworks 的这本书。

Thomas Betts，IHS Markit 首席工程师和 InfoQ Architecture Queue 负责人：

从高层面来看，我同意 Daniel 的大部分观点。Jan 是对的，一些架构模式顺着图中的趋势自然演进，而其他一些则可能永远不会超过早期采用者阶段，因为它们并不会被广泛采用。

有时候，我会对 AD 与 InfoQ 其他主题之间的重叠部分感到困惑，尤其是文化与方法论（CM）。我想这与康威定律有关。架构的很多内容都归结为通信——进入和离开系统的外部通信点是什么？内部服务是如何相互通信的？如何保存和访问数据？

在很多方面，公司解决这些问题的方式以及他们可以选择的选项将基于它们在 AD 和 CM 采用生命周期曲线上的位置。我认为 AD 是这个等式的技术端，而 CM 是非技术端，但这样的比喻似乎过于简单化了。此外，技术实现可能应该属于开发和 / 或语言队列。AD 处于两者之间的软弱处，处理横切面关注点，为如何实现系统提供指导。

我想添加一些具体的讨论点。

serverless——虽然我个人不喜欢这个术语，因为它似乎没有任何特定的含义，它或许应该在早期采用者阶段。

反应式——可能应该属于早期采用者。我认为反应式架构会变得更加普遍，因为开发人员越来越熟悉反应式编程，特别是在使用 JavaScript 时。

DDD——虽然 DDD 本身可能会进入晚期大众，但仍然会有很多与 DDD 密切相关的衍生想法，这些想法会在创新者或早期采用者中。例如，事件溯源可以进入早期采用者或早期大众。但是，我不认为很多子主题应该被包含在 AD 主题图中。

微服务——与“serverless”一样，它是一个容易被滥用或误解的术语。我认为随着它被广泛采用，将进入晚期大众，但可能在分布式架构方面处于早期采用者阶段。

分布式系统——我认为把它放在主题图中并不合适，因为这个概念太宽泛了。但我希望我们在谈论系统设计时可以考虑到分布式。像反应式和容错这样的想法对于构建健壮的分布式系统来说至关重要，而它们在单体系统中可能没有那么重要。这就是为什么要在 AD 主题图中加入混沌工程。

我完全支持在 QCon 大会上讨论这些话题！

关于作者

Thomas Betts是 IHS Markit 的首席软件工程师，拥有 20 年的专业软件开发经验。他一直致力于提供令客户满意的软件解决方案。他曾在多个行业工作，包括零售、金融、医疗、国防和旅游。Thomas 与妻子和儿子住在丹佛，他们喜欢徒步旅行，也喜欢探索美丽的科罗拉多州。

Daniel Bryant正在引领组织和技术变革。他目前的工作包括通过引入更好的需求收集和规划技术来实现组织敏捷性，重点关注敏捷开发中的架构相关性，以及促进持续集成 / 交付。Daniel 目前专注于“DevOps”工具、云 / 容器平台和微服务实现。他还是伦敦 Java 社区（LJC）的负责人，为多个开源项目做出贡献，为 InfoQ、DZone 和 Voxxed 等知名技术网站撰写文章，并定期出席 QCon、JavaOne 和 Devoxx 等国际性会议。

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

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

查看英文原文：https://www.infoq.com/articles/architecture-trends-2019