Netty vs Apache MINA
Ils fournissent à peu près les mêmes fonctionnalités. Lequel dois-je choisir pour développer mon serveur TCP haute performance? Quels sont les avantages et les inconvénients?
Liens de Référence:
7 réponses
Alors que MINA et Netty ont des ambitions similaires, ils sont très différents dans la pratique et vous devriez considérer votre choix avec soin. Nous avons eu de la chance en ce sens que nous avions beaucoup d'expérience avec MINA et avons eu le temps de jouer avec Netty. Nous avons particulièrement aimé L'API cleaner et une bien meilleure documentation. La Performance semblait meilleure sur le papier aussi. Plus important encore, nous savions que Trustin Lee serait sur place pour répondre à toutes les questions que nous avions, et il l'a certainement fait.
On a tout trouvé plus facile à Netty. Période. Alors que nous essayions de réimplémenter la même fonctionnalité que nous avions déjà sur MINA, nous l'avons fait à partir de zéro. En suivant l'excellente documentation et les exemples, nous avons fini avec plus de fonctionnalités dans beaucoup, beaucoup moins de code.
Le Pipeline Netty a mieux fonctionné pour nous. C'est en quelque sorte plus simple que MINAs, où tout est un gestionnaire et c'est à vous de décider de gérer les événements en amont, les événements en aval, les deux ou de consommer plus de choses de bas niveau. Gober octets dans les décodeurs" rejouer " était presque un plaisir. Il était également très agréable de pouvoir reconfigurer le pipeline à la volée si facilement.
Mais L'attraction principale de Netty, à mon humble avis, est la possibilité de créer des gestionnaires de pipeline avec une "couverture d'un". Vous avez probablement lu à propos de cette annotation de couverture déjà dans la documentation, mais essentiellement il vous donne l'état dans une seule ligne de code. Sans déconner, pas de cartes de session, la synchronisation et des choses comme ça, nous étions tout simplement en mesure pour déclarer des variables régulières (par exemple, "Nom d'utilisateur") et les utiliser.
, Mais ensuite nous avons frappé un barrage routier. Nous avions déjà un serveur multi-protocole sous MINA, dans lequel notre protocole d'application fonctionnait sur TCP / IP, HTTP et UDP. Lorsque nous sommes passés à Netty nous avons ajouté SSL et HTTPS à la liste en quelques minutes! Jusqu'à présent tout va bien, mais quand il est venu à UDP nous avons réalisé que nous avions glissé. MINA était très gentil avec nous en ce que nous pouvions traiter UDP comme un protocole "connecté". Sous Netty, il n'y a pas une telle abstraction. UDP est sans connexion et Netty le traite comme tel. Netty expose plus de la nature sans connexion de L'UDP à un niveau inférieur à celui de MINA. Il y a des choses que vous pouvez faire avec UDP sous Netty que vous ne pouvez pas sous l'abstraction de niveau supérieur que Mina fournit, mais sur laquelle nous nous sommes appuyés.
Il n'est pas si simple d'ajouter un wrapper "UDP connecté" ou quelque chose comme ça. Compte tenu des contraintes de temps et sur les conseils de Trustin que la meilleure façon de procéder était de mettre en œuvre notre propre fournisseur de transport à Netty, qui ne serait pas rapide, nous avons dû abandonner Netty à la fin.
Alors, regardez attentivement les différences entre eux et obtenez rapidement une étape où vous pouvez tester toute fonctionnalité délicate fonctionne comme prévu. Si vous êtes satisfait que Netty fera le travail, alors je n'hésiterais pas à aller avec elle sur MINA. Si vous passez de MINA à Netty, il en va de même, mais il convient de noter que les deux API sont vraiment très différentes et que vous devriez envisager une réécriture virtuelle pour Netty-vous ne le regretterez pas!
MINA a plus de fonctionnalités prêtes à l'emploi au prix de la complexité et des performances relativement médiocres. Certaines de ces fonctionnalités ont été intégrées dans le noyau trop étroitement pour être supprimées même si elles ne sont pas nécessaires par un utilisateur. Dans Netty, j'ai essayé de résoudre ces problèmes de conception tout en conservant les forces connues de MINA.
Actuellement, la plupart des fonctionnalités disponibles dans MINA sont également disponibles dans Netty. À mon avis, Netty a une API plus propre et plus documentée puisque Netty est le résultat d'essayer de reconstruire MINA à partir de zéro et résoudre les problèmes connus. Si vous trouvez qu'une fonctionnalité essentielle est manquante, n'hésitez pas à poster votre suggestion sur le forum. Je serais ravi de répondre à votre préoccupation.
Il est également important de noter que Netty a un cycle de développement plus rapide. Simplement, consultez la date de sortie des versions récentes. En outre, vous devriez considérer que l'équipe MINA procédera à une réécriture majeure, MINA 3, ce qui signifie qu'ils vont complètement casser la compatibilité de L'API.
J'ai testé 2 implémentations" Google Protobuffer RPC " où l'une était basée sur Netty (netty-protobuf-rpc) et l'autre basée sur mina (protobuf-mina-rpc). Netty a fini par être constamment plus rapide (+- 10% ) pour toutes les tailles de messages - ce qui confirme la revendication de performance globale sur le site Web Netty. Puisque vous voulez extraire chaque bit d'efficacité de votre code lorsque vous utilisez une telle bibliothèque RPC, j'ai fini par écrire protobuf-rpc-pro Basé sur Netty. J'ai utilisé MINA dans le passé, mais trouver leur documentation de la substance 2.0 a de gros trous, et la rupture de la rétrocompatibilité de L'API un gros moins.
MINA et Netty ont été initialement conçus et construits par le même auteur. C'est pourquoi ils sont si semblables les uns aux autres. MINA est conçu à un niveau légèrement supérieur avec un peu plus de fonctionnalités, tandis que Netty est un peu plus rapide. Je pense qu'il n'y a pas beaucoup de différence du tout, les concepts de base sont les mêmes.
Dans le site Netty, vous pouvez trouver des rapports de performance . Comme prévu : -) ils soulignent Netty comme le cadre avec les meilleures performances.
Je n'ai jamais utilisé Netty, mais J'ai déjà utilisé MINA pour implémenter un protocole TCP. La mise en œuvre du codage et du décodage était facile, mais la mise en œuvre de la machine d'état n'était pas si facile. MINA fournit des classes pour vous aider lors de la mise en œuvre de la machine d'état, mais je les ai trouvées difficiles à utiliser. À la fin nous avons décidé de fossé MINA et mettre en œuvre le protocole à partir de zéro, et étonnamment nous avons fini avec un serveur plus rapide.
Je préfère Netty.
Twitter a également choisi Netty pour construire son nouveau système de recherche et l'a accéléré jusqu'à 3 fois plus vite.
Ref: LA RECHERCHE Twitter est maintenant 3 fois plus rapide
Nous avons choisi Netty sur certains de ses autres concurrents, comme Mina et Jetty, parce qu'il a une API plus propre, une meilleure documentation et, plus important encore, parce que plusieurs autres projets de Twitter utilisent ce framework.
J'ai seulement utilisé MINA pour construire un petit serveur de type http. Les plus gros problèmes que j'ai rencontrés jusqu'à présent:
- il conservera votre "demande" et votre "réponse" en mémoire. Ce n'est qu'un problème car le protocole que je choisis d'utiliser est http. Vous pouvez cependant utiliser votre propre protocole pour contourner cela.
- Aucune option pour fournir un flux hors disque au cas où vous souhaitez servir des fichiers volumineux. Encore une fois peut être contourné en implémentant votre propre protocole
Belles choses à ce sujet:
- peut gérer beaucoup de connexions
- Si vous choisissez d'implémenter une sorte de système de travail distribué, savoir quand l'un de vos nœuds tombe en panne et perd la connexion est utile pour redémarrer le travail sur un autre nœud.