Answers:
虽然MINA和Netty具有相同的抱负,但它们在实践中却大相径庭,因此您应谨慎考虑选择。我们很幸运,因为我们在MINA方面拥有丰富的经验,并且有时间陪伴Netty。我们特别喜欢更简洁的API和更好的文档。在纸上的表现似乎也更好。更重要的是,我们知道Trustin Lee将随时回答我们遇到的任何问题,他当然做到了。
我们发现Netty的一切变得更容易。期。当我们尝试重新实现与MINA相同的功能时,我们是从头开始的。通过遵循出色的文档和示例,我们最终以更少得多的代码获得了更多的功能。
Netty管道对我们来说更好。它比MINA更为简单,在MINA中,一切都是处理程序,由您决定是处理上游事件,下游事件,还是同时处理更多低级事件。在“重放”解码器中吞噬字节几乎是一种乐趣。能够如此轻松地即时重新配置管道也非常好。
但是Netty的最吸引人的地方是恕我直言,它具有创建“覆盖一个”的管道处理程序的能力。您可能已经在文档中阅读了有关coverage注释的信息,但是从本质上讲,它使您只需一行代码即可获得状态。由于没有混乱,没有会话映射,同步和类似的东西,我们只需要声明常规变量(例如“用户名”)并使用它们即可。
但是后来我们遇到了障碍。我们已经在MINA下拥有一个多协议服务器,其中我们的应用程序协议基于TCP / IP,HTTP和UDP运行。当我们切换到Netty时,我们在几分钟之内就将SSL和HTTPS添加到了列表中!到目前为止,一切都还不错,但是当涉及到UDP时,我们意识到我们已经滑倒了。MINA对我们非常友好,因为我们可以将UDP视为“连接”协议。在Netty下,没有这样的抽象。UDP是无连接的,Netty将其视为无连接。与MINA相比,Netty在更低的级别上暴露了UDP的更多无连接性。在Netty下使用UDP可以做的事情比在MINA提供的更高级抽象下不能做的事情要多,但是我们要依靠它。
添加“连接的UDP”包装器或其他东西并不是那么简单。鉴于时间限制,并且在Trustin的建议下,最好的方法是在Netty中实现我们自己的运输提供商,但这并不是很快,所以我们最终不得不放弃Netty。
因此,仔细研究它们之间的差异,并迅速进入一个阶段,您可以测试任何棘手的功能是否按预期工作。如果您对Netty会做的工作感到满意,那么我会毫不犹豫地选择MINA。如果您要从MINA迁移到Netty,则同样适用,但是值得注意的是,这两个API确实有很大的不同,您应该考虑对Netty进行虚拟重写-您不会后悔的!
MINA具有更多现成的功能,但代价是复杂性和相对较差的性能。这些功能中的某些功能过于紧密地集成到内核中,即使用户不需要它们也无法删除。在Netty中,我试图解决此类设计问题,同时保留了MINA的已知优势。
当前,Netty中还提供了MINA中可用的大多数功能。在我看来,Netty具有更整洁,更文档化的API,因为Netty是尝试从头开始重建MINA并解决已知问题的结果。如果您发现缺少一项重要功能,请随时将您的建议发布到论坛上。我很高兴解决您的问题。
还需要注意的是Netty具有更快的开发周期。只需查看最近发行的发行日期。另外,您应该考虑MINA小组将进行重大改写MINA 3,这意味着他们将完全破坏API的兼容性。
我对2个“ Google Protobuffer RPC”实现进行了性能测试,其中一个基于Netty(netty-protobuf-rpc),另一个基于mina(protobuf-mina-rpc)。Netty最终对于所有消息大小都始终保持更快(+-10%)的性能-这支持了Netty网站上的总体性能要求。由于您想在使用这样的RPC库时从代码中压缩所有效率,因此我最终基于Netty 编写了protobuf-rpc-pro。我过去曾使用过MINA,但发现他们关于2.0的文档存在很大漏洞,并且API向后兼容性的破坏也很大。
我更喜欢Netty。
Twitter还选择了Netty来构建其新的搜索系统,并将其速度加快3倍。
我们选择Netty而不是它的其他一些竞争对手,例如Mina和Jetty,是因为它具有更干净的API,更好的文档,更重要的是,Twitter上的其他一些项目正在使用此框架。
我只用过MINA来构建像服务器这样的小型http。到目前为止,我遇到的最大问题是:
不错的事情: