微服务体系结构中的API调用

我不确定我的问题是否可以解释，但我会尽量在这里解释。我目前正在探索和使用微服务体系结构，以了解其工作原理并了解更多信息。我主要了解事情是如何工作的，API网关在这个体系结构中的角色是什么，等等

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

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

从我阅读的不同资料来看，从另一个服务调用一个服务会增加延迟，使服务相互依赖，一个服务的未来变化会破坏另一个服务，等等，所以这根本不是一个好主意

---

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

在我使用基于云的服务（主要是Microsoft Azure）的经验中，一个服务调用另一个服务的延迟确实存在，但可以认为是最小的。与用户设备通过他们碰巧拥有的互联网计划进行呼叫所涉及的未知延迟相比，这一点尤其正确

无论是SPA应用程序还是其他服务，始终会有依赖于服务及其定义接口的消费客户端。因此，在您描述的场景中，必须对两个服务的有效负载进行聚合

基于此，我看到通过使用一个服务来处理客户端请求、聚合来自n个服务的结果并做出相应响应，从而提高了性能。这确实会导致依赖性，但随着服务的发展，可能会同时激活多个版本的服务，从而允许您在适当的时候降低旧版本的价值

我希望这有帮助

正在调用多个服务/URL以获取数据并输出到UI 在这种情况下完全可以吗？还是有更好的方法来取 并汇总这些数据

是的，可以从UI调用多个服务，并根据需要在前置代码中聚合数据。实际上，在本例中，您将调用2个RESTAPI来从票证微服务和事件微服务获取数据

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

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

背景信息：

如果可以从另一个微服务呼叫一个微服务，您可以阅读主题所在的答案。对于您的特定情况，这不是一个好的选择，但对于某些情况，它可能是。因此，请阅读它以获得一些澄清

摘要：

我曾与系统一起工作，我们在那里做所有这三件事。这实际上取决于您的业务场景和应用程序的需求。选择哪种方法将取决于以下几个标准：UI的可用性、缩放（如果你对微服务有很高的需求，你可以考虑添加第三微服务，它可以从门票和事件微服务中聚合数据）、域耦合。

---

对于您的情况，我会从潜在用户那里建议选项1或选项2（如果您有高要求的UI）。在某些情况下，选项1就足够了，拥有第三个微服务可能会有点过头，但有时这也是一个选项。

可选建议

---

您可以在任何最适合的服务中维护读取表（非规范化）。为什么因为CQR适用于需要的地方，所以CQR最适合于大型和复杂的应用。它在您的系统中引入了复杂性，您获得的利润更少，而且更令人头痛。

很好的解释，我非常喜欢您的方法。然而，我还有一个关于第2号方法的问题。您是否建议新的第三个微服务将充当一个只聚合数据的层？因此，例如，我们可以将其实现为事件驱动（例如，新的第三个微服务将被订阅并侦听事件和票证），并且每当新数据被推送到或更新到事件和票证时，它都可以接收新数据并将其缓存/存储到自己的存储器t中