Нетти против Apache MINA

Они оба обеспечивают примерно одинаковую функциональность. Какой из них выбрать для разработки моего высокопроизводительного TCP-сервера? Какие плюсы и минусы?

Ссылочные ссылки:

Apache MINA ( источник )

Нетти ( источник )

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

Мы нашли все проще в Нетти. Период. В то время как мы пытались реализовать ту же функциональность, что и в MINA, мы сделали это с нуля. Следуя превосходной документации и примерам, мы получили больше функциональности в гораздо меньшем количестве кода.

Netty Pipeline работал лучше для нас. Это как-то проще, чем MINA, где все является обработчиком, и вы сами решаете, обрабатывать ли восходящие события, нисходящие события, оба или потреблять больше низкоуровневых вещей. Погибать байты в «повторных» декодерах было почти удовольствием. Также было очень приятно иметь возможность легко перенастроить трубопровод на лету.

Но главной особенностью Netty, imho, является возможность создавать конвейерные обработчики с «охватом одного». Возможно, вы уже читали об этой аннотации покрытия уже в документации, но по сути она дает вам состояние в одной строке кода. Без суеты, карт сеансов, синхронизации и тому подобного мы просто могли объявлять обычные переменные (скажем, «имя пользователя») и использовать их.

Но затем мы попали на контрольно-пропускной пункт. У нас уже был многопротокольный сервер под MINA, в котором наш протокол приложений работал по TCP / IP, HTTP и UDP. Когда мы переключились на Netty, мы добавили SSL и HTTPS в список за считанные минуты! Пока все хорошо, но когда дело дошло до UDP, мы поняли, что поскользнулись. MINA была очень милой с нами тем, что мы могли рассматривать UDP как «подключенный» протокол. Под Нетти нет такой абстракции. 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 реализаций "Google Protobuffer RPC", одна из которых была основана на Netty (netty-protobuf-rpc), а другая - на mina (protobuf-mina-rpc). В итоге Netty стал стабильно быстрее (+ - 10%) для сообщений любого размера, что подтверждает общую заявленную производительность на веб-сайте Netty. Поскольку при использовании такой библиотеки RPC вы хотите выжать каждый бит эффективности из своего кода, я в итоге написал protobuf-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. Если вы решите внедрить какую-то распределенную рабочую систему, то знание того, когда один из ваших узлов выходит из строя и теряет соединение, полезно для возобновления работы на другом узле.