CQRS Design Pattern in Microservices - CQRS模式

原文链接 CQRS Design Pattern in Microservices - GeeksforGeeks

【文章看起来像是AI写的。。。  😂😂😂】

简介

实现步骤

1，识别有界上下文：（Identify Bounded Contexts:）

2，命令和查询路径分离（Separate Command and Query Paths）

3，实现命令服务（Implement Command Services:）

4，实现查询服务（Implement Query Services:）

5，定义APIs（Define APIs）

6，选择数据存储机制（Choose Data Storage Mechanisms:）

7，建立异步通信（Establish Asynchronous Communication:  ）     

8，处理最终一致性（Handle Eventual Consistency:）

真实例子-在线书店（online bookstore）

1，命令服务（Command Services:）

2，查询服务（Query Services:）

3，事件驱动架构（Event-Driven Architecture:）

4，数据存储（Data Storage:）

5，API Gateway:

几个原则和概念

服务边界（Service Boundary）：

关注点分离 （Separation of Concerns）:

独立扩展 （Independent Scaling）

Domain-Driven Design (DDD)领域驱动设计 （Domain-Driven Design (DDD)）:

Event-Driven Architecture:事件驱动的体系结构 （Event-Driven Architecture:）

关注点分离  （Separation of Concerns of CQRS ）

命令职责（Command Responsibility）

写操作（Write Operations）

验证和业务逻辑：（Validation and Business Logic:）

事务行为：（Transactional Behavior）

查询职责（Query Responsibility）

读取操作（Read Operations）

优化的数据检索：（Optimized Data Retrieval）

可伸缩性：（Scalability）

沟通协调：（Communication and Coordination）

命令-查询分离：（Command-Query Separation）

异步通信：（Asynchronous Communication）

最终一致性：（Eventual Consistency）

Domain建模:（Domain Modeling）

Domain-Driven Design (DDD):

有界上下文（Bounded Contexts）

主要组件(Key Components of CQRS)

命令服务：（Command Service:）

命令处理程序：(Command Handlers:)

领域逻辑：(Domain Logic: )

事务行为：(Transactional Behavior):

查询服务（Query Service:）

查询处理（Query Handlers: ）

 优化的数据访问：（Optimized Data Access: ）

可伸缩性：（Scalability: ）

Event Bus or Message Broker:

异步通信：（Asynchronous Communication:）

发布-订阅机制：（Publish-Subscribe Mechanism:）

解耦：（Decoupling: ）

数据存储（Data Stores:）

写存储（命令侧）：（Write Store (Command Side):）

Read Store（查询端）：（Read Store (Query Side):）

API Gateway or Service Mesh:

入口点：（Entry Point: ）

路由和负载平衡：（Routing and Load Balancing: ）

安全和身份验证：（Security and Authentication: ）

优势（Advantages of CQRS）

扩展性（Scalability:）

性能优化（Performance Optimization:）

灵活性和可维护性 （Flexibility and Maintainability:）

改进的性能和响应能力 （Improved Performance and Responsiveness:）

挑战（Challenges of CQRS）

提升了复杂性（Increased Complexity:）

一致性管理（Consistency Management:）

数据同步：（Data Synchronization:）

操作开销: （Operational Overhead:）

---

简介

CQRS（ Command Query Responsibility Segregation ）意思就是 把 处理命令（command）的职责 和 查询数据（Query）的职责 分离开（Segregation）。

实现步骤

1，识别有界上下文：（Identify Bounded Contexts:）

        在应用不同规则和定义的域中定义有界上下文。每个有界上下文可能对应于体系结构中的微服务边界。

2，命令和查询路径分离（Separate Command and Query Paths）

        指定特定的微服务来处理命令（写操作），其他微服务来处理查询（读操作）。确保这两条路径之间的关注点清晰分离。

3，实现命令服务（Implement Command Services:）

        创建负责处理命令的微服务。这些服务接收命令请求，验证它们，执行必要的操作来更改系统的状态，并发布表示状态更改的事件。

