Netty vs Apache MINA

Oba zapewniają mniej więcej taką samą funkcjonalność. Który powinienem wybrać, aby stworzyć mój wydajny serwer TCP? Jakie są zalety i wady?

Linki referencyjne:

Apache MINA ( źródło )

Netty ( źródło )

Chociaż MINA i Netty mają podobne ambicje, w praktyce różnią się one od siebie i powinieneś dokładnie rozważyć swój wybór. Mieliśmy szczęście, ponieważ mieliśmy duże doświadczenie z MINA i mieliśmy czas, aby pobawić się z Netty. Szczególnie podobało nam się czystsze API i znacznie lepsza dokumentacja. Wydajność wydawała się lepsza również na papierze. Co ważniejsze, wiedzieliśmy, że Trustin Lee będzie pod ręką, aby odpowiedzieć na wszelkie pytania, które mieliśmy, i na pewno to zrobił.

W Netty wszystko było łatwiejsze. Kropka. Podczas gdy próbowaliśmy ponownie zaimplementować tę samą funkcjonalność, którą mieliśmy już na MINA, zrobiliśmy to od zera. Postępując zgodnie z doskonałą dokumentacją i przykładami, uzyskaliśmy większą funkcjonalność w znacznie mniejszym kodzie.

Netty Pipeline działał lepiej dla nas. Jest to w jakiś sposób prostsze niż MINA, gdzie wszystko jest programem obsługi i od Ciebie zależy, czy obsłużyć zdarzenia poprzedzające, zdarzenia późniejsze, czy też zużywać więcej rzeczy niskiego poziomu. Pożeranie bajtów w dekoderach „odtwarzających” było prawie przyjemnością. Bardzo miło było również móc tak łatwo zmienić konfigurację rurociągu w locie.

Ale największą atrakcją Netty, imho, jest możliwość tworzenia programów obsługujących rurociąg z „zasięgiem jednego”. Prawdopodobnie czytałeś już o tej adnotacji dotyczącej pokrycia już w dokumentacji, ale zasadniczo podaje ona stan w jednej linii kodu. Bez bałaganu, bez map sesji, synchronizacji i tym podobnych, mogliśmy po prostu zadeklarować zwykłe zmienne (powiedzmy, „nazwa użytkownika”) i ich używać.

Ale potem natrafiliśmy na blokadę. Mieliśmy już serwer wieloprotokołowy w ramach MINA, w którym nasz protokół aplikacji działał przez TCP / IP, HTTP i UDP. Kiedy przeszliśmy na Netty, dodaliśmy SSL i HTTPS do listy w ciągu kilku minut! Jak na razie dobrze, ale kiedy przyszło do UDP, zdaliśmy sobie sprawę, że popełniliśmy błąd. MINA było dla nas bardzo miłe, ponieważ mogliśmy traktować UDP jako protokół „połączony”. W Netty nie ma takiej abstrakcji. UDP jest bezpołączeniowy i Netty traktuje go jako taki. Netty bardziej ujawnia bezpołączeniowy charakter UDP na niższym poziomie niż MINA. Są rzeczy, które możesz zrobić z UDP w Netty, niż nie możesz zrobić w ramach abstrakcji wyższego poziomu, którą zapewnia MINA, ale na której polegaliśmy.

Dodanie opakowania „połączonego UDP” czy czegoś takiego nie jest takie proste. Biorąc pod uwagę ograniczenia czasowe i zgodnie z radą Trustina, że ​​najlepszym sposobem postępowania jest wdrożenie naszego własnego przewoźnika w Netty, co nie będzie szybkie, ostatecznie musieliśmy zrezygnować z Netty.

Przyjrzyj się więc dokładnie różnicom między nimi i szybko przejdź do etapu, na którym możesz sprawdzić, czy każda trudna funkcjonalność działa zgodnie z oczekiwaniami. Jeśli jesteś zadowolony, że Netty wykona swoją pracę, to nie zawahałbym się przejść z tym do MINA. Jeśli przechodzisz z MINA do Netty, to obowiązuje to samo, ale warto zauważyć, że oba interfejsy API naprawdę znacznie się różnią i powinieneś rozważyć wirtualne przepisanie dla Netty - nie pożałujesz!

