代码之家 › 专栏 › 技术社区 › Muhammad Usman

事件侦听器与REST调用

architecture javascript-events design-patterns rest performance

Muhammad Usman · 技术社区 · 6 年前

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

我正在开发一种界面,用户可以为所有应用程序拥有一个统一的界面,为此,我正在开发一种信封应用程序,它将在 iframe 在里面。

现在大多数应用程序都需要彼此通信,正如我之前提到的,它们是微服务,所以我使用 rest 他们之间需要沟通。

但我也用过 event listeners 在他们之间共享数据。这也行。但我不太确定使用它会产生什么影响。所以我的问题是,我是否可以像在ifram等内部使用应用程序时一样,正常地使用事件侦听器进行通信?

使用的优点和缺点是什么 rest call 虚拟 events 是吗?

任何帮助都将不胜感激。

谢谢

1 回复 | 直到 6 年前

Wintermute 6 年前

马丁·福勒就是这么称呼的 smart endpoints and dumb pipes .

至于哪一个更好:没有明确的“胜利者”,因为那些不是相互排斥的。它们服务于不同的语义目的(尽管可能提供相同的结果),并且可以在一个应用程序中一起使用。

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

至于优缺点,我可以给你一些陈述,可以帮助你决定何时使用哪种技术:

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

这些只是亮点,这个列表并不是最终的。这两种技术在应用程序中都具有不同的复杂性。这里最好的建议是使用定性陈述(类似上面的那些),常识和亲吻来决定哪个更适合你的情况(或者两者都适合?).