Какое лучшее решение для внедрения системы клиент-сервер с помощью Java-сокетов
Мне нужен совет от кого-то, кто имеет опыт работы в сети.
Я уже создал систему, предназначенную для мониторинга некоторых задач (5-30), которые написаны на Java, запущенных с помощью автоматического планировщика или оператора. Этими задачами занимаются системы в контексте банковского дела или страхования.
Система состоит из клиентского класса, многопоточного сервера и веб-приложения. Задачи будут использовать клиент для связи с сервером, и веб-приложение делает то же самое, чтобы отслеживать производительность задач, зарегистрированных на сервере, и веб-приложение может также отправлять задачам некоторые команды, такие как "стоп" или "пауза".
задача [1-n] <---> сервер <---> веб-приложение
Поскольку веб-приложение должно иметь возможность отправлять команды в пакет, здесь кроется проблема. Я нашел 2 решения:
1) без соединения; Не сохраняются открытые соединения между сторонами, клиент периодически отправляет статус на сервер и запрашивает у сервера, есть ли для него команды, период должен составлять несколько секунд, каждый запрос открывается, а затем закрывает сокет соединения в аналогичном режиме. путь к протоколу http.
2) Connectionfull; активные связи поддерживаются между сторонами. На этом этапе задачи могут связываться с сервером, а сервер - с задачами без опроса. Например, каждый раз, когда веб-приложение запрашивает состояние задачи на сервере, он спрашивает клиента, который его предоставит.
На мгновение я принял решение 1, и в смоделированной тестовой среде оно работает нормально.
Вопрос в том, что с точки зрения использования ресурсов и гибкости существует решение между двумя, безусловно, лучше, если да, то какой?
Если у вас есть какая-то связь с конкретным обсуждением темы, это хорошо.
Спасибо пока
1 ответ
Этот вопрос, вероятно, не по теме для Server Fault. Это, безусловно, основано на мнении.
Правильная архитектура для вашего программного обеспечения зависит от сети и архитектуры безопасности среды, в которой будет использоваться приложение. Это также будет зависеть от желаемой частоты обмена данными между компонентами и от того, сколько может использовать опрос полосы пропускания по сравнению с постоянными соединениями.
Если бы этот продукт создавался для перепродажи, я бы сделал его максимально гибким и, возможно, попытался бы использовать несколько архитектур.
Если клиентский и серверный компоненты работают, например, в одной и той же "зоне безопасности", вы можете рассмотреть архитектуру, в которой один из компонентов может инициировать связь с другим (по сути, оба компонента в некоторой степени превращаются в "серверы"). Это минимизирует задержку и исключит опрос.
В качестве альтернативы, если клиент будет сегрегирован таким образом, что сервер не сможет устанавливать произвольные соединения с клиентом (например, если клиент находился на внутренней стороне межсетевого экрана, разделяющего их), тогда выполняется опрос или постоянные соединения из клиент, вероятно, путь. Опрос может быть слишком "дорогим" (с точки зрения использования полосы пропускания), если ваша частота опроса высока, но постоянные соединения будут нуждаться в периодическом "сердцебиении", чтобы поддерживать их "живыми" на устройствах фильтрации с отслеживанием состояния.
Там нет единого решения для всех.