Вопрос

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

Справочные ссылки:

Апач МИНА (Источник)

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

Это было полезно?

Решение

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

В Netty все оказалось проще. Период. В то время как мы пытались реализовать ту же функциональность, что у нас уже была в 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 на основе Нетти.Я использовал 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-подобного сервера. Самые большие проблемы, с которыми я столкнулся до сих пор:

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

    <Ол>
  • Может обрабатывать много соединений
  • Если вы решите внедрить какую-то распределенную рабочую систему, то знание того, когда один из ваших узлов выходит из строя и теряет соединение, полезно для возобновления работы на другом узле.
  • Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top