5.6.2.2. Настройка взаимодействия серверов Middleware

Сервера Middleware могут поддерживать общие списки пользовательских сессий и других объектов, а также координировать сброс кэшей. Для этого достаточно на каждом их них включить свойство приложения cuba.cluster.enabled. Пример файла app_home/local.app.properties:

cuba.cluster.enabled = true

cuba.webHostName = host3
cuba.webPort = 8080
cuba.webContextName = app-core

Для серверов Middleware обязательно нужно указать правильные значения свойств cuba.webHostName и cuba.webPort для формирования уникального Server Id.

Механизм взаимодействия основан на библиотеке JGroups. Платформа содержит два конфигурационных файла для JGroups:

  • jgroups.xml - стек протоколов, основанный на UDP, пригодный для работы в локальной сети с разрешенными широковещательными сообщениями. Данная конфигурация используется по умолчанию.

  • jgroups_tcp.xml - стек протоколов, основанный на TCP, пригодный для работы в любой сети. Он требует явного указания адресов узлов кластера в параметрах TCP.bind_addr и TCPPING.initial_hosts. Для использования данной конфигурации настройте свойство приложения cuba.cluster.jgroupsConfig.

    Если между серверами middleware имеется firewall, не забудьте настроить на нем доступные порты в соответствии с выбранными настройками JGroups.

Для настройки параметров JGroups для вашего окружения скопируйте подходящий файл jgroups.xml из корня архива cuba-core-<version>.jar в корень модуля core вашего проекта (в каталог src) или в каталог tomcat/conf/app-core, и настройте его нужным образом.

Программный интерфейс для взаимодействия в кластере Middleware обеспечивает бин ClusterManagerAPI. Его можно использовать в приложении - см. JavaDocs и примеры использования в коде платформы.

Синхронная репликация пользовательских сессий

По умолчанию все сообщения JGroups отправляются в кластер асинхронно. Это означает, что код Middleware возвращает ответ клиентскому слою раньше того момента, когда кластерное сообщение будет получено другими узлами кластера.

Подобное поведение улучшает время ответа системы, однако оно может вызвать проблемы с балансировщиками запросов между клиентским слоем и Middleware, использующими стратегию round-robin (такими как NGINX или Kubernetes). А именно: запрос на вход в систему (логин) с веб-клиента возвращается раньше, чем новая пользовательская сессия полностью реплицирована другим узлам кластера. Последующий вызов сервиса среднего слоя с веб-клиента может быть направлен стратегией round-robin на другой узел среднего слоя, где этот вызов упадет с ошибкой NoUserSessionException, поскольку этот узел кластера еще не получил новую пользовательскую сессию.

Чтобы избежать ошибок NoUserSessionException при использовании round-robin балансировщика с кластером Middleware, новые пользовательские сессии, создаваемые при логине в систему, должны реплицироваться синхронно. Установите следующие свойства в файле app.properties (или app_home/local.app.properties на конечном сервере):

cuba.syncNewUserSessionReplication = true

# также если вы используете аддон REST API
cuba.rest.syncTokenReplication = true