这是我第一次阅读微服务。知道服务是来自整个系统的细分系统，该系统专门研究不同的领域。那数据怎么样？我假设所有使用传统db的服务存储它们的数据和数据都存储在不同的域中。如果有数据属于这两个域服务怎么办，我该怎么办呢。
E.g。篮子服务（处理用户购物车）和支付服务（处理他们放在篮子里的订单的付款）。
也许这不是一个很好的例子，在哪里存储产品信息。
在单片应用程序中，我们有单个数据库，它存储了每个数据相互引用的整个业务数据。
答案 0 :(得分：0)
通过这些服务，我们倾向于问一个问题是谁是真理的来源？ 在您的情况下，用户将项目添加到购物车，并且有服务可以跟踪用户添加的项目（可能只存储了itemid） 当用于移动结账时，将有一个结账服务，然后向购物车服务询问用户购物车中的商品，应用购物车逻辑。 需要注意的是结账服务知道并关心结账过程，并且不知道从哪里获取物品的数据。它只是调用正确的服务并获得它想要的东西并应用逻辑。 对于结账付款，您可以传递userid cartid和其他信息，付款可以利用这些信息在其认为合适的情况下膨胀信息并将结果返回结账，这可能会触发订单服务。
因此，如果您看到一个服务始终可以获得数据，并且您遇到需要数据的情况，而不是进行数据库调用，则可以进行服务调用 （服务职责是以低延迟为您提供此数据，并可能将逻辑拉入缓存或其他任何方式）
关于数据的另一点是事实的来源。对于经常调用的订单服务，我们倾向于保留与订单相关的所有信息的副本（我们再次这样做，它们可能是更好的方法）并且经常在返回流程问题中这样做以便信任哪个系统。您可以查询订单服务以获取应该发送订单的地址，但该地址可能已被用户删除。
这是单一真理来源发挥作用的地方。这有点棘手，因为送货地址的送货服务来源是从订单服务而不是用户服务获得的（但订单服务在下订单时从用户服务中获取详细信息） 同时，在回流期间，我们认为存储在订单服务中的价格（再次是订购时间内存在的快照）不一定要打电话给产品服务，但是对于付款我们直接与支付服务联系检查我们从用户那里获得的金额（可能有多个向内和向外流动）
所以底线是