这是一个创建于 1697 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如我订单服务 A，结算服务 B 。B 基于 A，T+1 生成数据，这时候 B 是否可以配置多数据源直接连 A 的数据库抽取数据呢？请各位大佬个建议呢？如果不建议这样做，有什么更好的实现方式呢？
 | 1 crclz 2021-04-07 19:51:27 +08:00 微服务的设计原则是不同微服务之间不共享数据源，只通过明确定义的 HTTP 接口（或类似的接口）进行协作。 破坏这种方式的后果： 坏处： 1a. 带来团队沟通或管理上的混乱 1b. 团队间迭代的节奏被卡住，造成生产力下降。例如，团队 2 的逻辑基于团队 1 数据源中的表结构，一旦团队 1 要变更表结构，会非常麻烦。 好处： 2a. 简化开发，减少短期内的开发时间 2b. 直接访问数据源，性能好 |
 | 2 securityCoding 2021-04-07 19:58:27 +08:00 via Android 这样的话还搞啥微服务，一张宽表聚合了事 |
 | 4 a719114136 2021-04-07 20:05:32 +08:00 如果是初中期的项目可以直连数据源，好处就是方便，不用依赖于其他人开发，能快速上线。 如果是后期的项目，服务的拆分也已经比较细化，这时就让 B 提供接口，这样做数据源 B 发生变化时 B 服务自己维护接口。 ======= 另外，初中后期其实是一个感性的概念，每个人理解都不一样，最直接的就是看团队的人数，人少时别搞那么复杂，否则流程长，维护成本极高不利于快速迭代；人多时必须复杂，可以规避很多 bug |
 | 5 wjv22019 OP @securityCoding 个人认为有时候迫于开发成本，时间之类的考虑，还是需要取舍的 |
| 6 wjv22019 OP @a719114136 好的，谢谢您的建议！ |
 | 7 taowen 2021-04-08 08:31:28 +08:00  1 当你考虑这么干的时候，直连不直连都一样了。A 封个查询 RPC 接口给 B 和直连 A 的数据库是一样的。当你发现需求需要你有耦合了，不调整 A/B 的职责分工，单纯换 RPC 方式是换汤不换药的 |
 | 8 xuanbg 2021-04-08 08:43:44 +08:00 微服务中多个服务可以用同一个数据源，但仅限于同一领域下的服务，譬如拆分应用 /管理服务。楼主这种订单和结算是两个业务领域了，没必要也不应该用同一个数据源。 |
 | 9 abcbuzhiming 2021-04-08 11:50:23 +08:00 你 B 越过 A 直接操作 A 业务范围内的数据，那 A 的存在意义在哪里？ |
 | 10 ychost 2021-04-09 17:46:26 +08:00 建议 A 包一下提供 API 来做吧，不然台混乱了 |
Select Language