Преимущества Netty по сравнению с базовым сервером ServerSocket?

Мне нужно создать относительно простой сервер Java tcp/ip, и у меня возникли небольшие проблемы с определением, следует ли мне использовать что-то вроде Netty или просто придерживаться простых ServerSocket и InputStream/OutputStream.

Нам действительно нужно просто прослушать запрос, а затем передать новый клиентский сокет какому-то коду обработки в новом потоке. Этот поток завершится после завершения обработки и отправки ответа.

Мне нравится идея конвейеров, декодеров и т. д. в Netty, но для такого простого сценария кажется, что это не стоит дополнительных затрат времени на разработку. Это кажется немного излишним для наших первоначальных требований, но я немного нервничаю из-за того, что есть много вещей, которые я не учитываю. Каковы преимущества Netty для таких простых требований, если таковые имеются? Что я не учитываю?


java tcp network-programming netty serversocket
person jluce50    schedule 06.12.2011    source источник
comment
Если это один из ваших первых проектов с сокетами, используйте low-level, чтобы лучше понять. Когда оцените API более высокого уровня и выберите тот, который вам больше нравится: Netty, Mina, ProtocolBuffers и т. д.   -  person Victor Sorokin    schedule 07.12.2011

Ответы (3)


arrow_upward
68
arrow_downward

Основное преимущество Netty по сравнению с простым чтением и записью в сокеты с использованием потоков заключается в том, что Netty поддерживает неблокирующий асинхронный ввод-вывод (с использованием NIO API Java); когда вы используете потоки для чтения и записи из сокетов (и вы запускаете новый поток для каждого соединения, принятого из ServerSocket), вы используете блокирующий синхронный ввод-вывод.

Подход Netty намного лучше масштабируется, что важно, если ваша система должна иметь возможность обрабатывать множество (тысячи) подключений одновременно. Если ваша система не нуждается в масштабировании для множества одновременных подключений, возможно, не стоит использовать такую ​​​​инфраструктуру, как Netty.

Еще немного справочной информации: потоки — это относительно дорогостоящие ресурсы в операционной системе. Каждому потоку требуется память для стека (размер которого может составлять, например, 2 МБ). Когда вы создаете тысячи потоков, это требует много памяти; кроме того, операционные системы имеют ограничения на количество создаваемых потоков. Таким образом, вы не хотите начинать новый поток для каждого принятого соединения. Идея асинхронного ввода-вывода состоит в том, чтобы отделить потоки от соединений (отсутствие однозначного отношения). Соединений может быть намного больше, чем потоков, и всякий раз, когда на одном из соединений происходит какое-либо событие (например, получение данных), для обработки события временно используется поток из пула потоков.

person Jesper    schedule 06.12.2011

arrow_upward
13
arrow_downward

Я думаю, что преимущества использования netty проявляются не сразу, а позже, когда меняются требования и обслуживание вашего проекта становится более сложным. Netty обеспечивает встроенное понимание протокола HTTP, поэтому вы можете предоставлять простые веб-службы RESTful. Также у вас есть возможность использовать асинхронную обработку запросов, которую netty предоставляет в качестве основы, чтобы вы могли потенциально повысить производительность и обслуживать на несколько порядков больше одновременных запросов.

person Neil Essy    schedule 06.12.2011

arrow_upward
6
arrow_downward

Во-первых, напишите логику вашего сервиса так, чтобы она не зависела от вашего коммуникационного уровня.

Как сказал Виктор Сорокин, есть преимущество в том, чтобы делать это самому. Так что стоит написать его с сокетами. Это потребует меньше усилий, чтобы начать работу, и если это работает достаточно хорошо, вы отправляетесь в гонки.

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

person Bill    schedule 06.12.2011