Camunda: архитектура и решения для высокопроизводительного динамического мультитенантного приложения

Я отвечаю за создание сложной системы для своей компании, и после некоторых исследований решил, что Camunda соответствует большинству моих требований. Но некоторые из моих требований не являются общими, и после прочтения руководства я понял, что есть много способов сделать то же самое, поэтому я надеюсь, что этот вопрос прояснит мои мысли, а также послужит базовым вопросом для всех, кто хочет построить что-то похожее.

Прежде всего, я планирую создать конкретное приложение поверх Camunda BPM. Он будет использовать рабочий процесс и BPM, но не обязательно все, что предоставляет BPM / Camunda. Это означает, что в мои планы не входит использование большей части веб-приложений, поставляемых в комплекте с Camunda (задачи, моделлер ...), по крайней мере, для конечных пользователей. И чтобы усложнить задачу, он должен поддерживать несколько арендаторов ... динамически.

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

Вот так:

  • Единое приложение, построенное на базе Camunda BPM
  • Высокая производительность
  • Рабочая нагрузка (10 тыс. Экземпляров новых процессов в день через несколько месяцев).
  • Пользователи (начиная с 1k, ожидается ~ 50k).
  • Несколько арендаторов (начиная с 10, ожидается ~ 1 тыс.)
  • Динамическое управление арендаторами (создание, развертывание определений процессов)
  • Он будет развернут в кластере
  • PostgreSQL
  • Желательно WildFly 8.1

После некоторых исследований это мои мысли

  • Приложение с одним процессом
  • Один Process Engine на каждого арендатора
  • Изоляция данных с несколькими арендаторами: уровень схемы или таблицы.
  • Кластеризация (2 узла) сначала для обеспечения высокой доступности и добавление дополнительных узлов, когда количество клиентов и рабочая нагрузка начинают расти.

Сомнения

  • Должен ли я позволить camunda управлять моими пользователями / группами или лучше управлять этим в моем приложении? В этом случае могу я сказать Камунде: «Пользователь X выполнил задачу Y», даже если Камунда не знает о существовании пользователя X?
  • А как насчет динамической мультиарендности? Можно ли создавать клиентов «на лету» и сохранять их в течение долгого времени даже после перезапуска сервера приложений? А как насчет повторного развертывания процессов после перезапуска?
  • После чего мне следует подумать о разделении движков по узлам? Трудно понять, как я собираюсь сделать это с помощью динамической мультитенантности, но, более того ... Правильный ли это способ справиться с высокой рабочей нагрузкой и растущим числом арендаторов?
  • Должен ли я позаботиться о чем-то еще в кластерной среде, настроив только одно приложение процесса?

Я не исключаю использования только одного клиента, одного механизма процесса и логической обработки всего, что связано с арендаторами в моем приложении, но я понимаю, что это может быть очень (ОЧЕНЬ!) Обременительным.

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


multi-tenant camunda
person Cristian    schedule 18.02.2015    source источник
comment
Я думаю, что это лучше подходит для форума, чем для SO, поскольку я не вижу, каким может быть принятый ответ ... это больше похоже на хорошее начало обсуждения ...   -  person Jan Galinski    schedule 19.02.2015
comment
См. Сообщение на форуме: groups.google.com/forum/ #! topic / camunda-bpm-users / ivKu-enuUXE   -  person thorben    schedule 19.02.2015

Ответы (1)


arrow_upward
2
arrow_downward

1. Должен ли я позволить camunda управлять моими пользователями / группами или лучше управлять этим в моем приложении? В этом случае могу я сказать Камунде: «Пользователь X выполнил задачу Y», даже если Камунда не знает о существовании пользователя X?

Да, вы можете выбрать свое приложение для управления пользователями и сообщить Камунде, что задача выполнена пользователем, о котором Камунда не знает. Точно так же вы можете заставить Camunda назначать задачи пользователям, о которых он вообще не знает. Это делается путем реализации их интерфейса org.camunda.bpm.engine.impl.identity.ReadOnlyIdentityProvider и сообщения конфигурации о вашей реализации.

PS: Если вам не нужно все приложение, поставляемое с Camunda, я бы даже посоветовал вам встроить движок Camunda в ваше приложение. Это можно сделать легко, и у них есть хорошая документация для своих API-интерфейсов Java. И это легко достижимо.

2. А как насчет динамической мультиарендности? Можно ли создавать клиентов «на лету» и сохранять их в течение долгого времени даже после перезапуска сервера приложений? Как насчет повторного развертывания процессов после перезапуска?

да. Можно динамически добавлять арендаторов. При перезапуске движка или приложения вы можете выбрать повторное развертывание / или просто использовать существующие развернутые процессы. Даже при повторном развертывании процесса, если вы хотите, чтобы Camunda создавал новую версию процесса, только если в процессе есть изменения, это также возможно. См. Свойство enableDuplicateFiltering для их DeploymentBuilder.

3. После чего мне следует подумать о разделении движков по узлам? Трудно понять, как я собираюсь сделать это с помощью динамической мультиарендности, но, более того ... Правильный ли это способ справиться с высокой рабочей нагрузкой и растущим числом арендаторов?

По моему опыту, это возможно. Здесь вам нужно отслеживать различные параметры, такие как память, количество обслуживаемых запросов, количество доступных открытых подключений и т. Д., А затем соответственно добавлять или удалять узлы. С AWS это будет намного проще, поскольку у них уже есть некоторые из этих инструментов для динамического масштабирования узлов ввода / вывода. Но, тем не менее, я сделал это только с Camunda как встроенным приложением (ями) движка.

person Sarath K S    schedule 28.03.2017