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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

Сначала напишите логику своей службы, чтобы она не зависела от вашего уровня связи.

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

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