4，实现查询服务（Implement Query Services:）

        开发专门处理查询的微服务。这些服务响应读请求从系统中检索数据，确保有效的数据访问和优化读操作。

5，定义APIs（Define APIs）

        为命令和查询服务设计清晰一致的API，指定它们支持的操作类型以及它们接受和返回的数据格式。

6，选择数据存储机制（Choose Data Storage Mechanisms:）

        根据命令和查询服务的具体需求，为其选择合适的数据存储机制。例如，命令业务可能使用针对写操作优化的NoSQL数据库，而查询业务可能使用关系数据库进行复杂的查询。

7，建立异步通信（Establish Asynchronous Communication:  ）     

        在命令和查询服务之间实现异步通信机制（如 message brokers 或 event buses）。这允许命令服务发布表示状态变化的事件，查询服务可以订阅这些事件以获得最终的一致性。

8，处理最终一致性（Handle Eventual Consistency:）

        开发机制来处理命令和查询服务之间的最终一致性。这可能涉及实现协调流程（reconciliation processes）、补偿事务（compensating transactions），或者使用事件重放（event replay）等技术来保持一致性。

真实例子-在线书店（online bookstore）

1，命令服务（Command Services:）

        订单服务（Order Service:）负责处理与订单管理相关的命令。命令包括创建新订单、更新订单状态和处理付款。该服务确保订单在数据库中得到验证、处理和持久化。

        库存服务（Inventory Service:）负责管理与库存管理相关的命令。命令包括增加或减少图书库存、更新产品可用性和处理缺货。此服务确保库存变化准确地反映在系统中，并相应地更新库存水平。

2，查询服务（Query Services:）

        商品目录服务（Product Catalog Service:）负责处理与产品目录相关的查询。查询包括检索图书信息、按标题或作者搜索图书以及列出可用产品。该服务提供对产品数据的快速有效访问，以便在网站或移动应用程序上显示。

        订单历史服务（Order History Service: ）负责处理与订单历史记录和客户资料相关的查询。查询包括检索订单详细信息、查看订单历史记录和管理用户配置文件。此服务为客户提供访问其过去订单的权限，并允许他们跟踪订单状态。

3，事件驱动架构（Event-Driven Architecture:）

        Event Bus: 事件用于在命令和查询服务之间通信更改。当下了一个新订单（命令）时，将发布一个事件，指示订单的创建。查询服务订阅相关事件并相应地更新其读取模型，从而确保命令端和查询端之间的最终一致性。

4，数据存储（Data Storage:）

        写入存储（Write Store (Command Side): ）使用为写操作优化的数据库，如关系数据库或NoSQL数据库。命令服务存储与订单、库存变更和其他写操作相关的数据。
 

        读取存储（Read Store (Query Side)：）使用单独的数据库进行读操作优化。查询服务维护数据的非规范化视图或投影（projections），以提高查询性能。

5，API Gateway:

        Entry Point: API网关充当客户机应用程序与微服务体系结构交互的入口点。
它根据正在执行的操作将请求路由到适当的命令或查询服务。

几个原则和概念

服务边界（Service Boundary）：

        每个微服务都围绕特定的业务功能或领域定义了一个清晰的边界。该边界封装了与该域相关的命令（command）和查询（query）职责。

关注点分离 （Separation of Concerns）:

        CQRS强调分离处理命令（commands）（写操作）和处理查询（queries）（读操作）的职责。每个微服务要么专注于处理命令，要么专注于处理查询，但不是两者都做。

独立扩展 （Independent Scaling）

        由于命令和查询通常具有不同的性能特征和可伸缩性需求，CQRS允许微服务根据它们处理的工作负载独立扩展。例如，负责处理高频（high-frequency）命令的微服务可以独立于处理复杂查询的微服务进行扩展。

