Задать вопрос
@SimpleDreamer

Какие технологии и архитектуру выбрать при проектировании сервера контроля доступа?

Добрый день!
Сейчас занимаюсь разработкой сервера контроля доступа.
Задачи - обеспечение возможности подключения приборов СКУД по протоколу TCP, хранение всей конфигурации приборов СКУД в базе данных (карточки, права доступа), выгрузка всех логов со СКУД в базу данных.
Также будет необходим удобный пользовательский интерфейс для управления всем этим - добавления/удаления карточек, редактирования прав доступа, просмотра истории событий, формирование отчетов и рассылка их.
В итоге я принял решение разбить систему на несколько фрагментов:
- TCP сервер, который обеспечивает коммуникация с приборами СКУД по TCP.
- база данных.
- веб-сервер управления, который обеспечивает работу таких REST-сервисов как
* сервис настроек,
* сервис отчетов,
* сервис рассылки

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

Также само и выгрузка данных с приборов СКУД идет через базу данных, т.е. TCP сервер выгружает все в БД, где и храниться постоянно история всех событий.

Команды в базу идут со стороны веб-сервера от пользователя, и в обратную сторону информация забирается из БД пользователем.

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

Пока вижу плохие моменты данного решения:
- если что-то происходит с базой, то управление TCP-сервером, загрузка/выгрузка данных невозможна.
Чтобы этого избежать была мысль в качестве каналов коммуникации использовать сервисы очередей типа ActiveMQ/RabbitMQ и параллельно результаты выполнения дублировать в текстовые логи и в базу.
- из-за того что все идет через базу, БД будет вносить свои задержки.

Возможно не учел еще какие-то моменты.
  • Вопрос задан
  • 140 просмотров
Подписаться 1 Простой Комментировать
Решения вопроса 1
Adamos
@Adamos
Отдайте базу веб-серверу управления и не подпускайте к ней никого, выполняя все правки и выборки только через API сервера управления. Жизнь сразу облегчится, особенно если API будет высокоуровневым, а не дублированием CRUD.
А серверу, обслуживающему железо, все равно надо самому логировать все, что с ним происходит. Хоть голым текстом - логи понадобятся только для разборок с факапами.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы