10个必知必会的云原生架构设计模式

在构建云原生应用程序时，采用了一些不同的软件架构方法。云原生应用程序通常采用微服务架构，以最大程度地利用云计算模型的优势。这些应用程序需要能够在动态编排和容器化环境中运行。

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

云环境中，软件架构的主要目标是关注点的分离，特别是通过将软件组件模块化到容器中。为了实现这一目标，有几种模式可供选择。本文介绍一些常用模式。

1 边车/副车模式

边车/副车模式(Sidecar/Adaptor Pattern)用于将主要应用程序的一些外围功能或附加功能抽象为独立的微服务。这种模式可以实现服务之间的独立性，打破紧密耦合的组件。

边车/副车模式适用于应用程序使用相同的语言和库，并且需要一个共享生命周期但可以独立部署的服务。然而，如果为每个实例部署边车服务的资源成本超过隔离优势，那么在应用程序中实施边车/副车模式可能不是一个明智的决策。例如，将日志记录、配置等功能抽象到单独的微服务中，如下面的示例所示，每个主要服务都有一个关联的辅助服务，它们之间形成一对一的关系。在应用边车/副车模式时，需要综合考虑资源成本和隔离优势。

边车/副车模式

2 大使模式

大使模式(Ambassador Pattern)经常用于扩展现有服务的网络功能，特别是对于那些过于古老或复杂且无法修改的服务。

大使服务可以被视为与客户端共存的一个进程外代理。

通过此模式添加额外的代理会增加延迟。与边车不同，这种模式可以用于多个服务。这种模式对于增强遗留服务的连接功能非常有效。如果低延迟是关键因素，使用大使模式可能会增加代理开销成本，因此不是一个好的选择。

大使模式

3 散点/聚集模式

散点/聚集模式(Scatter/Gather Pattern)是一种用于并行处理大规模数据集的设计模式。这种模式的要点是有一个聚合器，汇总来自不同服务的响应并提供报价。这种模式对于控制消息流到所有微服务非常有用。

散点/聚集模式

散点/聚集模式适用于需要对大量数据进行并行处理的情况，如分布式计算、数据分析、并行搜索等。它可以提高系统的处理速度和吞吐量，利用多个处理单元同时处理数据，从而加快处理过程。

4 前端后端模式

前端后端模式(Backends For Frontends Pattern)的主要要点是在前端和实际后端之间添加另一层后端，这被称为前端后端。这是工业界广泛应用的最受欢迎的模式之一。通过添加这种额外的层，可以在不同的前端和后端服务器之间进行编排，验证过滤来自前端的响应，映射和转换来自后端的数据模型。

BFF模式

5 反腐败层模式

反腐败层模式(Anti-Corruption Layer Pattern)用于解决在不同子系统或微服务之间通信时的语义不匹配问题。这种模式最初由埃里克·埃文斯在领域驱动设计中描述。

当存在多个子系统或微服务它们各自使用不同的语义和数据结构时，可能会导致通信困难和混乱。反腐败层模式的目标是在这些不兼容的系统之间建立一个翻译或转换层，以确保它们之间能够正确地交互和通信。这个层充当了一个中间件，负责将一个系统的请求转换为另一个系统可以理解的格式，并将响应从一个系统的格式转换为另一个系统可以接受的格式。

反腐败层模式的缺点和注意事项：

增加了额外的中间层，可能会引入性能延迟。

需要额外的开发和维护工作来处理转换逻辑。

需要确保反腐败层的正确性和稳定性，以避免引入更多问题。

反腐败层模式

6 命令与查询职责分离模式

命令与查询职责分离模式(Command and Query Responsibility Segregation，CQRS)旨在将读操作(查询)和写操作(命令)分离开来，以优化系统的性能、可伸缩性和灵活性。

在传统的应用程序中，读操作和写操作通常共享相同的数据模型和数据库，这会产生一些问题，例如当需要进行复杂查询时，可能会对写操作的性能产生影响，或者在需要高并发写操作时可能会影响读操作的性能。

解决方案是命令查询职责分离(CQRS)，将读取和写入分为不同的组件：

命令必须基于任务(例如“预订酒店房间”而不是“将预订状态设置为已预订”)。

命令通过异步通信实现。

查询不会改变数据库。查询响应使用不包含业务逻辑的数据传输对象(DTO)。

这种模式的缺点是需要保持读取和写入组件的同步。

命令查询职责分离模式

7 事件溯源模式

事件溯源模式(Event Sourcing Pattern)是过去十年中流行的一种技术，用于处理CRUD应用程序缺乏一致性的情况。与传统CRUD应用程序仅保存当前状态不同，事件溯源的主要是以追加方式保存数据，以存储对数据执行的完整系列操作。它提供了事务数据的一致性，保持了完整的编辑历史记录，提供完全的审计控制。

优点：

通过实现强数据一致性来提高性能。

使用事件存储简化数据编辑的实现和管理。

事件对领域专家可读，不仅对开发人员可理解。

防止对同一数据的并发更新，因为其事件的时间顺序。

事件存储作为数据操作的单一数据源。

缺点：

对于小型领域应用来说可能过于工程化。

不适用于实时数据驱动的应用程序。

8 服务网格模 式

服务网格模式(Service Mesh Pattern)旨在提供对微服务之间通信、安全、监控和可观察性的细粒度控制。

此模式要点是将与应用程序无关的横切关注点(如通信、监控、安全性、身份验证/授权等)与核心业务逻辑隔离开来。这种专用基础设施层为低延迟、可配置性增加了价值。

除了身份验证/授权、服务发现，服务网格模式还提供其他重要功能，如：

断路器

速率限制

条件速率限制

流量转移

9 笨拙组件与智能组件(面向前端)模式

此模式是在关注点分离(SoC)原则基础上的一种进阶模式。在这种模式中，将前端组件分为两种类型：笨拙组件(Dumb Components)和智能组件(Smart Components)。笨拙组件主要负责呈现和展示数据，而智能组件则负责处理数据流和业务逻辑，将数据注入到笨拙组件中。主要通过在笨拙组件中基于@Input和@Output(EventEmitter)的双向数据绑定实现。通过这些注解，笨拙组件从智能组件获取相关数据，或将数据发送到智能组件。智能组件通常注入服务或外观(Facade)并处理数据流。

10 单向架构(面向前端)模式

单向架构(面向前端)模式是一种结合响应式编程的主要模式。在当今的前端框架中，数据流是单向的，由数据流向驱动。数据仅以一种方向流向视图，而视图的反馈会触发不同的操作。这种设计使得对数据的控制更加精确。在处理数据流时，使用不同的库如RxJs、NgRx、Flux，可以提供多种功能和工具。