事件监听器与休息调用

Question

我有多个应用程序/微服务。

我正在开发一种界面，用户可以在其中为所有应用程序提供一个统一的界面，为此我正在开发一种信封应用程序，它将在其内部以iframe 显示所有其他应用程序。

现在大多数应用程序都需要相互通信，正如我已经提到的，它们是微服务，所以我使用rest 调用它们之间的通信。

但我也使用event listeners 在它们之间共享数据。这也很好用。但我不太确定使用它会产生什么影响。所以我的问题是，当我们在 ifram 等中有应用程序时，我通常可以像往常一样使用事件侦听器进行通信吗？

使用 rest call 与 events 的优缺点是什么？

任何帮助将不胜感激。

Answer 1

这就是 Martin Fowler 所说的 smart endpoints and dumb pipes。

至于哪个更好：没有明确的“赢家”，因为它们并不相互排斥。它们服务于不同的语义目的（尽管可能提供相同的结果）并且可以在一个应用程序中一起使用。

您唯一需要记住的是，事件模型本质上是异步的，您应该以这种方式对待它。当然，您可以提出一些 SLA 以使消息传递看起来是同步的，或者在前端创建类似同步的效果，但仍然如此。

至于利弊，我可以给你几句话来帮助你决定何时使用哪种技术：

• 耦合 - 比较反应式事件驱动模型和普通 API，您可以说 API 为您提供了更紧密的耦合，因为您必须遵循一些预定义的接口。消息在这方面并没有那么严格，但如果需要，可以这样做
• 扩展 - 事件驱动模型更容易扩展：创建更多的工作人员，你就完成了。但是，这种无状态性可能会成为一个问题 - 您可能需要同一个工作人员来处理特定事件，这可能会导致非常困难的排队架构
• 错误处理 - 在 REST API 中实现错误处理可以像抛出适当的错误一样简单并用它来完成。但是，如果您需要重试对外部服务的失败请求怎么办？它应该在 API 后端完成还是必须在客户端完成？如果您需要为每个请求使用不同类型的重试逻辑怎么办？您的 API 可能变得过于智能，这通常是一件坏事
• 阻塞与非阻塞 - 如果您的服务未达到预期的 SLA，您是否有应急计划？阻塞也可能是个问题，但至少你可以控制流程并监控执行过程
• 弹性 - 如果您的 API 在执行过程中崩溃，您可能会丢失有价值的数据。排队让您可以等到工作人员再次可用

这些只是亮点，这个列表无论如何都不是最终的。这两种技术都需要在您的应用程序中带来不同的复杂性。这里最好的提示是使用定性陈述（有点像上面的那些）、常识和 KISS 来决定哪个更适合你的情况（或者两者都适合？）。