微服务间通用数据共享方案咨询：单体拆分遇共享数据表困境

我之前在做单体转微服务的项目时，也碰到过几乎一模一样的棘手问题——那些被多个服务交叉依赖的共享数据表，没法拆成领域专属视图，一开始也想过用共享内核的只读Schema凑活，但确实如你所说，这方案长期来看隐患不小，容易让服务间又变回隐形耦合。结合实际项目经验，给你几个经过验证的通用思路，你可以根据业务场景选：

1. 领域服务+事件驱动的发布-订阅模式 #

这是DDD领域驱动设计里最推荐的解耦方案，核心是把共享数据的所有权收归到一个独立的领域服务，其他服务通过API或事件来获取/同步数据：

• 具体做法：比如你有个被订单、支付、用户服务同时依赖的user_basic表，就单独搭建一个user-core-service，所有对用户基础信息的读写操作都必须通过这个服务的接口完成。如果其他服务需要高频读取这些数据，就在自己的数据库里建一个本地缓存表（比如订单服务的user_order_view），当user-core-service的数据发生变更时，发布一个UserBasicUpdated事件，订阅该事件的服务收到后自动更新自己的本地视图。
• 适用场景：数据变更频率中等，对数据一致性要求较高，但读请求量很大的场景。
• 优缺点：彻底解耦服务间的数据库依赖，每个服务只维护自己需要的数据视图；但初期需要开发事件队列（比如Kafka、RabbitMQ）和同步逻辑，对团队的事件驱动开发能力有一定要求。

2. 联邦数据库的隔离只读视图 #

如果暂时不想做事件驱动的改造，可以用联邦数据库模式，在数据库层面实现跨服务的数据访问，但严格限制权限和访问范围：

• 具体做法：以MySQL为例，利用FEDERATED引擎或者分布式数据库中间件搭建联邦查询，让需要共享数据的服务只能通过只读视图访问其他服务的数据库，而且视图只暴露该服务需要的字段。比如订单服务只能访问用户服务数据库里user_basic表的user_id、nickname字段，完全看不到其他敏感或无关数据。同时在代码层面封装查询逻辑，避免直接写跨库SQL。
• 适用场景：短期过渡阶段，或者数据关联逻辑特别复杂、暂时无法拆分的场景。
• 优缺点：初期迁移成本低，不用大幅修改业务代码；但依赖数据库的联邦能力，跨库查询可能存在性能瓶颈，长期来看还是有一定的耦合风险。

3. 数据库复制+专属隔离视图 #

利用数据库的原生复制机制，把共享数据复制到每个需要的服务数据库中，同时为每个服务创建专属的隔离视图：

• 具体做法：比如共享的product_catalog表，用MySQL主从复制或者PostgreSQL逻辑复制，把数据同步到订单、库存等服务的从库中，然后给每个服务创建只包含其所需字段和数据行的视图——比如订单服务的视图只保留product_id、price、status字段，并且过滤掉已下架的商品。服务只需要读取自己库中的视图，完全不需要访问其他服务的数据库。
• 适用场景：对数据实时性要求不高（允许几秒到几分钟的延迟），读请求量极大的场景。
• 优缺点：每个服务读自己的数据库，性能最优；但数据存在一定延迟，需要维护复制规则和视图，适合数据变更不频繁的基础数据场景。

关于共享内核的补充建议 #

其实共享内核不是完全不能用，但一定要严格限定使用范围：只用于那些几乎不会变更的静态基础数据（比如字典表、地区编码表、行业分类表），并且必须设置严格的只读权限，绝对禁止任何服务直接写入这个共享Schema。如果是会频繁变更的业务数据，还是优先考虑前面的方案，避免后期出现“改一个字段要改N个服务”的维护噩梦。

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