微服务架构中的API调用

Question

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

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

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

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

如果我重复一个问题并且它已经在某个地方被问过（尽管我找不到它），我很抱歉，但我需要之前遇到这个问题的人提供意见，并且可以以更好的方式解释这里的流程。

Answer 1

在这种情况下，调用多个服务/URL 来获取数据并输出到 UI 完全可以吗？或者是否有更好的方法来获取和聚合这些数据。

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

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

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

背景资料：

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

概括：

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