【问题讨论】：
标签： java network-programming apache-mina netty
虽然 MINA 和 Netty 有着相似的抱负，但它们在实践中却大不相同，您应该仔细考虑您的选择。我们很幸运，因为我们对 MINA 有很多经验，并且有时间和 Netty 一起玩。我们特别喜欢更简洁的 API 和更好的文档。纸面上的表现似乎也更好。更重要的是，我们知道 Trustin Lee 会随时回答我们的任何问题，而且他确实做到了。
我们发现在 Netty 中一切都变得更简单了。时期。当我们试图重新实现我们已经在 MINA 上拥有的相同功能时，我们是从头开始的。通过遵循优秀的文档和示例，我们最终以更少的代码获得了更多的功能。
Netty 管道对我们来说效果更好。它比 MINA 更简单，在 MINA 中，一切都是处理程序，由您决定是处理上游事件、下游事件，还是同时处理更多低级事件。在“重放”解码器中吞噬字节几乎是一种乐趣。能够如此轻松地即时重新配置管道也非常棒。
但是，恕我直言，Netty 的明星吸引力在于能够创建具有“覆盖范围”的管道处理程序。您可能已经在文档中阅读过此覆盖注释，但本质上它在一行代码中为您提供了状态。没有搞乱，没有会话映射，同步和类似的东西，我们可以简单地声明常规变量（比如，“用户名”）并使用它们。
但后来我们遇到了障碍。我们在 MINA 下已经有一个多协议服务器，我们的应用程序协议运行在 TCP/IP、HTTP 和 UDP 上。当我们切换到 Netty 时，我们在几分钟内就将 SSL 和 HTTPS 添加到了列表中！到目前为止一切都很好，但是当谈到 UDP 时，我们意识到我们已经滑倒了。 MINA 对我们非常好，因为我们可以将 UDP 视为“连接”协议。在 Netty 下没有这样的抽象。 UDP 是无连接的，Netty 将其视为无连接的。 Netty 在比 MINA 更低的级别上暴露了更多 UDP 的无连接特性。在 Netty 下，您可以使用 UDP 做一些事情，而在 MINA 提供的更高级别的抽象下，您却无法做到，但我们依赖于它。
添加“连接的UDP”包装器或其他东西并不是那么简单。考虑到时间限制和 Trustin 的建议，最好的方法是在 Netty 中实现我们自己的传输提供程序，这不会很快，我们最终不得不放弃 Netty。
因此，请仔细研究它们之间的差异，然后快速进入可以测试任何棘手功能是否按预期工作的阶段。如果您对 Netty 能够完成这项工作感到满意，那么我会毫不犹豫地选择 MINA。如果您要从 MINA 迁移到 Netty，则同样适用，但值得注意的是，这两个 API 确实存在显着差异，您应该考虑对 Netty 进行虚拟重写 - 您不会后悔的！
【讨论】：
更新：只需使用Netty。它现在是一个成熟的项目，具有构建协议客户端和服务器所需的所有功能。它拥有强大的社区，有几个由企业支持的积极贡献者。它还有一本书，“Netty in Action”。已经是adopted by many many well-known companies and projects了。与 Netty 不同，Apache MINA 在我离开项目后一直处于维护模式。
MINA 具有更多开箱即用的功能，但代价是复杂性和相对较差的性能。其中一些功能被集成到核心中太紧密，即使用户不需要它们也无法删除。在 Netty 中，我尝试解决此类设计问题，同时保留 MINA 的已知优势。
目前，MINA 中可用的大多数功能在 Netty 中也可用。在我看来，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 向后兼容性的破坏是一个很大的缺点。
【讨论】：
MINA 和 Netty 最初是由同一作者设计和构建的。这就是为什么他们彼此如此相似。 MINA 的设计水平稍高一些，功能也更多一些，而 Netty 的速度要快一些。 我觉得没有太大区别，基本概念都是一样的。
【讨论】：
在 Netty 站点中，您可以找到一些性能 reports。正如预期的那样 :-) 他们指出 Netty 是性能最好的框架。
我从未使用过 Netty，但我已经使用 MINA 实现了一个 TCP 协议。编码和解码的实现很容易，但状态机的实现就没那么容易了。 MINA 提供了一些类来帮助您实现状态机，但我发现它们很难使用。最后我们决定放弃 MINA 并从头开始实现协议，令人惊讶的是，我们以更快的服务器结束了。
【讨论】：
我使用 Netty。
Twitter 还选择了 Netty 来构建其新的搜索系统，并将其速度提高了 3 倍。
参考：Twitter Search is Now 3x Faster
我们选择 Netty 而不是其他一些竞争对手，例如 Mina 和 Jetty，因为它有更简洁的 API、更好的文档，更重要的是，因为 Twitter 的其他几个项目都在使用这个框架。
【讨论】：
我只使用过 MINA 来构建一个小型 http 之类的服务器。到目前为止我遇到的最大问题：
关于它的好东西：
【讨论】：