#Разделение сервисов v1.9.0+

#Введение

Обычно все сервисы приложения NocoBase работают в одном экземпляре Node.js. По мере того как функциональность приложения усложняется с ростом бизнеса, некоторые ресурсоемкие сервисы могут влиять на общую производительность.

Чтобы повысить производительность приложения, NocoBase поддерживает разделение сервисов приложения для их запуска на разных узлах в кластерном режиме. Это позволяет избежать ситуации, когда проблемы с производительностью одного сервиса влияют на все приложение и мешают ему нормально отвечать на запросы пользователей.

Кроме того, это позволяет целенаправленно масштабировать определенные сервисы по горизонтали, повышая эффективность использования ресурсов кластера.

При развертывании NocoBase в кластере различные сервисы можно разделить и развернуть для работы на разных узлах. На следующей схеме показана структура разделения:

#Какие сервисы можно разделить

#Асинхронные рабочие процессы

Ключ сервиса: workflow:process

Рабочие процессы в асинхронном режиме после запуска ставятся в очередь на выполнение. Эти рабочие процессы можно рассматривать как фоновые задачи, и пользователям обычно не нужно ждать возврата результатов. Особенно для сложных и ресурсоемких процессов с большим объемом запусков рекомендуется разделять их для выполнения на независимых узлах.

#Другие асинхронные задачи пользовательского уровня

Ключ сервиса: async-task:process

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

#Как разделить сервисы

Разделение различных сервисов на разные узлы достигается путем настройки переменной среды WORKER_MODE. Эту переменную среды можно настроить в соответствии со следующими правилами:

• WORKER_MODE=<пусто>: Если не настроено или установлено в пустое значение, режим работы совпадает с текущим одноэкземплярным режимом: принимаются все запросы и обрабатываются все задачи. Это совместимо с приложениями, которые ранее не были настроены.
• WORKER_MODE=!: Режим работы — обрабатывать только запросы, не обрабатывая никаких задач.
• WORKER_MODE=workflow:process,async-task:process: Настраивается с одним или несколькими идентификаторами сервисов (разделенными запятыми). Режим работы — обрабатывать только задачи для этих идентификаторов, не обрабатывая запросы.
• WORKER_MODE=*: Режим работы — обрабатывать все фоновые задачи, независимо от модуля, но не обрабатывать запросы.
• WORKER_MODE=!,workflow:process: Режим работы — обрабатывать запросы и одновременно обрабатывать задачи для определенного идентификатора.
• WORKER_MODE=-: Режим работы — не обрабатывать никаких запросов и задач (этот режим требуется внутри рабочего процесса).

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

#Примеры конфигурации

#Несколько узлов с раздельным выполнением

Предположим, у вас есть три узла: node1, node2 и node3. Их можно настроить следующим образом:

• node1: Обрабатывает только пользовательские UI-запросы, настройте WORKER_MODE=!.
• node2: Обрабатывает только задачи рабочего процесса, настройте WORKER_MODE=workflow:process.
• node3: Обрабатывает только асинхронные задачи, настройте WORKER_MODE=async-task:process.

#Несколько узлов со смешанным выполнением

Предположим, у вас есть четыре узла: node1, node2, node3 и node4. Их можно настроить следующим образом:

• node1 и node2: Обрабатывают все обычные запросы, настройте WORKER_MODE=!, а балансировщик нагрузки автоматически распределяет запросы между этими двумя узлами.
• node3 и node4: Обрабатывают все остальные фоновые задачи, настройте WORKER_MODE=*.

#Справочник для разработчиков

При разработке бизнес-плагинов вы можете разделять сервисы, потребляющие значительные ресурсы, в зависимости от требований сценария. Это можно реализовать следующими способами:

1. Определите новый идентификатор сервиса, например, my-plugin:process, для конфигурации переменной среды и предоставьте соответствующую документацию.
2. В бизнес-логике серверной части плагина используйте интерфейс app.serving() для проверки среды и определения, должен ли текущий узел предоставлять определенный сервис на основе переменной среды.

const MY_PLUGIN_SERVICE_KEY = 'my-plugin:process';
// В серверном коде плагина
if (this.app.serving(MY_PLUGIN_SERVICE_KEY)) {
  // Обработка бизнес-логики для этого сервиса
} else {
  // Не обрабатывать бизнес-логику для этого сервиса
}