云原生架构模式

文摘   2024-07-13 08:42   上海  

本文主要介绍了云原生架构的主要设计模式,讨论了这些模式的优缺点及其适用场景,并探讨了在云计算环境中的应用和挑战。原文: Cloud-Native Architecture Patterns (Part 1)[1]Cloud-Native Architecture Patterns (Part 2)[2]

Bernard Hermant @Unsplash

在云原生环境中构建应用时,软件架构可能会采用略有不同的方法。云原生应用广泛采用微服务形式构建,此外,应用程序应该能在动态调度和容器化环境中运行,以便利用云计算模型的优势。

云原生计算是一种软件开发[3]方法,利用云计算[4]"在现代动态环境(如公共云、私有云和混合云)中构建和运行可扩展的应用程序"。

云环境中软件架构背后的动机是关注点分离,尤其是运行在容器中的模块化软件组件,以下模式有助于实现这一目的。

边车(Sidecar)/插件(Sidekick)

如果想在不同微服务中抽象出主应用程序的某些外围部分,这种模式会很有帮助,这有助于实现服务之间的独立性,打破紧密耦合的组件。

如果应用程序使用相同的语言和库,需要共享生命周期但又能独立部署的服务,那么 Sidecar/Sidekick 模式将是一个有益的选择。如果为每个实例部署 Sidecar 服务的资源成本不值得隔离的优势,那么在应用程序中实施 Sidecar/Sidekick 模式就是一个错误的决定。如下图所示,日志、配置等功能可以抽象到另一个微服务中。该模式与主服务的关系为 1:1

Sidecar/Sidekick 模式
大使(Ambassador)

大使模式通常用于扩展现有服务的网络能力,尤其是在该服务已经过时或复杂到需要修改的情况下。

大使服务可被视为与客户端同处一地的进程外代理。

通过这种模式增加额外代理会带来延迟。与 Sidecar 不同,这种模式可用于多种服务,有助于增强传统服务的连接功能。因为 Ambassador 模式有代理开销,如果对低延迟要求很高,那么这种模式就不是个好选择。

大使模式
分散(Scatter)/聚合(Gather)

这种模式适用于使用冗余服务的传统应用,其主要思想是建立一个聚合器,汇总来自不同服务的响应,并提供最佳响应。这种模式可以很好的控制流向其他服务的消息流。

分散/聚集模式
BFF(Backends For Frontend)

这种模式的要点是在前端和真正的后端之间再做一层后端,就是所谓的BFF(Backend For Frontend),是在广泛应用的最流行的模式之一。通过添加这一额外层,可以在不同的前端和后端服务之间进行协调,验证来自前端的过滤响应,映射和转换从后端交付的数据模型。

防腐层(Anti-Corruption Layer)

如果系统中有不同的子系统或微服务,它们的语义并不相同,那么这种模式可能会非常有用。防腐层(Anti-Corruption Layer)可以翻译或整合这些服务之间的通信。Eric Evans在《领域驱动设计》(Domain-Driven Design)一书中首次介绍了这一模式。

如果你正在将遗留系统迁移到新系统,因此部分新系统使用了遗留系统的功能资源,那么就很可能出现这种情况。

可能有如下缺点和副作用:

  • 这一额外层引入了更多延迟
  • 这一层也是额外的服务,会占用资源
  • 可维护性、数据一致性、自动缩放以及连接服务的开销也需要被额外关注
ACl 模式
命令与查询责任分离(CQRS, Command and Query Responsibility Segregation)

这种模式基于数据库读取和更新的 SoC(Separation of Concerns,关注点分离)。在传统架构中,如果读取执行许多查询,而写入执行非常复杂的验证和业务逻辑,就会出现数据复杂性问题。这种读写不对称,具有不同的性能和需求。

这里的解决方案可能是 CQRS,将读写分离成不同的部分,命令用于更新,查询用于读取:

  • 命令必须基于任务("预订酒店房间",而不是"将预定状态设为已预订")。
  • 通过异步通信执行命令
  • 查询从不更改数据库。查询响应的 DTO 不包含业务逻辑。

这种模式的缺点是读写组件保持同步。

CQRS 模式
事件源(Event Sourcing)

事件源模式(Event Sourcing Pattern)是近十年来针对 CRUD 应用缺乏一致性的情况而流行的技术之一。与传统 CRUD 应用一样,事件源的主要思想是以仅增加(append-only)的方式保存数据,而不仅仅保存当前状态,从而存储对数据采取的一系列完整操作。这种方式为事务性数据提供了一致性,保持了对历史版本的全面审计控制。

优势:

  • 通过实现强大的数据一致性来提高性能
  • 使用事件存储简化数据版本的实施和管理
  • 事件对于领域专家来说是可读的,而不仅是让开发人员可以理解
  • 由于事件基于时间排序,可以防止对同一数据进行并发更新
  • 事件存储作为数据操作的单一来源

缺点:

  • 被认为是对小领域应用的过度设计
  • 不适合实时数据驱动型应用

你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。为了方便大家以后能第一时间看到文章,请朋友们关注公众号"DeepNoMind",并设个星标吧,如果能一键三连(转发、点赞、在看),则能给我带来更多的支持和动力,激励我持续写下去,和大家共同成长进步!

参考资料
[1]

Cloud-Native Architecture Patterns (Part 1): https://azeynalli1990.medium.com/cloud-native-architecture-patterns-60a010d90978

[2]

Cloud-Native Architecture Patterns (Part 2): https://azeynalli1990.medium.com/cloud-native-architecture-patterns-part-2-9704f160525f

[3]

软件开发: https://en.wikipedia.org/wiki/Software_development

[4]

云计算: https://en.wikipedia.org/wiki/Cloud_computing


DeepNoMind
你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。