Шаг 8. Какой экземпляр роли активен

Для других сервисов системы роль DC светится списком именованных микросервисов – по одному на каждый домен. Именно эти микросервисы поднимаются активным экземпляром роли, и не поднимаются резервными экземплярами. Именно эти микросервисы разделяются по группам ролей в соответствии с обслуживаемыми доменными зонами. Таким образом для WS достаточно сформулировать задачу, ориентированную на DC и указать интересующий домен, а остальное решается через подсистему глобальных имен. При этом WS безразлично, какой именно вариант DC находится на его сайте – MDC или SDC, и как именно разделены доменные зоны по группам ролей DC, какие домены обслуживаются на текущем сайте, а какие проксируются. Все это реализуется за его пределами – в системе регистрации глобальных имен и в самой роли DC.

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

Роль RPCI резервируется в режиме Active-Active, и имеет клиентский модуль, активный на любой ноде и доступный любым сервисам на ней. Фактически клиентский модуль является функциональным фасадом RPCI.

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

При рассмотрении сервисного взаимодействия ролей на диаграмме не имеет значения их распределение по серверам. Важно лишь то, что все они находятся на одном сайте.

В приведенном выше первом принципе упомянут клиентский модуль роли RPCI, доступный на любой ноде. В нем происходит поиск сервиса роли RPCI, а также кэширование недоступных экземпляров и периодическая их проверка. Этот принцип используется для служебных ролей, в частности ServerShell именно таким образом осуществляет поиск IC.

Этот подход реализует принцип инкапсуляции. Есть ли там кэширование – зависит от конкретной реализации клиентского компонента роли.

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

Чтобы не обращаться всякий раз на сервер RPCI, локальный клиентский модуль, получив ответ от сервера, ставит выданный процесс на мониторинг. В дальнейшем вплоть до завершения этого процесса данные о нем предоставляются локально и оперативно.

Кэширование не всегда полезно, существуют такие операции, которые не терпят даже 5 секунд лишней задержки. Такая задержка может появиться, если кэш предоставляет данные о недоступном сервере в течение какого-то времени, а инициатор запроса отправляет запрос и ждет его выполнения или какого-то ответа на него в течение некоторого времени, прежде чем зафиксировать неудачу и перейти к следующему экземпляру. Решению этого вопроса служит системный пинг-понг перед отправкой запроса. Пинг-запрос либо проходит быстро, либо сервер/сервис точно недоступен. Преимущество подхода в дешевой быстрой проверке актуальности. Внутренние сервисы не злоупотребляют пингами в некритичных ко времени и надежности доставки запроса задачах, поэтому общее их количество в трафике не слишком высоко.

Массовая рассылка запросов может использоваться в тех местах, где обработка запроса занимает существенно больше времени, чем обработка пакетов. Таким образом, в ходе массовой рассылки производится расчет на то, что роль-получатель запроса самостоятельно определит, какой из экземпляров будет выполнять запрос. Либо же вовсе могут быть необходимы ответы каждого из экземпляров, например, в кейсе "собрать все внешние подключения системы" было бы необходимо опросить все роли WS и объединить их ответы в один список. Конечно же массовая рассылка производится параллельно (отправляются запросы всем получателям и только потом производится сбор ответов).