Netty vs Apache MINA

Question

Ambos proporcionan más o menos la misma funcionalidad. ¿Cuál debería elegir para desarrollar mi servidor TCP de alto rendimiento? ¿Cuáles son los pros & cons?

Enlaces de referencia:

Apache MINA (source)

Netty (source)

Answer 1

Mientras que MINA y Netty tienen ambiciones similares, son bastante diferentes en la práctica y debe considerar su elección cuidadosamente. Tuvimos suerte porque tuvimos mucha experiencia con MINA y tuvimos tiempo para jugar con Netty. Nos gustó especialmente la API más limpia y una documentación mucho mejor. El rendimiento parecía mejor en el papel también. Más importante aún, sabíamos que Trustin Lee estaría a su disposición para responder cualquier pregunta que tuviéramos, y ciertamente lo hizo.

Encontramos todo más fácil en Netty. Período. Mientras intentábamos volver a implementar la misma funcionalidad que ya teníamos en MINA, lo hicimos desde cero. Al seguir la excelente documentación y ejemplos, terminamos con más funcionalidades en mucho, mucho menos código.

The Netty Pipeline funcionó mejor para nosotros. Es de alguna manera más simple que las MINA, donde todo es un controlador y depende de usted decidir si se manejan los eventos río arriba, los posteriores o ambos, o si se consumen más cosas de bajo nivel. Engullir bytes en "reproducir" decodificadores fue casi un placer. También fue muy agradable poder reconfigurar la tubería sobre la marcha tan fácilmente.

Pero la atracción principal de Netty, imho, es la capacidad de crear controladores de tuberías con una "cobertura de uno". Probablemente ya haya leído acerca de esta anotación de cobertura en la documentación, pero básicamente le proporciona el estado en una sola línea de código. Sin problemas, sin mapas de sesión, sincronización y cosas así, simplemente pudimos declarar variables regulares (por ejemplo, "nombre de usuario") y usarlas.

Pero luego llegamos a una barricada. Ya teníamos un servidor multiprotocolo bajo MINA, en el cual nuestro protocolo de aplicación funcionaba a través de TCP/IP, HTTP y UDP. Cuando cambiamos a Netty, agregamos SSL y HTTPS a la lista en cuestión de minutos. Hasta ahora todo bien, pero cuando se trataba de UDP nos dimos cuenta de que habíamos caído. MINA fue muy amable con nosotros en que pudimos tratar UDP como un protocolo "conectado". Bajo Netty no hay tal abstracción. UDP no tiene conexión y Netty lo trata como tal. Netty expone más de la naturaleza sin conexión de UDP en un nivel más bajo que MINA. Hay cosas que puede hacer con UDP en Netty de lo que no puede hacerlo en la abstracción de nivel superior que proporciona MINA, pero en las que confiamos.

No es tan simple agregar un contenedor "UDP conectado" o algo así. Dadas las limitaciones de tiempo y el consejo de Trustin de que la mejor manera de proceder era implementar nuestro propio proveedor de transporte en Netty, lo que no sería rápido, al final tuvimos que abandonar Netty.

Por lo tanto, fíjese bien en las diferencias entre ellos y llegue rápidamente a una etapa en la que puede probar que cualquier funcionalidad complicada está funcionando como se esperaba. Si está satisfecho de que Netty hará el trabajo, no dudaría en seguir con MINA. Si te estás moviendo de MINA a Netty, aplica lo mismo, pero vale la pena señalar que las dos API realmente son significativamente diferentes y debes considerar una reescritura virtual para Netty: ¡no te arrepentirás!

Answer 2

En Netty sitio se puede encontrar algo de rendimiento reports. Como se esperaba :-) señalan a Netty como el marco con el mejor rendimiento.

Nunca utilicé Netty, pero ya utilicé MINA para implementar un protocolo TCP. La implementación de codificación y decodificación fue fácil, pero la implementación de la máquina de estado no fue tan fácil. MINA proporciona algunas clases para ayudarlo cuando implementa la máquina de estado, pero me pareció un poco difícil de usar. Al final, decidimos deshacernos de MINA e implementar el protocolo desde cero, y sorprendentemente terminamos con un servidor más rápido.

Answer 3

Solo he usado MINA para construir un pequeño servidor tipo http. Los mayores problemas que he encontrado hasta ahora:

1. Mantendrá su "solicitud" y "respuesta" en la memoria. Esto es solo un problema porque el protocolo que elijo usar es http. Sin embargo, puede usar su propio protocolo para evitar esto.
2. No existe la opción de proporcionar un flujo de disco en caso de que desee entregar archivos de gran tamaño. Una vez más se puede evitar mediante la aplicación de su propio protocolo

cosas agradable sobre él:

1. puede manejar una gran cantidad de conexiones
2. Si decide implementar algún tipo de sistema de trabajo distribuido entonces saber cuándo uno de sus nodos se cae y pierde conexión es útil para reiniciar el trabajo en otro nodo.

Answer 4

MINA y Netty fueron inicialmente diseñadas y compiladas por el mismo autor. Es por eso que son muy similares el uno al otro. MINA está diseñado en un nivel ligeramente más alto con un poco más de características, mientras que Netty es un poco más rápido. Creo que no hay mucha diferencia en absoluto, los conceptos básicos son los mismos.

Answer 5

MINA tiene más funciones listas para usar a costa de la complejidad y un rendimiento relativamente bajo. Algunas de esas características se integraron en el núcleo con demasiada fuerza como para eliminarlas incluso si el usuario no las necesita. En Netty, traté de abordar estos problemas de diseño sin perder los puntos fuertes conocidos de MINA.

Actualmente, la mayoría de las características disponibles en MINA también están disponibles en Netty. En mi opinión, Netty tiene una API más limpia y documentada, ya que Netty es el resultado de intentar reconstruir MINA desde cero y resolver los problemas conocidos. Si encuentra que falta una característica esencial, no dude en publicar su sugerencia en el foro. Estaría encantado de dirigir su preocupación.

También es importante tener en cuenta que Netty tiene un ciclo de desarrollo más rápido. Simplemente, revisa la fecha de lanzamiento de los lanzamientos recientes. Además, debe considerar que el equipo MINA procederá a una reescritura importante, MINA 3, lo que significa que romperá la compatibilidad API por completo.

Answer 6

El rendimiento probó 2 implementaciones "Google Protobuffer RPC" donde una se basaba en Netty (netty-protobuf-rpc) y la otra en mina (protobuf-mina-rpc). Netty terminó siendo consistentemente más rápido (+ - 10%) para todos los tamaños de mensaje, lo que respalda el reclamo de rendimiento general en el sitio web de Netty. Dado que desea extraer todo el rendimiento del código cuando usa una biblioteca RPC de este tipo, terminé escribiendo protobuf-rpc-pro basado en Netty. He utilizado MINA en el pasado, pero encuentro que su documentación del material 2.0 tiene grandes agujeros, y la ruptura de la compatibilidad con versiones anteriores de API es un gran inconveniente.

Answer 7

Prefiero Netty.

Twitter también eligió Netty para construir su nuevo sistema de búsqueda y lo aceleró hasta 3 veces más rápido.

Ref: Twitter Search is Now 3x Faster

Elegimos Netty sobre algunos de sus otros competidores, como Mina y embarcadero, porque tiene un API limpio, mejor documentación y, más importante aún, debido a que varios otros proyectos en Twitter están utilizando este marco.