不确定我的问题是否可以解释，但我会尽力在这里进行解释。我目前正在探索和使用微服务架构，以了解其工作原理并了解更多信息。大多数情况下，我了解事情如何工作，API网关在此体系结构中的作用是什么，等等。
所以我还有一个理论问题。例如，假设有2个服务，即。事件（管理可能的事件）和服务票证，管理与特定事件相关的票证（可能有很多票证）。因此，这两个服务确实相互依赖，但是它们有一个独立的数据库，完全隔离且松散耦合，就像在“理想的”微服务环境中一样。
现在想象我要获取事件以及与该事件相关的所有票证，并将其显示在移动应用程序或Web Spa应用程序中或任何其他内容中。在这种情况下，调用多个服务/ URL来获取数据并将其输出到UI完全可以吗？还是有更好的方法来获取和汇总此数据。
从我的不同阅读源中，从另一服务中调用一项服务会增加延迟，使服务彼此依赖，一项服务的未来更改会破坏另一项服务，以此类推，所以这根本不是一个好主意。
很抱歉，如果我重复一个问题并且已经在某个地方提出了这个问题（虽然我找不到），但是我需要早些遇到此问题的人提出意见，并可以以一种更好的方式解释这里的流程
答案 0 :(得分：2)
正在调用多个服务/ URL以获取数据并输出到UI 在这种情况下完全可以吗？还是有更好的方法来获取 并汇总这些数据。
是的，可以从UI调用多个服务，并根据需要在Fronted代码中聚合数据。实际上，在这种情况下，您将调用2 Rest API来从票务微服务和事件微服务获取数据。
另一个选择是您具有一些“视图/读取”优化的微服务，这些服务将聚合来自这两个微服务的数据并用作只读微服务。当然，这涉及一些延迟注意事项和其他事项。例如，如果您有一个要求，例如包含多个模型的视图（类似于非规范化视图），则可以使用此方法，该模型将被大量访问和/或具有一些复杂的过滤器选项。在这种方法中，您将拥有一个第三项微服务，该服务将从您的两个微服务的数据（票证和事件）中汇总。该微服务将针对读取进行优化，如果需要，还可以使用其他存储类型（Document db或类似的存储）。对于您而言，如果您决定执行此操作，则只能对该微服务进行一次API调用，该API将为您提供所有数据。
从另一微服务调用一个微服务。在某些情况下，您无法真正避免这种情况。即使有一些在线资源会告诉您不要这样做，但有时这是不可避免的。对于您的示例，我不推荐这种方法，因为它会产生耦合和不必要的延迟，而其他方法可以避免这种情况。
背景信息：
如果可以从另一个微服务调用一个微服务，可以阅读this主题所在的答案。对于您的特定情况，这不是一个很好的选择，但在某些情况下可能是。因此，请阅读以进行澄清。
摘要：
我曾与系统一起工作过，在那里我们做所有这三件事。这实际上取决于您的业务场景和应用程序的需求。选择哪种方法取决于几个标准，例如：UI的可用性，缩放（如果您对微服务有很高的要求，则可以考虑添加第三个微服务，该服务可以汇总票证和事件微服务的数据） ，域耦合。 对于您的情况，我建议潜在用户建议选项1或选项2（如果您的UI要求很高）。在某些情况下，选项1就足够了，拥有第三种微服务可能会显得过大，但有时这也是一个选择。
答案 1 :(得分：1)
根据我在基于云的服务（主要是Microsoft Azure）中的经验，确实存在一种服务调用另一种服务的延迟，但是可以将其最小化。与用户设备通过碰巧拥有的互联网计划进行呼叫所涉及的未知延迟相比，这尤其如此。
将始终有一个依赖于服务及其定义的接口的使用方客户端，无论是SPA应用程序还是其他服务。因此，在您描述的场景中，必须聚合来自两个服务的有效负载。
基于此，我已经看到通过使用处理客户端请求，聚合n个服务的结果并做出相应响应的服务，可以提高性能。确实确实会导致依赖性，但是随着服务的发展，可以同时激活多个版本的服务，从而允许您在适当的时候贬值旧版本。
我希望有帮助。
答案 2 :(得分：0)
可选建议
您可以在最适合的任何服务中维护读取表（denormalize）。为什么？ -因为CQRS适用于需要的地方，所以CQRS最适合大型和复杂的应用程序。它引入了系统的复杂性，使您获得的利润更少，更头痛。