将异步业务流迁移至事件驱动系统的技术方案问询

问题1：读写服务操作同一数据库还是副本更合理？ #

• 直接用同一主库的合理性：架构简单，不存在数据同步延迟，适合对数据实时性要求高的场景；在CQRS模式下，读写端本就围绕同一业务模型，依赖相同DB schema是合理的，只要schema变更时同步更新两个服务即可。
• 用副本读的优势：能有效分流主库的查询压力，适合高并发查询场景；但要注意副本同步的延迟问题，若业务能接受短暂的数据不一致（比如几秒延迟），再考虑采用副本。
• 决策建议：如果当前查询量不大、数据实时性要求高，优先用同一主库；等后续查询量上升或主库压力过高时，再逐步切换到副本，可配合读写分离中间件实现平滑过渡。

问题2：Core仅写DB vs 事务同时写DB和Kafka，哪个方案更优？ #

• 当前方案（Core写DB，event-complete-handler负责后续）的优缺点：
  • 优点：Core业务逻辑更纯粹，无需耦合Kafka消息发送逻辑，降低了服务复杂度；
  • 缺点：存在一致性风险——若DB写成功但event-complete-handler未正常处理（比如服务挂了、消息丢失），会导致计算结果无法被后续流程消费。
• 事务方案（同时写DB和Kafka）的优缺点：
  • 优点：可通过事务消息保证“计算结果落库”和“触发后续流程”的原子性，一致性更强；
  • 缺点：Core逻辑会耦合消息队列操作，复杂度上升，且需要数据库或中间件支持事务消息（比如Kafka的事务机制）。
• 决策建议：如果业务对一致性要求极高（比如金融场景），优先选事务方案；若能接受短暂不一致，且可通过补偿机制（比如定时扫描DB补发送消息）兜底，当前方案更简洁。另外，无论选哪种方案，event-complete-handler都要实现幂等性，避免重复处理。

问题3：Core能否直接读DB？是否会导致schema依赖？ #

• 可以直接读DB，但确实会产生DB schema依赖——Core和读写服务会绑定同一数据库结构，后续schema变更时需要同步调整多个服务。
• 优化建议：
  • 引入领域模型层：Core依赖抽象的领域模型而非直接依赖DB schema，DB层负责模型与数据库表的映射，schema变更时仅需修改DB适配层，Core逻辑无需改动；
  • 缓存常用数据：把Core计算需要的高频数据缓存到Redis等中间件，Core读缓存而非直接读DB，减少对DB schema的依赖；
  • 事件溯源替代直接读DB：若业务适合，Core可从Kafka事件流中回放历史事件获取计算所需数据，完全解耦DB schema，但这种方式对业务模型设计要求较高。
• 如果是简单业务场景，直接读DB也没问题，只要做好schema变更的同步管理（比如由同一团队维护相关服务，或用schema版本工具跟踪变更）。

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