如果所有服务共享相同的数据库表，那么您不太可能从microservices体系结构中获益。这是因为您有效地紧密耦合了服务。如果数据库表发生更改，则所有服务都必须更改。
您必须明白，microservices体系结构的全部原因是为了减少开发团队之间的依赖性，并允许他们独立地进行快速发布。
以下是亚马逊首席技术官沃纳•沃格斯（werner vogels）的一句话（亚马逊开创了许多微服务风格的架构）：
对于我们来说，面向服务意味着用对数据进行操作的业务逻辑封装数据，只有通过已发布的服务接口才能进行访问。不允许从服务外部直接访问数据库，服务之间也没有数据共享。
有关更多信息，请阅读此和此。

一般来说，微服务应该负责自己的数据。这是一个完美的世界场景。
在实践中，有些服务可能彼此高度相关。e、 g.customershippingdetails和customershoppingcheckout服务都可以访问相同的数据-客户地址。然后，您将如何解决向客户结账服务提供客户地址的问题。如果checkout服务直接查询购物细节，那么您就打破了服务之间的松散耦合。另一种选择是引入共享数据库。
在架构上总要有某种妥协。神圣的是一个高度依赖于全局（整个系统的设计）的体系结构决策。
没有太多关于你的系统的细节，我会采取混合的方法。也就是说，为处理类似业务逻辑的服务提供共享数据库。因此customershippingdetails和customershoppingcheckout可以共享一个数据库。但是storeitemsdetails会有一个单独的数据库。
您可以在microservicearchitecture上找到有关microservices共享数据库模式的更多信息。