事件监听器与剩余呼叫

Question

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

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

现在大多数应用程序都需要相互通信，并且正如我已经提到的那样，它们是微服务，因此我正在使用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来确定哪种更适合您的情况（或可能两者都适用）。