微服务架构：应采用独立数据库还是共享数据库？技术求解

核心结论：微服务架构的最佳实践是为每个服务配置独立数据库，共享数据库从根本上违背了微服务的设计初衷，会带来一系列难以解决的问题。

为什么不建议用共享数据库 #

• 强耦合陷阱：多个服务直接操作同一张表，任何一方修改表结构、字段规则，都会牵连其他服务，完全失去了微服务解耦的意义，最后会退化成一个披着微服务外衣的单体应用。
• 维护成本飙升：排查数据问题时，你根本没法快速定位是哪个服务修改了数据；并发场景下的锁竞争、事务冲突会被放大，调试和优化难度直线上升。
• 技术选型受限：所有服务必须绑定同一个数据库类型，比如你想给某个服务换成MongoDB处理非结构化数据，共享数据库的情况下根本做不到，完全限制了服务的独立演进。

独立数据库下，服务间数据怎么管理 #

1. 直接调用服务API #

这是最常规的方式：如果服务A需要服务B的数据，直接调用B提供的公开API接口。比如订单服务要获取用户的收货地址，就调用用户服务的/api/users/{id}/address接口。

• 注意点：做好接口版本管理（比如/api/v2/users/{id}），避免接口变更影响依赖方；同时要处理好调用超时、重试、降级等异常情况，防止单个服务故障引发连锁反应。

2. 事件驱动的数据同步 #

当某个服务的数据发生变更时，发布一个事件到消息队列（比如Kafka、RabbitMQ），其他需要该数据的服务订阅这个事件，更新自己本地的缓存或副本数据。

• 举个例子：用户服务更新了用户的手机号，就发布UserPhoneUpdated事件，订单服务订阅后，把自己存储的用户联系方式副本更新掉，后续查询订单时就不用再调用用户服务了。
• 优势：彻底解耦服务间的依赖，不用强依赖其他服务的API，同时保证数据的最终一致性。

3. 只读副本/视图（临时过渡方案） #

如果是一些基础的、极少变更的公共数据（比如系统字典表），可以给其他服务提供只读的数据库副本或者视图，但绝对禁止写操作。

• 注意：这只能作为临时过渡手段，长期来看还是要通过API或事件驱动来规范数据交互，不然很容易又滑向共享数据库的泥潭。

4. 明确领域边界从根源减少数据依赖 #

在设计微服务初期，先做好领域建模，把每个服务的职责边界划清楚。比如用户服务只负责用户的核心身份数据，订单服务只负责订单的创建、流转数据，不要让订单服务存储用户的详细信息，只存用户ID就行，需要时再通过API获取。

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