13

我可能是错的，但据我了解，整个反应/事件循环的东西，尤其是Netty ，是为了解决C10K+问题而发明的。它有明显的缺点，因为您的所有代码现在都变成了Async，带有丑陋的回调，无意义的堆栈跟踪，因此难以维护和推理。

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

所以问题是：

  1. 当Loom在生产中发布时，它不会让Netty有点过时吗？

  2. 如果我们在Java中有Fibers和Continuations，我们可以编写漂亮的Sync代码并且可以在没有Netty的情况下使用C10K+吗？

  3. 在Loom生产发布后，在编写Async代码和使用Netty方面，性能或解决C10K+有什么优势吗？

我知道Netty不仅仅是响应式/事件循环框架，它还具有各种协议的所有编解码器，无论如何，这些实现无论如何都会有用，即使是在之后。

4

1 回答 1

2

我专注于 Netty 的反应部分，因为您似乎最想在一般层面上解决答案：

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

但是，在反应式编程方法有意义并且比命令式代码更易于阅读的地方可能仍然存在一些问题。反应式框架通常是面向流的，非常适合在不同的实体/数据流上组合元素和操作。他们还通过他们的提供者/订阅者模型提供直接的本地事件总线解决方案。在这种情况下，响应式模型可能仍然是最好的选择，它比命令式方法更高效、更易读。但事实上，由于缺乏对本地语言结构的更好支持，project loom 应该使所有“误用”过时。

于 2020-05-20T09:40:24.557 回答