Netty против Apache MINA

Ответ 1

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

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

Netty Pipeline работал лучше для нас. Это как-то проще, чем MINAs, где все является обработчиком, и вам решать, обрабатывать ли восходящие события, нисходящие события, или потреблять более низкоуровневые вещи. Сглаживание байтов в "повторном" декодере было почти приятным. Было также очень приятно иметь возможность перенастроить конвейер на лету так легко.

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

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

Не так просто добавить "подключенную UDP-оболочку" или что-то еще. Учитывая временные ограничения и советы Trustin, что лучший способ продолжить - это реализовать нашего собственного поставщика транспорта в Netty, который не был бы быстрым, в конце концов нам пришлось отказаться от Netty.

Итак, внимательно изучайте различия между ними и быстро переходите на сцену, где вы можете протестировать любую сложную функциональность, работающую, как ожидалось. Если вы удовлетворены тем, что Netty выполнит эту работу, я бы без колебаний пошел с ней над MINA. Если вы переходите от MINA к Netty, то то же самое относится, но стоит отметить, что оба API действительно существенно отличаются, и вы должны рассмотреть виртуальную переписку для Netty - вы не пожалеете об этом!

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

На Netty вы можете найти некоторые отчеты . Как и ожидалось:-), они указывают на Netty как основу с лучшей производительностью.

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

Ответ 6

Я предпочитаю Netty.

Twitter также выбрал Netty для создания новой поисковой системы и ускорил ее до 3 раз быстрее.

Ссылка: Twitter Search теперь 3x быстрее

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

Ответ 7

Я только когда-либо использовал MINA для создания небольшого http-сервера. Самые большие проблемы, с которыми я столкнулся до сих пор:

• Он будет хранить ваши "запрос" и "ответ" в памяти. Это только проблема, потому что протокол, который я предпочитаю использовать, - http. Однако вы можете использовать свой собственный протокол, чтобы обойти это.
• Нет возможности предоставить поток с диска, если вы хотите подавать большие файлы. Снова можно обойти, реализовав собственный протокол.

Приятные вещи:

• Может обрабатывать множество соединений
• Если вы решите реализовать какую-то распределенную рабочую систему, тогда зная, когда один из ваших узлов опустится и теряет соединение, полезно перезапустить работу над другим node.