微服务背后的想法之一是它们是独立的。他们有自己的数据库来存储数据。
例如，假设我们有两个微服务：人MS 和地址MS 。
人MS -保留有关人的信息，例如姓名，年龄，地址ID和e.t.c。
地址MS -保存有关地址的信息，例如：街道，城市，州，邮政编码等
为简单起见，我们假设记录之间的关系是1到1。一个人只能离开一个地址。
在用户界面上，我想显示一个人及其地址的列表，并按城市进行过滤。
由于我只能通过API在MS之间进行通信，因此从城市过滤的地址MS 中查询信息，然后将其用作从人民MS中查询信息的条件，这是一个糟糕的主意。
问题是，对于这种情况，正确的方法是什么？ 这是否意味着这种特定的数据结构不适合微服务范式，而必须一起存储在一个地方？
答案 0 :(得分：1)
这不是创建微服务时在何处画线的好例子，但是它确实谈到了我们在微服务中一次又一次看到的方面。 您拥有跨两个服务的数据，需要在UI上显示它们。 好吧，您需要一些位置来首先聚合数据，而我们通常在BFF层中进行聚合。 UI是直接与之对话并从中获取数据的另一项服务（从UI进行两次（或多次）调用以增强一个视图是不好的）。 对于您所说的聚合，它在一个服务上进行get调用，获取一堆数据，并基于此响应将服务称为两个膨胀数据。 （这是我们通常的处理方式，具有两个SLA的单个服务会在规定的时间做出响应）
现在使用过滤器，我可能不同意从serviceA查询数据并使用响应从serviceB获取更多数据是一个坏主意。 可能会很慢，但还是会达成共识，但这并不坏（因为如果您没有联接的权力，这将是您应该做的）。现在，您需要检查您是否认为它很慢，还是真的很慢。我已经看到，在某些情况下，这样的电话对我来说效果很好。就我的响应而言，UI没有明显的延迟。但是，是的，在某些情况下，您可能需要处理大量数据，或者某些服务可能无法为您提供缓存，或者您可能涉及两个以上的服务，或者只是放置了太多的数据和方式太多字段无法过滤。 在这种情况下，我们通常会在两者之间增加一层，以帮助我们将所有数据收集在一起，并且还允许快速有效的搜索，例如弹性搜索。/
因此，您可以采用多种方式来应对此类情况。但是，您首先需要考虑的是如何将产品划分为服务。如果您做对了，您将最大程度地减少此类情况。遵循其聚集和缓存策略，然后可能是搜索引擎。