微服务设计上是否可以多数据源？有悖于微服务设计原则吗？

[wjv22019]

比如我订单服务 A，结算服务 B 。B 基于 A，T+1 生成数据，这时候 B 是否可以配置多数据源直接连 A 的数据库抽取数据呢？请各位大佬个建议呢？如果不建议这样做，有什么更好的实现方式呢？

[crclz]

微服务的设计原则是不同微服务之间不共享数据源，只通过明确定义的 HTTP 接口（或类似的接口）进行协作。

破坏这种方式的后果：

坏处：
1a. 带来团队沟通或管理上的混乱
1b. 团队间迭代的节奏被卡住，造成生产力下降。例如，团队 2 的逻辑基于团队 1 数据源中的表结构，一旦团队 1 要变更表结构，会非常麻烦。

好处：
2a. 简化开发，减少短期内的开发时间
2b. 直接访问数据源，性能好

[securityCoding]

这样的话还搞啥微服务，一张宽表聚合了事😂

[wjv22019]

@crclz 谢谢！

[a719114136]

如果是初中期的项目可以直连数据源，好处就是方便，不用依赖于其他人开发，能快速上线。

如果是后期的项目，服务的拆分也已经比较细化，这时就让 B 提供接口，这样做数据源 B 发生变化时 B 服务自己维护接口。

=======

另外，初中后期其实是一个感性的概念，每个人理解都不一样，最直接的就是看团队的人数，人少时别搞那么复杂，否则流程长，维护成本极高不利于快速迭代；人多时必须复杂，可以规避很多 bug

[wjv22019]

@securityCoding 个人认为有时候迫于开发成本，时间之类的考虑，还是需要取舍的

[wjv22019]

@a719114136 好的，谢谢您的建议！

[taowen]

当你考虑这么干的时候，直连不直连都一样了。A 封个查询 RPC 接口给 B 和直连 A 的数据库是一样的。当你发现需求需要你有耦合了，不调整 A/B 的职责分工，单纯换 RPC 方式是换汤不换药的

[xuanbg]

微服务中多个服务可以用同一个数据源，但仅限于同一领域下的服务，譬如拆分应用 /管理服务。楼主这种订单和结算是两个业务领域了，没必要也不应该用同一个数据源。

[abcbuzhiming]

你 B 越过 A 直接操作 A 业务范围内的数据，那 A 的存在意义在哪里？

[ychost]

建议 A 包一下提供 API 来做吧，不然台混乱了