微服务架构中Worker Service数据访问与职责划分相关问题咨询

优先选择调用面向用户的微服务接口获取数据，不建议直接共享数据库访问，核心原因如下：

• 符合微服务边界自治的核心原则：共享数据库会直接打破两个组件的职责边界，后续如果面向用户的微服务需要调整表结构、增加数据校验规则、接入缓存层，直连数据库的Worker需要同步修改所有对应逻辑，极容易出现数据不一致、逻辑遗漏的问题。
• 避免逻辑重复实现：待发送任务的状态过滤、权限校验、数据组装逻辑只需要在面向用户的微服务中实现一次，Worker直接调用接口即可，不需要重复开发相同逻辑，后期维护成本更低。
• 只有两种特殊场景可考虑直连数据库：一是Worker与面向用户的微服务属于同一业务域下的内部绑定组件，不会独立迭代；二是接口调用的性能无法满足发信吞吐量要求，这种情况需要提前约定数据库schema的变更规则，禁止Worker随意修改数据库数据。

该方案不符合单一职责原则，除非是极小体量的临时项目，否则不建议采用，核心弊端如下：

• 影响发信任务稳定性：API接口需要频繁迭代用户需求、调整权限逻辑、新增业务参数，而发信Worker的核心要求是运行稳定、尽量减少发布次数，两者耦合在同一个服务中时，每次API迭代的发布都会打断正在运行的发信任务，增加故障概率。
• 容易出现资源争抢：API接口属于应对突发用户请求的CPU/网络密集型负载，发信Worker属于持续运行的IO密集型负载，两者共享进程资源时，突发的用户请求很容易占满CPU、内存、网络资源，导致发信任务延迟甚至失败。
• 后续扩展成本更高：当发信量上涨需要单独扩容Worker节点时，需要连带扩容无状态的API服务，造成资源浪费；反之当API请求量上涨需要扩容时，也会额外启动大量不需要的发信进程，提升部署成本。

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