MINA ma więcej gotowych funkcji kosztem złożoności i stosunkowo słabej wydajności. Niektóre z tych funkcji zostały zbyt mocno zintegrowane z rdzeniem, aby można je było usunąć, nawet jeśli nie są potrzebne użytkownikowi. W Netty próbowałem rozwiązać takie problemy projektowe, zachowując znane mocne strony MINA.

Obecnie większość funkcji dostępnych w MINA jest również dostępna w Netty. Moim zdaniem Netty ma czystsze i bardziej udokumentowane API, ponieważ Netty jest wynikiem próby przebudowania MINA od podstaw i rozwiązania znanych problemów. Jeśli okaże się, że brakuje jakiejś istotnej funkcji, prosimy o przesłanie swojej sugestii na forum. Z przyjemnością odpowiem na Twoje obawy.

Należy również zauważyć, że Netty ma szybszy cykl rozwoju. Po prostu sprawdź datę premiery ostatnich wydań. Należy również wziąć pod uwagę, że zespół MINA przystąpi do poważnego przepisania, MINA 3, co oznacza, że ​​całkowicie zerwą kompatybilność API.

Przetestowałem wydajność 2 implementacji "Google Protobuffer RPC", gdzie jedna oparta była na Netty (netty-protobuf-rpc), a druga na mina (protobuf-mina-rpc). Netty okazał się konsekwentnie szybszy (+ - 10%) dla wszystkich rozmiarów wiadomości - co potwierdza ogólną wydajność witryny Netty. Ponieważ chcesz wycisnąć z kodu każdą część wydajności, gdy używasz takiej biblioteki RPC, napisałem protobuf-rpc-pro w oparciu o Netty. Używałem MINA w przeszłości, ale okazało się, że ich dokumentacja rzeczy 2.0 ma duże dziury, a zerwanie wstecznej kompatybilności API jest dużym minusem.

MINA i Netty zostały początkowo zaprojektowane i zbudowane przez tego samego autora. Dlatego są do siebie tak podobni. MINA został zaprojektowany na nieco wyższym poziomie z nieco większą liczbą funkcji, podczas gdy Netty jest nieco szybszy. Myślę, że nie ma dużej różnicy, podstawowe pojęcia są takie same.

W witrynie Netty można znaleźć kilka raportów wydajności . Zgodnie z oczekiwaniami :-) wskazują Netty jako framework o najlepszej wydajności.

Nigdy nie używałem Netty, ale już użyłem MINA do implementacji protokołu TCP. Implementacja kodowania i dekodowania była łatwa, ale implementacja automatu stanowego nie była taka łatwa. MINA zapewnia kilka klas, które pomogą ci w implementacji maszyny stanowej, ale okazało się, że są one trudne w użyciu. W końcu zdecydowaliśmy się porzucić MINA i zaimplementować protokół od zera i, co zaskakujące, skończyliśmy na szybszym serwerze.

Wolę Netty.

Twitter również wybrał Netty do zbudowania swojego nowego systemu wyszukiwania i przyspieszył go nawet 3x szybciej.

Ref: Wyszukiwanie na Twitterze jest teraz 3x szybsze

Wybraliśmy Netty zamiast niektórych innych konkurentów, takich jak Mina i Jetty, ponieważ ma czystsze API, lepszą dokumentację i, co ważniejsze, ponieważ kilka innych projektów na Twitterze używa tego frameworka.

Używałem MINA tylko do zbudowania małego serwera typu http. Największe problemy, z jakimi się do tej pory spotkałem:

1. Przechowuje w pamięci Twoje „prośby” i „odpowiedzi”. Jest to problem tylko dlatego, że wybrany przeze mnie protokół to http. Możesz jednak użyć własnego protokołu, aby to obejść.
2. Brak opcji dostarczania strumienia z dysku w przypadku, gdy chcesz obsługiwać duże pliki. Ponownie można to obejść, implementując własny protokół

Niezłe rzeczy:

1. Obsługuje wiele połączeń
2. Jeśli zdecydujesz się zaimplementować jakiś rodzaj rozproszonego systemu pracy, wiedza o tym, kiedy jeden z Twoich węzłów ulegnie awarii i utraci połączenie, jest przydatna do ponownego uruchomienia pracy na innym węźle.