Domain-Driven Design (DDD)领域驱动设计 （Domain-Driven Design (DDD)）:

        CQRS通常与领域驱动设计原则一起应用。DDD有助于识别有界上下文（bounded contexts）、聚合（aggregates）和域实体（domain entities），然后可以按照CQRS模式将它们映射到微服务。

Event-Driven Architecture:事件驱动的体系结构 （Event-Driven Architecture:）

        事件驱动的体系结构通过支持微服务之间的通信和维护分布式系统之间的一致性来补充CQRS。事件可以用来通知其他微服务由于命令执行而导致的状态变化

关注点分离  （Separation of Concerns of CQRS ）

命令职责（Command Responsibility）

写操作（Write Operations）

        负责处理命令的微服务专注于管理数据修改。它们接收执行更改系统状态的操作的请求，例如创建、更新或删除数据。

验证和业务逻辑：（Validation and Business Logic:）

        命令微服务执行业务规则并验证传入请求，以确保数据完整性和一致性。        

事务行为：（Transactional Behavior）

        命令通常在事务边界内执行，以保证原子性、一致性、隔离性和持久性（ACID属性）。
 

查询职责（Query Responsibility）

读取操作（Read Operations）

        用于处理查询的微服务专注于从系统中检索数据。它们在不改变系统状态的情况下响应信息请求。

优化的数据检索：（Optimized Data Retrieval）

        查询微服务优化数据存储和检索机制，以实现高效的读取操作。这可能涉及对数据进行非规范化、采用缓存策略或使用专门的查询语言。

可伸缩性：（Scalability）

        查询微服务可以根据读取工作负载独立伸缩，从而实现高效的资源分配和性能优化。
沟通协调：

沟通协调：（Communication and Coordination）

命令-查询分离：（Command-Query Separation）

        处理命令的微服务和处理查询的微服务之间存在明确的界限，防止重叠，并确保每个服务都有明确的职责。

异步通信：（Asynchronous Communication）

        命令和查询微服务可以异步通信，允许解耦交互和容错。异步消息传递系统或事件驱动的体系结构促进了服务之间的通信。

最终一致性：（Eventual Consistency）

        异步通信可以导致命令端和查询端之间的最终一致性。微服务必须优雅地处理最终的一致性场景，确保数据正确性并将用户影响降至最低。

Domain建模:（Domain Modeling）

Domain-Driven Design (DDD):

        微服务与DDD原则定义的领域边界保持一致。每个微服务封装了一个特定的领域或业务功能，确保了内聚行为和领域逻辑的封装。

有界上下文（Bounded Contexts）

        微服务在域中定义有界上下文，描绘（delineating）应用不同规则和定义的区域。这确保了复杂领域中关注点的清晰和分离。

主要组件(Key Components of CQRS)

命令服务：（Command Service:）

命令处理程序：(Command Handlers:)

        负责接收、验证和执行改变系统状态的命令。

领域逻辑：(Domain Logic: )

        实现处理命令所需的业务规则和特定于领域的逻辑。

事务行为：(Transactional Behavior):

        确保命令执行的原子性、一致性、隔离性和持久性（ACID属性）。

查询服务（Query Service:）

查询处理（Query Handlers: ）

        查询处理程序：在不修改状态的情况下从系统响应读请求检索数据。

 优化的数据访问：（Optimized Data Access: ）

       利用高效的数据检索机制，如反规范化、缓存或索引，来优化查询性能。

可伸缩性：（Scalability: ）

        独立扩展以有效地处理不同的读工作负载。

Event Bus or Message Broker:

异步通信：（Asynchronous Communication:）

        命令服务和查询服务之间通过事件或消息进行通信。

发布-订阅机制：（Publish-Subscribe Mechanism:）

        允许命令服务发布表示状态变化的事件，查询服务可以订阅这些事件以获得最终的一致性。

解耦：（Decoupling: ）

      支持服务之间的松耦合，提高灵活性和容错性。

