云原生架构模式

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

Bernard Hermant @Unsplash

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

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

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

边车(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"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！

本文由 mdnice 多平台发布