CQRS/ES正确落地实现的两大实操问题咨询

问题1：微服务是否需要额外保留独立本地数据库 #

核心结论 #

绝大多数场景下不需要额外搭建独立本地库，仅少数特殊场景可以按需引入。
事件存储库是整个架构的唯一事实源，配套的只读投影库已经可以覆盖90%以上的微服务查询需求，额外的独立本地库本质属于「私有投影」的特殊形式，没有明确不可替代的需求时不建议引入。

可引入本地库的典型场景 #

• 存储和核心业务逻辑无关的非溯源类数据：比如微服务的内部重试任务快照、接口限流规则、本地缓存过期配置这类不需要纳入事件溯源的运维、配置类数据，存在本地库比写入事件库更加轻量，也不会污染核心事件流。
• 高频场景下的聚合根快照存储：比如每秒数千次请求的交易场景，每次重放事件计算聚合根状态开销过大，可以把最新的聚合根快照存在本地库，不需要每次都从事件库或通用投影库拉取，大幅降低响应延迟。

引入本地库的优劣势 #

• 优势：
  • 读写隔离，降低事件库、通用投影库的访问压力
  • 特殊场景下可降低接口响应延迟30%以上
  • 微服务可自行控制本地数据的存储结构、生命周期，不需要修改通用投影规则，灵活性更高
• 劣势：
  • 新增数据一致性风险：本地库数据如果和事件源不同步，会直接导致业务逻辑错误，需要额外开发同步校验机制
  • 提升运维复杂度：多一个数据源就要配套备份、扩容、监控体系，增加运维成本
  • 破坏单一事实源原则：排查问题时需要多数据源比对，排障成本提升至少一倍

示例场景说明 #

订单、商品微服务如果没有上述特殊需求，完全不需要额外搭建独立的订单本地库、商品本地库，现有事件库+投影库已经足够支撑全量业务。如果确实有高频库存预计算、订单重试任务存储的需求，可以搭建小体量的本地库，仅存储对应场景的数据，绝对不要把核心业务状态（比如订单状态、商品库存）全量存在本地库。 #

问题2：命令下发前的校验数据应该从哪里取 #

核心结论 #

优先从专属只读投影库取数，只有引入了本地库且本地库对应数据可以保证和事件源强一致的前提下，才可以从本地库取数。

逻辑说明 #

命令校验的核心要求是「数据必须和当前事实源的状态尽可能一致」，只读投影库本身就是基于事件源同步生成的，默认保证最终一致，大部分业务场景下的同步延迟在毫秒级，完全可以满足校验需求。如果要使用本地库数据做校验，必须保证本地库的数据更新和事件消费强绑定，每次相关事件消费成功后才更新本地库的对应字段，避免脏数据导致校验错误。

示例场景说明 #

创建订单校验库存的场景中，商品服务的只读投影库已经存储了每个商品的实时库存，直接查询投影库的库存字段即可，不需要走本地库。如果是秒杀这类超高频校验场景，确实需要降低查询延迟，可以把库存快照存在商品服务的本地库，但必须保证每一次库存扣减、库存补充事件消费成功后，才同步更新本地库的库存值，同时加乐观锁避免并发更新问题。 #

通用落地建议 #

• 初期落地CQRS/ES时严格遵守单一事实源原则，只保留事件库和通用只读投影库，不要额外加本地库，跑通核心流程后再根据性能瓶颈、业务需求评估是否需要新增本地存储
• 所有命令的校验逻辑默认走只读投影库，只有压测发现投影库查询延迟满足不了业务要求时，再考虑引入本地缓存或本地库做校验，同时必须配套数据一致性校验的定时任务，定期比对本地数据和投影库、事件源的数据是否一致
• 本地库仅可存储非核心的快照、配置、运维类数据，绝对不要存储核心业务状态，避免出现数据不一致导致的资损问题

内容的提问来源于stack exchange，提问作者chaotic-mr