微服务的好处与弊端_《微服务架构设计模式》-学习总结07

本篇主要总结第七章：在微服务架构中实现查询

在微服务架构中查询数据的挑战
何时以及如何使用API组合模式实现查询
何时以及如何使用CQRS模式实现查询

微服务架构中，查询通常需要检索分散在多个服务所拥有的数据库中的数据，跨服务数据查询的两种模式：

API组合模式
- 简单，应尽可能使用
CQRS：命令查询职责隔离模式
- 强大但复杂
- 维护一个或多个视图数据库

API组合模式

API组合模式：由API组合器和两个或多个服务提供方组成，API组合器通过查询每个服务的API并组合结果，实现从多个服务检索数据的查询。

API组合器：调用数据提供方API并组合查询结果
数据提供方服务

API组合模式需要解决的两个设计问题：

由谁来担任API组合器的角色
- 客户端
- API Gateway
- API组合器独立为服务
如何编写有效的聚合逻辑
- 尽可能并行查询，使用响应式编程模型

API组合模式的好处和弊端

好处
- 简单
弊端
- 增加了额外的开销
  - 将一个查询变成了N个查询
- 带来可用性降低的风险
  - 依赖于每个服务提供方都可用，总体可用性是各服务提供方可用性的乘积。
  - 需要专门的策略来提高可用性
    - 缓存数据
    - 返回不完整数据
- 缺乏事务数据一致性
  - 查询操作可能返回不一致的数据

CQRS模式（命令查询职责隔离）

CQRS模式：使用事件来维护从多个服务复制数据的只读视图，借此实现对来自多个服务的数据的查询。它将持久化数据模型和使用数据的模块分为命令端和查询端，他们拥有各自的独立数据库。

命令端
- 增、删和改操作CUD
- 不需要join，仅基于主键的查询操作
- 发布领域事件
查询端
- 查询操作R
- 数据库视图
- 订阅并处理领域事件并更新数据库

CQRS模式的好处和弊端

好处
- 在微服务架构中高效地实现查询
- 高效地实现多种不同的查询类型
- 在基于事件溯源技术的应用程序中实现查询
- 更进一步地实现问题隔离
弊端
- 更加复杂的架构
- 处理数据复制导致的延迟
  - 在命令端发布事件和在查询端处理事件并更新视图之间存在延迟。
    - 命令端和查询端API提供数据的版本信息，使其能够判断查询端是否过时，查询API调用端可以轮询查询直到获得最新版本的数据。

设计CQRS视图

CQRS视图模型包括视图数据库和三个子模块：

查询API
事件处理程序
数据访问模块
视图数据库

设计CQRS视图需要考虑：

选择视图数据库
设计数据库访问模块
- 并发处理：乐观锁
- 幂等事件处理程序
添加和更新CQRS视图
使用归档事件构建CQRS视图
- 增量式构建CQRS视图
  - 快照+后续事件

学习总结

本章主要讲跨服务查询的问题。主要是两个解决方案：

第一，使用一个API查询组合器，分别调用各个服务提供的API查询数据，再将结果组合起来。第二，使用CQRS，设计单独的命令端和查询端，命令端通过事件通知查询端更新数据视图，需要跨服查询时直接查数据视图。

在项目的初期或者在比较简单查询的情况下，可以多使用API查询组合器。在项目后期或者对于一些较复杂的查询，需要使用CQRS。