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