数据存储（Data Stores:）

写存储（命令侧）：（Write Store (Command Side):）

        针对处理写操作（如插入、更新和删除）进行了优化。可能使用NoSQL数据库提高可伸缩性和性能。

Read Store（查询端）：（Read Store (Query Side):）

        优化了高效的数据检索。可以使用关系数据库进行复杂的查询，或者为特定的用例使用专门的数据存储。

API Gateway or Service Mesh:

入口点：（Entry Point: ）

        为客户端提供与微服务架构交互的单一入口点。

路由和负载平衡：（Routing and Load Balancing: ）

        将请求路由到适当的命令或查询服务，并在实例之间平衡负载。

安全和身份验证：（Security and Authentication: ）

        执行安全策略、身份验证和授权机制。

优势（Advantages of CQRS）

扩展性（Scalability:）

        独立扩展（Independent Scaling:）命令和查询服务可以根据它们处理的工作负载独立扩展。这允许更好的资源分配和改进的性能，因为每个服务都可以针对其特定的职责进行优化。

性能优化（Performance Optimization:）

        优化的数据访问：（Optimized Data Access: ）命令服务和查询服务可以使用针对各自操作优化的单独数据存储机制。例如，命令服务可能使用NoSQL数据库进行快速写操作，而查询服务可能使用关系数据库进行复杂查询。

        高效的读操作：（Efficient Read Operations: ）查询服务可以对数据进行反规范化，使用缓存策略，或者使用专门的数据存储来优化读操作，提高响应时间。

        

灵活性和可维护性 （Flexibility and Maintainability:）

        关注点分离：（Separation of Concerns: CQRS）CQRS将处理命令（写操作）和处理查询（读操作）的职责分离开来。这种分离使得随着时间的推移更容易理解、维护和发展系统。

        模块化：（Modularity）CQRS体系结构中的每个微服务都封装了特定的业务功能或领域，这使得在不影响整个系统的情况下更容易更新或替换单个服务。

        

改进的性能和响应能力 （Improved Performance and Responsiveness:）

        减少阻塞操作：（Reduced Blocking Operations:）分离读和写操作可以减少争用和阻塞，从而提高响应能力和整体系统性能。

        异步通信：（Asynchronous Communication: CQRS）CQRS通常涉及服务之间的异步通信，这可以通过将命令执行与查询处理分离来提高响应性。

        

挑战（Challenges of CQRS）

提升了复杂性（Increased Complexity:）

       体系结构复杂性：（Architectural Complexity:）实现CQRS引入了额外的体系结构复杂性，包括需要单独的命令和查询路径、事件溯源和最终的一致性机制。

        开发复杂性：（Development Complexity:）为命令和查询服务开发和维护单独的代码库会增加开发开销，特别是对于不熟悉模式的团队。

一致性管理（Consistency Management:）

        最终一致性：（Eventual Consistency: ）维护命令端和查询端之间的最终一致性可能具有挑战性，特别是在具有高并发性和数据复制延迟的分布式系统中。

        同步问题：（Synchronization Issues:）确保由命令传播的数据更新准确地反映在查询结果中，需要仔细的同步机制和对竞争条件的处理。

数据同步：（Data Synchronization:）

        数据复制：（Data Duplication: ）CQRS通常涉及在命令和查询模型之间复制数据，从而增加了存储需求和保持数据同步的复杂性。

        数据完整性：（Data Integrity: ）维护跨多个数据存储的数据完整性并确保它们之间的一致性可能具有挑战性，特别是在系统故障或网络分区期间。

操作开销: （Operational Overhead:）

       
        基础设施管理：（Infrastructure Management:）管理运行独立命令和查询服务所需的基础设施，包括部署、监视和扩展，可能会带来额外的操作开销。

         监视和调试：（Monitoring and Debugging:）调试和监视基于cqrs的微服务架构需要专门的工具和技术来跟踪命令和事件流并诊断一致性问题。