Pregunta

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

Enlaces de referencia:

Apache MINA ( fuente )

Netty ( fuente )

¿Fue útil?

Solución

Si bien MINA y Netty tienen ambiciones similares, son bastante diferentes en la práctica y debe considerar cuidadosamente su elección. 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.

El Netty Pipeline funcionó mejor para nosotros. Es de alguna manera más simple que los 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 "volver a 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 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 sobre 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 por el estilo, simplemente pudimos declarar variables regulares (por ejemplo, "nombre de usuario") y usarlas.

Pero luego llegamos a un obstáculo. Ya teníamos un servidor multiprotocolo bajo MINA, en el que 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 en que podíamos tratar UDP como un "conectado". protocolo. 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 " UDP conectado " envoltura 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, 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 esperaba. 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á!

Otros consejos

MINA tiene más funciones listas para usar a costa de la complejidad y un rendimiento relativamente pobre. Algunas de esas características se integraron en el núcleo con demasiada fuerza como para eliminarlas incluso si un usuario no las necesita. En Netty, traté de abordar tales problemas de diseño manteniendo 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é el rendimiento 2 '' Google Protobuffer RPC '' implementaciones donde una estaba basada en Netty (netty-protobuf-rpc) y la otra basada 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. Dado que desea exprimir cada bit de eficiencia de su código cuando utiliza una biblioteca RPC, terminé escribiendo protobuf-rpc-pro basado en Netty. He usado MINA en el pasado, pero su documentación de las cosas 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ñadas y construidas por el mismo autor. Es por eso que son tan similares entre sí. MINA está diseñado en un nivel ligeramente más alto 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 a 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 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 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 usando este marco.

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

  1. Retendrá su " solicitud " y "respuesta" en 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 falla y pierde la conexión es útil para reiniciar el trabajo en otro nodo.
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top