[@倚贤][¥20]微服务

物理上也许不必隔离，但逻辑上一定要隔离，可以多个服务一个库，但是访问的数据资源一定要隔离开，否则A服务能直接操作B服务的数据，是有违微服务的核心概念的

通常情况下，在每个服务都有自己的缓存和数据库，并且缓存和数据库是相互独立且透明的。因此，共享缓存与共享数据库是不对的。那如果服务 A 需要获取服务 B 的数据怎么办？请读者思考，这种情况下，可以直接在服务 A 创建两个数据源（一个是服务 A 的数据库，一个是服务 B 的数据库）进行数据操作么？事实上，这个方案是不提倡的，因为它破坏了微服务之间的数据独立性。因此，更好的做法是：服务 B 提供一个获取该数据的 API 接口，而服务 A 通过调用该接口进行业务组装。但是，凡事无绝对，有一种特殊的场景可能需要共享数据库，那就是旧的服务过度到新的服务的场景，新的服务复用旧的服务的数据库从而到达功能与数据过度的需求。

阅读链接：http://blog.720ui.com/2017/msa_design/

私以为微服务是为了开发方便，比如热部署，容器隔离提出来的想法，不一定非要说完全物理隔离，如果你觉得有公用点，那么放在同一个git仓库下也OK

微服务只是架构思想，并不是所有的依赖的资源全是物理隔离的，逻辑隔离是一个良好的开始。
假设你的微服务A和微服务B由2个团队开发，调用这2个微服务都是面向接口，物理数据库可以共享一个。
如果随着业务的发展，微服务A或B已经不能共享一个库了，可以再迁移出去实现物理隔离。