Java 生态下想搞大流量下的 ws,是不是暂时只能 netty?

最近项目想上直播和拍卖业务,自身流量也是比较大,想问下目前业界 ws 方案下是不是更推荐 netty 或者有没有其他可以参考的方案呢?

直播推流这快准备用阿里云的,直播上会用到 ws 的也就是评论,拍卖可能就是出价和评论。

1. 使用 Netty 的建议

• sagaxu：不要直接用 Netty，建议使用 Vert.x 或者 Quarkus。
• wxw752：我们公司使用 Netty 处理 WebSocket，直播推流用阿里云，并找云服务商做备份。
• Goooooos：Vert.x 底层就是 Netty。
• ZZ74：老老实实用 Netty，大流量+响应式编程可能会出问题。

2. 虚拟线程与响应式编程

• cheng6563：用 Java 21 虚拟线程同步处理，不要考虑响应式或异步编程。
• ychost：虚拟线程更好，响应式编程复杂度太高。
• Karte：
  • 虚拟线程的出现是为了减少 IO 操作，非 IO 操作使用虚拟线程会增加负担。
  • 虚拟线程通过用户态上下文切换减少内核态切换，但会占用内存，可能导致 OOM。
  • JDK-21-LTS 的虚拟线程存在 synchronized 问题，会将虚拟线程 PIN 到平台线程。
  • Netflix 团队在使用虚拟线程时遇到死锁问题。
• ychost：JDK24 修复了 synchronized 问题。
• 5261：JDK21 的用户可能是小白鼠。
• Gress：JDK24 修复了 synchronized 问题。
• anyele：synchronized 问题已修复（JEP 491）。
• siweipancc：虚拟线程的发布文档提到同步关键字还未适配。
• ebony0319：
  • 虚拟线程是 JDK8 后的里程碑产品，适合高并发场景。
  • 在实际使用中，虚拟线程显著提升了性能。
  • 提供了生产环境中的 CPU 和内存使用情况截图。
• Karte：
  • 在 JDK-21-LTS 中，建议在贴近 IO 的部分使用虚拟线程。
  • 在 JDK-24 中，synchronized 问题已修复，但仍需注意虚拟线程数量。
  • 建议等待下一个 LTS 版本。

3. Java 版本的选择

• ZeroDu：不要用 Java8，至少用 Java17。
• 5261：企业用 Java 要的是稳定，升级 JDK 不是想升就能升。
• qinxi：Java8 过期这么久都不升级的企业，换其他语言也不一定能更好。

4. 其他框架与语言

• halov：可以看看 t-io，但评价不高。
• SunDShuai9797：t-io 的 issues 都关了，怎么用？
• aboutier：Java Netty 没有替代品。
• NizumaEiji：建议使用 Spring -> MQ -> Node.js/Go 的架构。
• conn457567：不要用响应式编程，虚拟线程还不成熟，建议用 Go 或 Node.js。

5. 服务器成本与开发成本

• x537196：服务器成本是最低成本，人员和维护成本才是最高的。
• 5261：Java 对于中小企业是一种负担，用 Go 可以减少服务器成本。

6. 其他讨论

• 5261：Reactor Netty 和 Vert.x 有什么区别？
• ebony0319：提供了生产环境中的 CPU 和内存使用情况截图。

总结

• Netty：仍然是稳健的选择，尤其是大流量场景。
• 虚拟线程：JDK21 存在 synchronized 问题，JDK24 已修复，适合 IO 密集型场景，但需谨慎使用。
• Java 版本：建议至少使用 Java17，企业升级需考虑稳定性。
• 其他框架与语言：Vert.x、Quarkus、Go、Node.js 等也是可选方案，但需根据具体场景选择。
• 成本：服务器成本较低，人员和维护成本较高，选择技术栈时需综合考虑。