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