Как правильно спроектировать коммуникацию между серверами?

Question

[Губернатор]

Есть 2 внешних сервера, к которым есть доступ через интернет домен (ВНЕШНИЙ-1, ВНЕШНИЙ-2).
И есть еще 4 внутренних (ВНУТРЕННИЙ-1, ВНУТРЕННИЙ-2, ..3..4) сервера, у которых нет доступа в интернет, назову их скрытые сервера.
Скрытые 4 сервера могут обращаться к 2 внешним через ВПН (или что-то подобное).
Но внешние не могут обращаться к скрытым серверам.

Ранее схема работы была такая:
1. Клиент обращается на внешний сервер
2. сервер сохраняет запрос в своей внешней БД
3. скрытый сервер проверяет БД на наличие запросов, в случае обнаружения, обрабатывает запрос у себя
4. кладет ответ в БД внешнего сервера
5. внешний сервер обнаружив ответ, отдает его клиенту (клиент все это время ждал)

Необходимо добавить еще внутренних сервисов, и соответственно еще обработчиков, но проблема в том, что это решение самописное, и сложно поддается масштабированию.
Необходимо упростить и стандартизировать решение, но я не понимаю - как эта область называется, и в какую сторону копать.

Слышал про RabbitMQ, и Kafka но не понимаю подойдут ли они в этом случае.
Подскажите пожалуйста, какие существуют архитектурные решения в подобном вопросе?

Comments

[Valentin Barbolin]

> Как правильно спроектировать коммуникацию между серверами?
При чем тут коммутация? Коммутация относиться к первому оровню модели OSI.

> но проблема в том, что это решение самописное, и сложно поддается масштабированию.
Раз внешних серверов 2, а внутренних 4, значит механизм распределения нагрузки заложен. В чем проблема просто добавить еще один сервер внутри?

[mayton2019]

RabbitMQ/Kafka - это асинхронный вызов методов без обратной связи. Не для всякого бизнеса он подходит. И его надо обсуждать не в данном топике. По крайней мере где VPN и сети - никто не обсуждает следующие два уровня где надо уже говорить о транзакциях, кодах ошибок и о различного уровня гарантиях.

Вобщем лучше поднять отдельный вопрос.

Answer 1

[Илья Голец]

На счёт «как эта область называется, и в какую сторону копать» — наиболее близкие по смыслу — это «Service oriented architecture» и «Event driven architecture». Подробно раскрывать не буду, почитайте на досуге.

Очереди сообщений (те самые MQ из RabbitMQ) тут как раз могут быть полезны и будут помогать с масштабированием. В идеале, чтобы избежать ненужных ожиданий, хорошо бы разрешить внешним серверам работать с очередями (как минимум, писать в них задачи на обработку).

Касательно масштабирования — не очень понятно, какую часть вы пытаетесь масштабировать. Мое предположение — скорее скрытые сервера, которые, как я понял, делают какую-то нагруженную обработку. При наличии очереди сообщений вы можете делать произвольное количество серверов, которые вынимают задачу из очереди, обрабатывают и помечают задание как выполненное. Более того, если разворачивать решение на облачной платформе (любой), можно создать метрику, которая анализирует длину этой очереди и при её росте автоматически запускает новые инстансы (сервера) в «скрытой» зоне. А при уменьшении очереди так же автоматически их тушит, чтобы не тратить деньги.

В общем и целом, вся схема выглядит не сильно ужасной, но немного смущает эта синхронизация внешней и внутренней систем через базу данных. Непременно будут таймауты, если опросы с обеих сторон будут по таймеру. Можно подумать о том, чтобы использовать какие-то уведомления от базы данных, например, в MSSQL такое есть.

А если говорить о том, как делаются «промышленные» (не самопальные) системы такого рода, то тут будут следующие слои начиная от пользователя:

1. Балансировщик нагрузки
   
2. Веб-приложения (их может быть несколько, чтобы можно было, например, по одному отключать и обслуживать)
   
3. Очередь сообщений
   
4. База данных
   
5. Сервера фоновой обработки
   

Веб-приложения могут добавляться в пул по метрикам загрузки процессора и времени ответа.
Сервера фоновой обработки могут добавляться в пул по метрикам длины очереди.