微服务架构中的 API 调用

Question

不确定我的问题是否足够解释，但我会尽量在这里解释它。我目前正在探索和使用微服务架构，以了解它是如何工作的并了解更多信息。大多数情况下，我了解事情是如何工作的，API 网关在这个架构中的作用是什么等等......

所以我还有一个理论问题。例如，假设有 2 个服务，即。 event(管理可能的事件)和管理与特定事件相关的票证的服务票证(可能有很多票证)。所以这 2 个服务确实相互依赖，但它们有一个单独的数据库，完全隔离且松散耦合，就像在“理想”微服务环境中一样。

现在想象一下，我想获取事件以及与该事件相关的所有门票，并将其显示在移动应用程序或 Web 水疗应用程序或其他任何应用程序中。在这种情况下，调用多个服务/URL 来获取数据并输出到 UI 是否完全可以？或者有没有更好的方法来获取和聚合这些数据。

根据我阅读的不同来源，从另一项服务调用一项服务会增加延迟，使服务相互依赖，一项服务的 future 更改将破坏另一项服务，等等，所以这根本不是一个好主意。

如果我重复一个问题并且已经有人问过这个问题(虽然我找不到)，我很抱歉，但我需要早先遇到这个问题的人的意见，并且可以更好地解释这里的流程。

Answer 1

Is calling multiple services / URLs to fetch data and output to UI completely okay in this scenario? Or is there a better way to fetch and aggregate this data.

是的，可以从您的 UI 调用多个服务并根据您的需要在您的前端代码中聚合数据。实际上，在这种情况下，您将调用 2 个 Rest API 从票证微服务和事件微服务中获取数据。

另一种选择是你有一些 View /读取优化的微服务，它可以聚合来自两个微服务的数据并作为只读微服务。这当然涉及一些延迟考虑和其他事情。例如，如果您有像 View 这样的需求，该 View 由多个模型(类似于非规范化 View )组成，这些模型将被大量访问和/或具有一些复杂的过滤器选项，则可以使用这种方法。在这种方法中，您将拥有第三个微服务，它将从您的 2 个微服务(票证和事件)的数据中聚合。这个微服务将针对读取进行优化，如果需要，也可以使用不同的存储类型(文档数据库或类似的)。对于您的情况，如果您决定这样做，您只能对该微服务进行一次 API 调用，该服务将为您提供所有数据。

从另一个调用一个微服务。在某些情况下，您无法真正避免这种情况。尽管网上有一些消息来源会告诉您不要这样做，但有时这是不可避免的。对于您的示例，我不会推荐这种方法，因为它会产生耦合和不必要的延迟，而这可以通过其他方法来避免。

背景信息:

您可以阅读 this回答主题是关于是否可以从另一个微服务调用一个微服务。对于您的特定情况，这不是一个好的选择，但在某些情况下可能是。所以请阅读它以获得一些澄清。

摘要:

我曾与系统一起工作，我们在那里做所有这三件事。这实际上取决于您的业务场景和应用程序的需求。选择哪种方法取决于几个标准，例如:UI 的可用性、扩展性(如果您对微服务有很高的需求，您可以考虑添加第三个微服务，它可以聚合来自门票和事件微服务的数据) , 域耦合。
对于您的情况，我会从用户的角度建议选项 1 或选项 2(如果您的 UI 要求很高)。在某些情况下，选项 1 就足够了，并且拥有第三个微服务将是一种矫枉过正，但有时这也是一种选择。