Netty 和 Project Loom

Question

我可能错了，但据我了解，整个 Reactive/Event Loop 事物，尤其是 Netty，都是为了解决 Reactive/Event Loop 而发明的strong>C10K+ 问题。它有明显的缺点，因为您的所有代码现在都变成了异步，带有丑陋的回调、无意义的堆栈跟踪，因此难以维护和推理关于。

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

所以问题是：

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

2. 如果我们在 Java 中有 Fibers 和 Continuations，我们是否可以编写好的 Sync 代码和C10K+ 没有 Netty 可以吗？

3. 在生产发布后，在编写 Async 代码和使用 Netty 方面，性能或解决 C10K+ 是否有任何优势织布机？

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

Answer 1

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

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

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