Netty和Project Loom

我可能是错的,但据我所知,整个反应式/事件循环,特别是Netty,都是为了解决C10K +问题而发明的。它有明显的缺点,因为你所有的代码现在都变成了异步,有丑陋的回调无意义的堆栈跟踪,因此很难维护和推理。

Go的goroutines语言是一种解决方案,现在他们可以编写Sync代码并处理C10K +。所以现在Java出现了Loom,它基本上复制了Go的解决方案,很快我们将拥有FibersContinuaries,并且能够再次编写Sync代码。

所以问题是:

  1. 织布机在生产中发布时,它不会让Netty有点过时吗?

  2. 如果我们在Java中有纤维延续,我们是否可以编写漂亮的同步代码,并在没有Netty的情况下使用C10K +

  3. Loom 正式版发布后,在编写异步代码和使用 Netty 的性能或解决 C10K+ 方面有什么优势吗?

我知道Netty不仅仅是Reactive/Event Loop框架,它还具有各种协议的所有编解码器,无论如何,这些实现都会以某种方式有用,即使在之后也是如此。


答案 1

我专注于Netty的反应部分,因为那些你似乎最想解决的问题是在一般层面上回答:

目前,反应式编程范例通常用于解决性能问题,而不是因为它们适合问题。这些应该通过项目Loom完全覆盖。

但是,在反应式编程方法有意义且比命令式代码更易于阅读的地方,可能会仍然存在一些问题。反应式框架通常是面向流的,非常适合在不同的实体/数据流上组合元素和操作。他们还通过其提供商/订户模型提供直接的本地事件总线解决方案。在这种情况下,反应式模型可能仍然是最佳选择,比命令式方法更高性能且更具可读性。但事实上,由于在母语结构中缺乏更好的支持,项目织布机应该使所有“滥用”过时。


答案 2

推荐