如何跨多个微服务或模块化单体模块实现查询端(read side)？

你列的三个方案刚好对应DDD和微服务架构中跨上下文查询的三类标准实现模式，不存在通吃所有场景的唯一最佳实践，选择的核心依据是业务对 一致性、查询延迟、研发运维成本 三个核心指标的优先级要求。

三类方案的适用场景&优劣势 #

1. 客户端自行聚合模式 #

• 适用场景：
  • 前端视图本身就是分模块独立渲染，不同模块的数据归属不同限界上下文，无需跨模块关联计算
  • 允许不同模块的数据存在更新时间差，一致性要求低
  • 下游各服务接口可用性高，并发量不大
• 优劣势：
  优势是服务端无额外开发量，迭代速度最快，没有额外运维成本
  劣势是客户端逻辑冗余，需要处理多接口的重试、降级逻辑，网络开销大，不适合对第三方开放统一接口的场景

2. 服务端API聚合层模式 #

• 适用场景：
  • 需要对客户端屏蔽后端限界上下文的拆分逻辑，提供统一的查询接口
  • 对数据实时性要求极高，必须返回最新的业务数据
  • 聚合逻辑简单，关联的数据量小，不需要复杂的多表join、统计计算
• 优劣势：
  优势是对客户端友好，聚合逻辑可复用，无需处理数据同步问题，天然保证数据一致性
  劣势是响应延迟等于多个下游接口的延迟叠加，高并发场景下容易出现级联故障，聚合逻辑复杂后维护成本极高

3. 物化视图预生成模式 #

• 适用场景：
  • 查询逻辑复杂，需要跨多个上下文做多表关联、分组统计、大数据量计算
  • 并发查询量高，对响应延迟要求苛刻
  • 业务允许一定的同步延迟（延迟时长取决于同步机制，从毫秒级到分钟级均可配置）
• 优劣势：
  优势是查询性能极高，聚合逻辑一次计算多次复用，不会给下游业务服务带来额外的查询压力
  劣势是需要处理数据同步的一致性问题，额外的存储、同步组件运维成本高，数据模型变更时需要做全量数据同步，迭代成本更高

通用决策逻辑 #

行业内的通用选择优先级可以参考如下：

1. 优先判断业务允许的最大数据延迟：要求强一致的直接排除物化视图方案，只能在前两类中选择；允许最终一致的优先评估物化视图方案的可行性
2. 其次看查询的性能要求：QPS过千、响应要求在百毫秒内、且聚合逻辑复杂的场景，优先选物化视图方案
3. 最后看研发运维的成本承受能力：小团队、业务处于快速迭代阶段、数据模型还不稳定的，优先选前两类轻量方案，等业务稳定后再考虑切换到物化视图方案

绝大多数公司的生产实践中都是三类模式混合使用，面向C端的高并发公开查询用物化视图，内部后台管理类查询用API聚合或客户端聚合即可。

内容的提问来源于stack exchange，提问作者tlt