Шаг 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). А если достаточно, чтобы запрос обработал любой из экземпляров функциональной роли, тогда необходимо выбрать доступный. Если вдруг неудача, то например, взять следующий и исполнить запрос снова – это уже зависит от контекста и может содержать транзакции.

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

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

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