Шаг 3. Многосерверная система

Масштабирование обеспечивается тем, что система функционирует на нескольких серверах. Преимущественно каждый сервер имеет свой состав ролей. На этом шаге мы исследуем то, каким образом обеспечивается объединение системы в единое целое. Для наглядности представим следующую схему распределения ролей по серверам на сайте (см.рис.)

Если бы речь шла о простом приложении, запущенном на 4 серверах, возьмем к примеру калькулятор, то это в целом было бы просто 4 независимых калькулятора. А мы имеем систему, где каждый экземпляр программы на каждом сервере (точнее, на каждой ноде) выполняет определенный набор ролей. При этом с точки зрения приложения на всех серверах всё одно и то же, но функционирует по-разному. Только вся система целиком обладает теми полезными качествами, которые удовлетворяют всему набору требований.

Каким образом каждый из серверов узнает, какие роли следует ему исполнять? Каким образом каждая роль на сервере узнает, где находятся нужные ей другие сервисы системы? В частности, роли WS требуется DC, и не просто как приложение, а именно как сервис, то есть работающее приложение с активными процессами и данными. Просто обратиться локально нельзя, ведь локально роль DC не исполняется (см. схему сайта – по одной роли на каждом сервере), а лишь имеется совокупность программных файлов в силу идентичности состава программных каталогов на всех серверах.

За это отвечает конфигурация – структура, объединяющая слои инфраструктуры, логики и данных между собой. Какой сервер к какому сайту относится, какие адреса у серверов, какие роли на каких серверах выполняются, какие доменные зоны на каких сайтах обслуживаются и прочие данные. Конфигурация определяется файлом конфигурации, и едина для всех серверов системы. Каждая нода на каждом сервере черпает в конфигурации информацию о том, какие серверы входят в инфраструктуру, обнаруживает себя, определяет какие роли следует активировать, а также на каких серверах располагаются остальные роли.

Запуск приложения платформы на сервере схематично выглядит так:

Еще одна диаграмма…​

Приложение запускает корневую ноду, где активируется служебная роль ServerShell. Ее основная задача – на основе файла конфигурации запускать и отслеживать дочерние рабочие ноды. Каждая рабочая нода стартует процесс BasedRole, который на основе файла конфигурации производит запуск целевых функциональных ролей. Если вдруг что-то происходит с рабочей нодой, ServerShell моментально её перезапускает. Если же что-то происходит с экземпляром целевой роли в рабочей ноде, ее перезапускает служебный сервис Boot.