我很好奇听到人们的意见。随着软件开发向微服务策略发展的趋势，这是否还要求/暗示/建议您还应该为每个微服务隔离专用数据库？
我听说有人提到微服务只是从代码的分离/隔离一直到完全隔离基础结构。从数据角度看，如果您拥有一堆服务，这些服务最终都将拥有一些User数据，但可能只有一小部分关于用户的数据，这似乎会给主数据管理带来麻烦。因此，您最终将梳理多个系统以获取用户的完整图片，然后会出现以下问题：当数据不同步时，哪些数据是规范的，例如用户的email address。
我很好奇听到人们在微服务之旅中的经历
答案 0 :(得分：0)
它只是说，无论服务在做什么，都应该从外部服务中抽象出来。您所暴露的只是您的合同，这是某人可以带来服务状态任何更改的唯一方法。 使用Monolith，我们倾向于共享数据库，即我们曾经进行直接数据库调用。 这种方法的问题在于，现在没有一个模块可以控制数据库内部的运行。您所做的任何更改都需要与数据库进行交互的每个人的支持。
为了带来这种灵活性，我们选择从其他数据库中抽象数据库。 现在关于聚合数据，如果我在整体中设置了类似的限制并取消了连接，我相信您将能够满足数据需求。 就是这样。
总应该有一个真理来源。如果谈论用户数据，它应该是一项服务。现在，这取决于您如何构造它。 我们说用户联系方式电子邮件人口统计信息由用户服务负责。订单带有订单服务。 （我选择说用户订单驻留在订单服务中），并从给定用户的订单服务中汇总。 订单服务依次（通过userId）保持对用户的引用，这是获取订单的唯一方法（即，只有用户ID可以作为属性来过滤用户的订单）
答案 1 :(得分：0)
微服务意味着小型独立规模的服务。一种服务的更改不应影响其他服务。没有什么是免费的，微服务也是如此。为了获得独立的服务，我们也倾向于使用单独的数据库。没错，这是以数据管理为代价的，但这是我们称之为独立微服务的唯一方式。
为什么要分离数据库？
并非所有服务都可能适合单个数据模型。一种服务可能与关系数据库很好地匹配，而另一种服务则更适合没有sql的情况。我们分离数据库，有时分离数据模型，因此我们可以独立扩展它们。想象有一个数据库，所有服务都试图访问它。如果共享数据库出现故障，所有服务将停止工作。但是，如果您对单个数据库有单独的影响，则不会影响其他数据库。
分散的数据？
由于您在微服务中提到过，数据可能分散在各个服务之间。通常，单个服务拥有主副本，而其他服务可能具有数据的子集或引用。例如在用户数据的情况下，用户服务拥有有关用户的所有信息，但所有其他服务可能都有参考（用户电子邮件ID等）。我认为只有在使服务独立的情况下，数据子集才应该存在。例如预订服务可以包含订单状态（运输，提货，交付），但实际图片仍保留在订单数据库中。如果订单服务中断，您仍然有当前订单 预订微服务的状态，这使预订服务完全独立。
如何合并分散的数据？
没有正确的答案，这实际上取决于您如何分离数据。将数据放在不同的服务中并加入它们可能会很昂贵，而且如果一项服务失败，则您的加入可能不会带来所有数据。为了解决这个问题，您需要使用不同服务中的数据子集，或者您可以使用事件处理和CQRS等更高级的模式来构建读取模型。由于微服务通常使用事件来传递数据，因此您可以使用相同的事件来构建读取模型。
答案 2 :(得分：0)
服务应具有自己的数据库-主要原因是自治。这既是他们以最小程度地依赖于其他服务的可用性进行操作的能力，又是他们独立发展的能力。 （请注意，出于实际原因，部署架构可以在同一实例上共同托管多个服务的数据库）
在上一段中，我使用了术语服务而不是微服务，因为它不一定适用于微服务-如果服务足够小，只要几个微服务共享相同的数据库，它们仍然有意义单一逻辑服务。如果服务太小而仍具有单独的服务，则它们很容易变成“ nanoservices”（开销大于其实用程序的服务）。我通常会在services and aspects之间进行区分，其中方面是同一服务的较小的半独立部分。例如，在我构建的一个系统中，我们在node.js中实现了一个方面，该方面实现了GraphQL API来查询由Scala后端更新的数据库-两个方面共享一个数据库，但具有足够不同的要求和足够的路线图以保证独立开发和不同的技术。
关于收集和汇总数据-我通常采用一种称为“ aggregated reporting”的模式，这种想法是服务是其自身数据的所有者/主数据，但是它们可以发出不可变（版本化）的副本。将其数据存储到其他服务或负责报告的数据集市中。请注意，在某些情况下，查询多个服务并在客户端或at a backend gateway
聚合（联接）仍然有意义