Netty 与 Apache MINA
它们都提供大致相同的功能.我应该选择哪一个来开发我的高性能 TCP 服务器?有什么优点&缺点?
They both provide roughly the same functionality. Which one should I choose to develop my high-performance TCP server? What are the pros & cons?
参考链接:
Apache MINA (来源)
Netty (来源)
推荐答案
虽然 MINA 和 Netty 有相似的抱负，但在实践中却大不相同，你应该仔细考虑你的选择.我们很幸运，因为我们对 MINA 有很多经验，并且有时间和 Netty 一起玩.我们特别喜欢更简洁的 API 和更好的文档.纸面上的表现似乎也更好.更重要的是，我们知道 Trustin Lee 会随时回答我们的任何问题，而且他确实做到了.
While MINA and Netty have similar ambitions, they are quite different in practice and you should consider your choice carefully. We were lucky in that we had lots of experience with MINA and had the time to play around with Netty. We especially liked the cleaner API and much better documentation. Performance seemed better on paper too. More importantly we knew that Trustin Lee would be on hand to answer any questions we had, and he certainly did that.
我们发现在 Netty 中一切都变得更简单了.时期.当我们试图重新实现我们已经在 MINA 上拥有的相同功能时，我们是从头开始的.通过遵循优秀的文档和示例，我们最终以少得多的代码获得了更多的功能.
We found everything easier in Netty. Period. While we were trying to reimplement the same functionality we already had on MINA, we did so from scratch. By following the excellent documentation and examples we ended up with more functionality in much, much less code.
Netty 管道对我们来说效果更好.它比 MINA 更简单，在 MINA 中，一切都是处理程序，由您决定是处理上游事件、下游事件，还是同时处理更多低级事件.在重放"解码器中吞噬字节几乎是一种享受.能够如此轻松地即时重新配置管道也非常棒.
The Netty Pipeline worked better for us. It is somehow simpler than MINAs, where everything is a handler and it is up to you to decide whether to handle upstream events, downstream events, both or consume more low-level stuff. Gobbling bytes in "replaying" decoders was almost a pleasure. It was also very nice to be able to reconfigure the pipeline on-the-fly so easily.
但是，恕我直言，Netty 的明星吸引力在于能够创建具有覆盖率"的管道处理程序.您可能已经在文档中阅读过有关此覆盖率注释的内容，但本质上它在一行代码中为您提供了状态.没有搞乱，没有会话映射，同步和类似的东西，我们可以简单地声明常规变量(比如，用户名")并使用它们.
But the star attraction of Netty, imho, is the ability to create pipeline handlers with a "coverage of one". You've probably read about this coverage annotation already in the documentation, but essentially it gives you state in a single line of code. With no messing around, no session maps, synchronization and stuff like that, we were simply able to declare regular variables (say, "username") and use them.
但后来我们遇到了障碍.我们在 MINA 下已经有一个多协议服务器，我们的应用程序协议运行在 TCP/IP、HTTP 和 UDP 上.当我们切换到 Netty 时，我们在几分钟内就将 SSL 和 HTTPS 添加到了列表中！到目前为止一切都很好，但是当涉及到 UDP 时，我们意识到我们已经滑倒了.MINA 对我们非常好，因为我们可以将 UDP 视为连接"协议.在 Netty 下没有这样的抽象.UDP 是无连接的，Netty 将其视为无连接的.Netty 在比 MINA 更低的级别上暴露了更多 UDP 的无连接特性.在 Netty 下，您可以使用 UDP 做一些事情，而在 MINA 提供的更高级别的抽象下，您却无法做到，但我们依赖于它.
But then we hit a roadblock. We already had a multi-protocol server under MINA, in which our application protocol ran over TCP/IP, HTTP and UDP. When we switched to Netty we added SSL and HTTPS to the list in a matter of minutes! So far so good, but when it came to UDP we realised that we had slipped up. MINA was very nice to us in that we could treat UDP as a "connected" protocol. Under Netty there is no such abstraction. UDP is connectionless and Netty treats it as such. Netty exposes more of the connectionless nature of UDP at a lower level than MINA does. There are things you can do with UDP under Netty than you can't under the higher-level abstraction that MINA provides, but on which we relied.
添加连接的UDP"包装器或其他东西并不是那么简单.考虑到时间限制和 Trustin 的建议，最好的方法是在 Netty 中实现我们自己的传输提供程序，这不会很快，我们最终不得不放弃 Netty.
It is not so simple to add a "connected UDP" wrapper or something. Given time constraints and on Trustin's advice that the best way to proceed was to implement our own transport provider in Netty, which would not be quick, we had to abandon Netty in the end.
因此，请仔细研究它们之间的差异，然后快速进入可以测试任何棘手功能是否按预期工作的阶段.如果您对 Netty 能够完成这项工作感到满意，那么我会毫不犹豫地选择 MINA.如果您要从 MINA 迁移到 Netty，则同样适用，但值得注意的是，这两个 API 确实存在显着差异，您应该考虑对 Netty 进行虚拟重写——您不会后悔的！
So, look hard at the differences between them and quickly get to a stage where you can test any tricky functionality is working as expected. If you're satisfied that Netty will do the job, then I wouldn't hesitate to go with it over MINA. If you're moving from MINA to Netty then the same applies, but it is worth noting that the two APIs really are significantly different and you should consider a virtual rewrite for Netty - you won't regret it!
相关文章