Для высокой доступности или распределения нагрузки, применяется практика запуска процессов в кластере на нескольких нодах. Соответственно, в случае выходе из строя какого-либо узла, другие работают исправно. Например, используя тот же Docker Swarm, можно поднять процесс даже с одной репликой, и он будет перезапущен на другой ноде, в случае чего.
На этом этапе все прозрачно и понятно. Далее вступает в игру такой компонент, как фронт-сервер, или балансировщик. Соответственно, часть архитектурных логических задач по управлению траффиком лежит на нем. Например, детектинг отключенной ноды, задействование новой и т.п.
Но есть предположение, что сам фронт-сервер, поднимаясь на одной ноде априори вносит сомнение в высокую доступность системы, т.к. в случае возникновения сбоя на этом участке, совершенно не имеет значения, сколько там реплик чего было поднято - запросы все равно не дойдут никуда.
В самом классическом варианте, клиент шлет запрос на определенное доменное имя. Правильно ли я думаю, что для высокой доступности, сам фронт-сервер должен быть запущен также в нескольких репликах, а так же должен присутствовать компонент, который сможет по нужным коллбекам ходить на ДНС сервер и там вносить корректировки по факту отключения того или иного фронт-сервера?
Какую топологию компонентов (узлов) вы используете в своих проектах?
Если речь о классическом веб-сервисе, к которому обращаются браузеры, то ничего не попишешь, придется:
Балансировщик упрощается до ужаса, для минимизации ошибок.
Балансировщик отлаживается существенно тщательнее чем прочие компоненты
Дополнительно реализуется на сетевом уровне слой, который автоматически перекидывает на исправный балансировщик - например, на основании информации BGP, задание нескольких IP-адресов в DNS и т.п.
Но полностью не избежать проблем. Ручное отслеживание, ручное перекидывание на резерв нужно.
Если же речь идет об API, которому обращаются специально написанные клиенты - балансируется клиентами. Это можно сделать намного гибче и нет единой точки отказа (клиентов же много).
Сложный
