Apache MINA vs Netty

Ambos fornecem aproximadamente a mesma funcionalidade. Qual deles devo escolher para desenvolver meu servidor TCP de alto desempenho? Quais são os prós e os contras?

Links de referência:

Apache MINA ( origem )

Netty ( fonte )

Embora MINA e Netty tenham ambições semelhantes, na prática são bastante diferentes e você deve considerar sua escolha com cuidado. Tivemos sorte porque tínhamos muita experiência com o MINA e tivemos tempo para brincar com Netty. Gostamos especialmente da API mais limpa e de uma documentação muito melhor. O desempenho também parecia melhor no papel. Mais importante, sabíamos que Trustin Lee estaria à disposição para responder a quaisquer perguntas que tivéssemos, e ele certamente fez isso.

Encontramos tudo mais fácil no Netty. Período. Enquanto estávamos tentando reimplementar a mesma funcionalidade que já tínhamos no MINA, fizemos isso do zero. Seguindo a excelente documentação e exemplos, acabamos com mais funcionalidade em muito, muito menos código.

O Netty Pipeline funcionou melhor para nós. De alguma forma, é mais simples do que as MINAs, onde tudo é um manipulador e você decide se deve lidar com eventos upstream, downstream, ambos ou com mais coisas de baixo nível. Devorar bytes em "repetir" decodificadores foi quase um prazer. Também foi muito bom poder reconfigurar o pipeline on-the-fly tão facilmente.

Mas a atração principal de Netty, imho, é a capacidade de criar manipuladores de pipeline com uma "cobertura de um". Você provavelmente já leu sobre esta anotação de cobertura na documentação, mas essencialmente ela fornece um estado em uma única linha de código. Sem mexer, mapas de sessão, sincronização e coisas assim, simplesmente pudemos declarar variáveis ​​regulares (por exemplo, "nome de usuário") e usá-las.

Mas então chegamos a um obstáculo. Já tínhamos um servidor multiprotocolo sob o MINA, no qual nosso protocolo de aplicação era executado em TCP / IP, HTTP e UDP. Quando mudamos para o Netty, adicionamos SSL e HTTPS à lista em questão de minutos! Até agora tudo bem, mas quando se tratava de UDP, percebemos que havíamos escorregado. O MINA foi muito legal conosco, pois poderíamos tratar o UDP como um protocolo "conectado". Sob Netty, não existe essa abstração. O UDP não tem conexão e o Netty o trata como tal. O Netty expõe mais a natureza sem conexão do UDP em um nível mais baixo do que o MINA. Há coisas que você pode fazer com o UDP no Netty do que na abstração de nível superior que o MINA fornece, mas nas quais confiamos.

Não é tão simples adicionar um wrapper "UDP conectado" ou algo assim. Dadas as restrições de tempo e os conselhos de Trustin de que a melhor maneira de proceder era implementar nosso próprio provedor de transporte em Netty, o que não seria rápido, tivemos que abandonar Netty no final.

Portanto, observe bem as diferenças entre elas e chegue rapidamente a um estágio em que você pode testar qualquer funcionalidade complicada que esteja funcionando conforme o esperado. Se você está convencido de que Netty fará o trabalho, não hesitaria em segui-lo pela MINA. Se você estiver mudando de MINA para Netty, o mesmo se aplica, mas vale a pena notar que as duas APIs são realmente significativamente diferentes e você deve considerar uma reescrita virtual para o Netty - você não vai se arrepender!

O MINA possui mais recursos prontos para uso, com custo de complexidade e desempenho relativamente baixo. Alguns desses recursos foram integrados ao núcleo com muita força para serem removidos, mesmo que não sejam necessários ao usuário. No Netty, tentei resolver esses problemas de design, mantendo os pontos fortes conhecidos do MINA.

Atualmente, a maioria dos recursos disponíveis no MINA também está disponível no Netty. Na minha opinião, o Netty possui uma API mais limpa e mais documentada, pois o Netty é o resultado de tentar reconstruir o MINA do zero e solucionar os problemas conhecidos. Se você achar que um recurso essencial está ausente, sinta-se à vontade para postar sua sugestão no fórum. Ficaria feliz em responder à sua preocupação.

Também é importante observar que o Netty tem um ciclo de desenvolvimento mais rápido. Simplesmente, verifique a data de lançamento dos lançamentos recentes. Além disso, você deve considerar que a equipe do MINA procederá a uma grande reescrita, o MINA 3, o que significa que eles quebrarão completamente a compatibilidade da API.

Testei o desempenho de duas implementações "Google Protobuffer RPC", uma baseada no Netty (netty-protobuf-rpc) e a outra na mina (protobuf-mina-rpc). O Netty acabou sendo consistentemente mais rápido (+ - 10%) para todos os tamanhos de mensagem - o que faz o backup da reivindicação de desempenho geral no site do Netty. Como você deseja extrair toda a eficiência do seu código ao usar essa biblioteca RPC, acabei escrevendo protobuf-rpc-pro com base no Netty. Eu usei o MINA no passado, mas acho que a documentação deles do material 2.0 tem grandes falhas, e a quebra da compatibilidade com versões anteriores da API é muito grande.

MINA e Netty foram inicialmente projetados e construídos pelo mesmo autor. É por isso que eles são tão parecidos entre si. O MINA foi projetado em um nível um pouco mais alto, com um pouco mais de recursos, enquanto o Netty é um pouco mais rápido. Eu acho que não há muita diferença, os conceitos básicos são os mesmos.

No site Netty, você pode encontrar alguns relatórios de desempenho . Como esperado :-) eles apontam o Netty como o framework com o melhor desempenho.

Eu nunca usei o Netty, mas já usei o MINA para implementar um protocolo TCP. A implementação da codificação e decodificação foi fácil, mas a implementação da máquina de estado não foi tão fácil. O MINA fornece algumas classes para ajudá-lo na implementação da máquina de estado, mas eu as achei meio difíceis de usar. No final, decidimos abandonar o MINA e implementar o protocolo a partir do zero e, surpreendentemente, terminamos com um servidor mais rápido.

Eu prefiro Netty.

O Twitter também escolheu a Netty para construir seu novo Sistema de Pesquisa e acelerou-o até 3x mais rápido.

Ref: Pesquisa no Twitter é agora 3x mais rápida

Escolhemos a Netty em detrimento de outros concorrentes, como Mina e Jetty, porque ela possui uma API mais limpa, melhor documentação e, mais importante, porque vários outros projetos no Twitter estão usando essa estrutura.

Eu só usei o MINA para criar um servidor http pequeno. Os maiores problemas com que me deparei até agora:

1. Ele manterá sua "solicitação" e "resposta" na memória. Esse é apenas um problema, porque o protocolo que escolho usar é http. Você pode usar seu próprio protocolo, no entanto, para contornar isso.
2. Nenhuma opção para fornecer um fluxo fora do disco, caso você queira exibir arquivos grandes. Mais uma vez, pode ser contornado implementando seu próprio protocolo

Coisas legais sobre isso:

1. Pode lidar com muitas conexões
2. Se você optar por implementar algum tipo de sistema de trabalho distribuído, saber quando um de nossos nós será desativado e perderá a conexão será útil para reiniciar o trabalho em outro nó.