Netty vs Apache MINA

Вони обидва забезпечують однаковий функціонал. Який вибрати для розробки свого високоефективного сервера TCP? Які плюси і мінуси?

Довідкові посилання:

Apache MINA ( джерело )

Netty ( джерело )

Незважаючи на те, що MINA та Netty мають подібні амбіції, вони на практиці досить різні, і ви повинні уважно ставитися до свого вибору. Нам пощастило в тому, що ми мали великий досвід роботи з MINA та мали час пограти з Netty. Нам особливо сподобався чистіший API та набагато краща документація. Продуктивність здавалася кращою і на папері. Що ще важливіше, ми знали, що Трустін Лі буде готовий відповідати на будь-які наші запитання, і він, безумовно, це зробив.

Ми знайшли все простіше в Netty. Період. Поки ми намагалися повторно реалізувати ту саму функціональність, яку ми вже мали на MINA, ми зробили це з нуля. Дотримуючись чудової документації та прикладів, ми отримали більше функціональних можливостей у набагато, значно меншому коді.

Трубопровід Netty працював краще для нас. Це дещо простіше, ніж MINA, де все є обробником, і ви вирішуєте, чи обробляти події вгору за потоком, події вниз за течією, або споживати більше матеріалів низького рівня. Пограбування байтів у "відтворення" декодерів було майже задоволенням. Було також дуже приємно, що можна було так легко перелаштувати трубопровід на ходу.

Але зіркова привабливість Netty, imho, - це можливість створювати конвеєри трубопроводів з "покриттям одного". Ви, ймовірно, читали про цю примітку про покриття вже в документації, але по суті вона дає вам стан в одному рядку коду. Не турбуючись, не маючи сеансові карти, синхронізацію та подібні речі, ми просто змогли оголосити звичайні змінні (скажімо, "ім'я користувача") та використати їх.

Але тоді ми потрапили в блокпост. У нас вже був багатопротокольний сервер під MINA, на якому наш протокол додатків переходив через TCP / IP, HTTP та UDP. Коли ми перейшли на Netty, ми додали SSL та HTTPS до списку за лічені хвилини! Поки що добре, але коли справа дойшла до UDP, ми зрозуміли, що ми прослизнули. МІНА була дуже приємна нам тим, що ми могли ставитися до UDP як до "підключеного" протоколу. Під Netty такої абстракції немає. UDP не пов'язаний і Netty ставиться до цього як до такого. Netty розкриває більше беззв'язного характеру UDP на нижчому рівні, ніж MINA. Ви можете зробити з UDP в Netty, ніж ви не можете під абстракцією вищого рівня, яку надає MINA, але на яку ми покладалися.

Не так просто додати обгортку "підключений UDP" чи щось таке. Враховуючи часові обмеження та поради Трустіна, що найкращим способом продовжувати було впровадження власного постачальника транспорту в Netty, що було б не швидко, ми зрештою повинні були відмовитися від Netty.

Отже, уважно подивіться на відмінності між ними та швидко перейдіть до етапу, коли ви можете перевірити будь-яку складну функціональність, як працює, як очікувалося. Якщо ви впевнені, що Нетті зробить цю роботу, то я б не вагався перейти з нею через MINA. Якщо ви переходите від MINA до Netty, те саме стосується, але варто відзначити, що два API справді значно відрізняються, і вам слід розглянути можливість віртуальної переписування для Netty - ви не пошкодуєте про це!

MINA має більше нестандартних функцій ціною складності та відносно низькою продуктивністю. Деякі з цих функцій були вбудовані в ядро ​​занадто щільно, щоб видалити їх, навіть якщо користувачеві вони не потрібні. У Netty я намагався вирішити такі проблеми дизайну, зберігаючи відомі сильні сторони MINA.

В даний час більшість функцій, доступних в MINA, також доступні в Netty. На мій погляд, у Netty є більш чистий та задокументований API, оскільки Netty є результатом спроби відновити MINA з нуля та вирішити відомі проблеми. Якщо ви виявите, що важлива функція відсутня, не соромтеся розмістити свої пропозиції на форумі. Я буду радий звернутися до вашої турботи.

Важливо також зазначити, що Netty має більш швидкий цикл розвитку. Просто перевірте дату випуску останніх випусків. Також слід врахувати, що команда MINA перейде до основного перезапису, MINA 3, а це означає, що вони повністю порушать сумісність API.

Я перевірив продуктивність 2-х реалізацій «Протоколу RPC Google», де одна була заснована на Netty (netty-protobuf-rpc), а інша - на mina (protobuf-mina-rpc). Netty виявився стабільно швидшим (+ - 10%) для всіх розмірів повідомлень - що забезпечує резервне копіювання загальної вимоги щодо ефективності на веб-сайті Netty. Оскільки ви хочете вичавити кожен шматочок ефективності зі свого коду, коли ви використовуєте таку бібліотеку RPC, я закінчив писати протобуф-rpc-pro на базі Netty. У минулому я використовував MINA, але в їх документації щодо речей 2.0 є великі дірки, а розбиття назад сумісності API - великий мінус.

MINA та Netty спочатку були розроблені та створені одним і тим же автором. Ось чому вони так подібні один до одного. MINA розроблений на трохи більш високому рівні з трохи більше функцій, в той час як Netty трохи швидше. Я думаю, що різниці взагалі не так багато, основні поняття однакові.

На сайті Netty ви можете знайти кілька звітів про ефективність . Як і очікувалося :-) вони відзначають Netty як основу з найкращою продуктивністю.

Я ніколи не використовував Netty, але вже використовував MINA для реалізації протоколу TCP. Реалізація кодування та декодування була легкою, але реалізація державної машини була не такою простою. MINA пропонує кілька класів, які допоможуть тобі при впровадженні державної машини, але мені здалося, що вони важкі у використанні. Врешті-решт ми вирішили скинути MINA та реалізувати протокол з нуля, і на диво ми закінчили більш швидкий сервер.

Я віддаю перевагу Нетті.

Також Twitter вибрав Netty для створення нової пошукової системи та пришвидшення її до 3 разів швидше.

Довідка: Пошук у Твіттері зараз у 3 рази швидший

Ми вибрали Netty над іншими своїми конкурентами, такими як Mina та Jetty, оскільки він має більш чистий API, кращу документацію та, що ще важливіше, тому що кілька інших проектів у Twitter використовують цю рамку.

Я тільки коли-небудь використовував MINA для створення невеликого http-сервера. Найбільші проблеми, з якими я стикався до цього часу:

1. Він збереже ваші "запит" і "відповідь" в пам'яті. Це лише проблема, оскільки протокол, який я обираю використовувати, - це http. Однак ви можете використовувати власний протокол, щоб обійти це.
2. Немає можливості надати потік з диска, якщо ви хочете подавати великі файли. Знову можна обійтись, застосувавши власний протокол

Приємних речей про це:

1. Може обробляти безліч з'єднань
2. Якщо ви вирішили реалізувати якусь розподілену робочу систему, то знаючи, коли один з ваших вузлів виходить з ладу і втрачає з'єднання, корисно для перезавантаження роботи на іншому вузлі.