【软件架构】软件架构和设计 InfoQ 趋势报告—2021 年 4 月
关键要点
- 在云原生世界中,架构师正在重新确定他们认为最重要的事项的优先级。创新的架构师正在设计弹性、可观察性、可移植性和可持续性。
- Dapr 和开放应用程序模型是使构建分布式系统更容易的两种方法,观察它们在未来如何被采用将会很有趣。
- 在单体应用和微服务之间摇摆到极端之后,钟摆似乎要停止了。因此,无论底层技术如何,架构师都依赖于专注于高内聚和低耦合的成熟模式和设计。
- 在完全远程的工作环境中,架构师正在寻找与团队沟通的新方式,并寻找有助于收集知识的饮水机聊天的替代品。
- 下一代 GraphQL 功能,尤其是 GraphQL 联合和 GraphQL 微服务,正在展示公司大力采用 GraphQL 之后的下一步发展方向。
每年,InfoQ 的编辑都会讨论软件架构和设计的当前状态,并确定需要关注的关键趋势,从而产生这份报告和随附的图表。今年,我们让您在 InfoQ 播客的一集中收听讨论。 IBM 企业战略团队的创新领导者 Holly Cummins 和 QCon 的前任发言人也加入了编辑的行列。
为___设计
我们首先看看哪些“-ilities”对架构师来说最重要。软件架构师负责横切关注点,并确保大型系统的各个组件可以无缝协作以实现总体目标。在 2021 年,我们认为架构师关注的四个领域是弹性设计、可观察性设计、可移植性设计和可持续性设计。
弹性设计对于现代分布式系统至关重要,其中任何单个组件都可能出现故障,而整个系统应保持可用。在许多方面,正在实施的想法并不新鲜——随着分布式系统和模块化架构越来越普遍,它变得越来越重要。 Daniel Bryant 提到了 David Parnas 在 1970 年代所做的工作,以及 Michael Nygard 最近的著作《Release It!》,作为有关断路器、超时、重试和弹性系统的其他基本要求的想法的良好来源。新的是寻找跨系统解决这些问题的方法,例如使用云原生服务网格,甚至在 Dapr 等框架上构建。
在采用曲线的下方,异步编程技术和事件驱动架构的采用一直在稳步增长。这种采用是实现异步模式的较低准入门槛和提高系统弹性的内置优势的结果。
然而,事件驱动架构和异步系统的另一面,一般来说,它们仍然难以推理和理解。这与可观察性设计的兴起有关。很多时候,可观察性被视为一种运行时需求——我们能否判断系统是否按预期运行?但是,对于架构师来说,可观察性作为设计时的需求变得越来越重要——我们能理解复杂系统中发生的所有交互吗?
2021 年,创新者正在寻找几乎自动提供运行时和设计时可观察性优势的方法。通过消除开发人员必须手动实现可观察性非功能性需求的负担,系统大图中缺少关键组件的可能性变得更小。这将导致能够使用可观察性来创建准确的、生动的架构图,以及相应的系统心智模型。
架构师的另一个重点领域是设计可移植性,无论是多云还是混合云。在大多数情况下,架构师没有理由为实现真正的多云可移植性或避免供应商锁定而设计最低公分母。然而,尤其是在企业收购时,CTO 更有可能拥有在不同的托管环境中运行的系统,包括 AWS、Azure、GCP 和本地。在做出有关标准化的决策时,架构师需要选择他们的战斗。
Holly Cummins 谈到了可持续设计的主题,这是新的创新趋势之一。这种情况正在出现,因为人们意识到软件行业的碳使用水平与航空业相当。其中一些几乎可以直接衡量,因为计算使用的账单与能源消耗高度相关。 CTO 和架构师可以通过减少不必要的计算使用或利用更可持续的云托管选项来产生影响。一些云数据中心使用 100% 的绿色能源运行,而弗吉尼亚州的数据中心则使用煤炭供电。如果延迟不是问题,那么在冰岛而不是弗吉尼亚举办可能是有意义的。虽然许多公司纯粹出于经济原因希望降低托管成本,但有些公司选择将可持续性作为优先事项,并相应地构建和部署他们的系统。
正确构建的分布式系统
微服务的主题在趋势图中稳步移动,并且在一段时间内被归类为晚期主流趋势,因为构建分布式系统变得更加容易。然而,我们继续看到一些反对过度使用微服务作为解决所有问题的尝试。在某些情况下,这导致了重大逆转,例如回到单体应用。随着钟摆停止摆动,似乎我们终于为大多数系统设置了一种理智的方法。
围绕构建分布式系统或模块化单体的一些趋势都回到了基本的架构原则,例如高内聚和低耦合。领域驱动设计虽然被认为是一种晚期主流趋势,但仍然受到寻求上下文映射和识别系统边界的良好指导的架构师的重视。同样,C4 模型对于创建分层架构图集以帮助理解您的系统非常有用。
数据架构
InfoQ 继续在软件架构和数据架构之间的重叠中看到创新。去年添加到图表中的数据网格今年仍然是创新趋势。它由数据网关加入,这有点像 API 网关,但专注于数据方面。由于微服务导致了多语言持久层,API 网关提供抽象、安全、扩展、联合和合同驱动的开发功能。
架构师的角色
我们将继续关注软件架构师在其组织中所扮演的角色。除了传统的“盒子和箭头”职责之外,架构师还担任其他团队成员的技术领导和导师。架构师还需要能够与许多观众进行交流,Gregor Hohpe 将其描述为乘坐架构师电梯——与 CTO 和其他高管交谈,然后前往机房与开发人员一起工作。
对于许多团队来说,由于大流行以及许多公司采用了长期的远程工作策略,沟通方式被打乱了。这意味着架构师失去了通过渗透学习的能力,仅仅是因为他们可以和开发人员坐在同一个房间里偷听对话。在这有帮助的地方,它导致了更多的书面交流,无论是在 IM 聊天室,还是在架构决策记录中,并保持最新,因为团队经常引用它们。领先的架构师正在寻找方法来利用完全远程团队的限制来发挥自己的优势,并因此创建更好的软件设计。
其他主题
Dapr 和开放应用程序模型 (OAM) 都是微软在 2019 年底推出的。OAM 是一种用于定义云原生应用程序的规范,专注于应用程序,而不是容器或编排器。同样,Dapr 是一个具有可插拔组件的框架,旨在简化云原生开发。尽管微软参与了他们的创建,但两者都是开源项目,可以在任何云提供商上工作,而且 Dapr 可能会成为 CNCF 项目。 Dapr 和 OAM 都还没有被大规模采用,因此显然是值得关注的创新趋势。
WebAssembly 是另一个创新趋势。对于架构师来说,看看它是否只是作为 Web 框架和移动开发的补充,或者系统是否会在设计时考虑到 WebAssembly,以及这将如何体现,将会很有趣。
关于 GraphQL 的最后一点,它在去年跨越了趋势图上的鸿沟。从那时起,对于下一代 GraphQL 功能,尤其是 GraphQL 联合和 GraphQL 微服务,出现了创新,特别是在 Netflix。正如微服务造成的蔓延导致了管理这种蔓延的新模式一样,对于在 GraphQL 上投入巨资的公司来说,他们需要 GraphQL 联合来帮助管理新的复杂性。这不是每家公司都会遇到的问题,但了解并了解它在未来的发展方向仍然很有用。
- 28 次浏览