Netty vs Apache MINA

Ambos proporcionan aproximadamente la misma funcionalidad. ¿Cuál debo elegir para desarrollar mi servidor TCP de alto rendimiento? ¿Cuáles son los pros y los contras?

Enlaces de referencia:

Apache MINA ( fuente )

Netty ( fuente )

Si bien MINA y Netty tienen ambiciones similares, son bastante diferentes en la práctica y debe considerar su elección cuidadosamente. Tuvimos suerte porque teníamos 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 también parecía mejor en el papel. Más importante aún, sabíamos que Trustin Lee estaría disponible para responder cualquier pregunta que tuviéramos, y ciertamente lo hizo.

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

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 manejar eventos ascendentes, eventos descendentes, ambos o consumir más cosas de bajo nivel. Engullir bytes en decodificadores de "reproducción" fue casi un placer. También fue muy agradable poder reconfigurar la tubería sobre la marcha tan fácilmente.

Pero la atracción estrella de Netty, en mi opinión, es la capacidad de crear manejadores 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 esencialmente le da el estado en una sola línea de código. Sin perder el tiempo, sin mapas de sesión, sincronización y cosas así, simplemente pudimos declarar variables regulares (por ejemplo, "nombre de usuario") y usarlas.

Pero luego nos topamos con un obstáculo. Ya teníamos un servidor multiprotocolo bajo MINA, en el cual nuestro protocolo de aplicación se ejecutaba sobre 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 fallado. MINA fue muy amable con nosotros porque podíamos 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 que no puede hacer con la abstracción de nivel superior que proporciona MINA, pero en la 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, tuvimos que abandonar Netty al final.

Por lo tanto, observe detenidamente las diferencias entre ellos y llegue rápidamente a una etapa en la que pueda probar que cualquier funcionalidad difícil funciona como se espera. Si está satisfecho de que Netty hará el trabajo, no dudaría en hacerlo con MINA. Si se está mudando de MINA a Netty, se aplica lo mismo, pero vale la pena señalar que las dos API realmente son significativamente diferentes y debe considerar una reescritura virtual para Netty, ¡no se arrepentirá!

MINA tiene más funciones listas para usar a costa de la complejidad y un rendimiento relativamente pobre. Algunas de esas funciones se integraron en el núcleo con demasiada fuerza para eliminarlas, incluso si un usuario no las necesita. En Netty, traté de abordar tales problemas de diseño mientras mantenía las fortalezas conocidas de MINA.

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

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

Probé 2 implementaciones de "Google Protobuffer RPC" donde una se basaba en Netty (netty-protobuf-rpc) y la otra en mina (protobuf-mina-rpc). Netty terminó siendo constantemente más rápido (+ - 10%) para todos los tamaños de mensajes, lo que respalda el reclamo de rendimiento general en el sitio web de Netty. Como desea exprimir cada bit de eficiencia de su código cuando usa una biblioteca RPC de este tipo, terminé escribiendo protobuf-rpc-pro basado en Netty. He usado MINA en el pasado, pero 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.

MINA y Netty fueron inicialmente diseñados y construidos por el mismo autor. Es por eso que son tan similares entre sí. MINA está diseñado en un nivel ligeramente superior con un poco más de funciones, mientras que Netty es un poco más rápido. Creo que no hay mucha diferencia, los conceptos básicos son los mismos.

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

Nunca usé Netty, pero ya usé MINA para implementar un protocolo TCP. La implementación de la codificación y la decodificación fue fácil, pero la implementación de la máquina de estado no fue tan fácil. MINA ofrece algunas clases para ayudarlo a implementar 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.

Prefiero Netty

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

Ref: La búsqueda de Twitter ahora es 3 veces más rápida

Elegimos Netty sobre algunos de sus otros competidores, como Mina y Jetty, porque tiene una API más limpia, mejor documentación y, lo que es más importante, porque varios otros proyectos en Twitter están utilizando este marco.

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

1. Retendrá su "solicitud" y "respuesta" en la memoria. Esto es solo un problema porque el protocolo que elijo usar es http. Sin embargo, podría usar su propio protocolo para evitar esto.
2. No hay opción para proporcionar una transmisión fuera del disco en caso de que desee servir archivos grandes. Una vez más se puede solucionar implementando su propio protocolo

Cosas buenas al respecto:

1. Puede manejar muchas conexiones
2. Si elige implementar algún tipo de sistema de trabajo distribuido, saber cuándo uno de sus nodos se cae y pierde la conexión es útil para reiniciar el trabajo en otro nodo.