微服务：数据库如何组织在微服务之后

作者: 一瓶泡沫
发布时间: 2024-01-25 06:00:38 (6月前)
转自：

2 条回复

0#
回复此人
老人与海。 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 有了这些服务，我们倾向于问一个问题是谁是真理的来源？在您的情况下，用户将项目添加到购物车，并且有服务可以跟踪用户添加的项目（可能只存储了itemid）当用于移动结账时，将有一个结账服务，然后向购物车服务询问用户购物车中的商品，应用购物车逻辑。需要注意的是结账服务知道并关心结账过程，并且不知道从哪里获取物品的数据。它只是调用正确的服务并获得它想要的东西并应用逻辑。对于结账付款，您可以传递userid cartid和其他信息，付款可以利用这些信息在其认为合适的情况下膨胀信息并将结果返回结账，这可能会触发订单服务。 因此，如果您看到一个服务始终可以获得数据，并且您遇到需要数据的情况，而不是进行数据库调用，则可以进行服务调用（服务职责是以低延迟为您提供此数据，并可能将逻辑拉入缓存或其他任何方面） 关于数据的另一点是真实的来源。对于经常调用的订单服务，我们倾向于保留与订单相关的所有信息的副本（我们再次这样做，它们可能是更好的方法）并且经常在返回流程问题中这样做以便信任哪个系统。您可以查询订单服务以获取应该发送订单的地址，但该地址可能已被用户删除。 这就是单一真理来源发挥作用的地方。这有点棘手，因为送货地址的送货服务来源是从订单服务而不是用户服务获得的（但订单服务在下订单时从用户服务中获取详细信息）同时，在回流期间，我们认为存储在订单服务中的价格（再次是订购时间内存在的快照）不一定会打电话给产品服务，但是对于付款，我们直接与付款服务联系检查我们从用户那里取得的金额（可能有多个向内和向外流动） 所以底线是 <UL> <LI> 通过一个服务公开一个数据库，并让其他服务通过此服务连接到数据库 </LI> <LI> 阅读更多关于单一真理来源的信息。我们决定某些合同，例如谁是SSOT谁（我不一定同意这种方法，但它适用于我们） </LI> </UL> </DIV>

编辑

登录后才能参与评论