Описание микросервиса Process и предпосылки

Микросервис для управления CMMN, BPMN процессами.

Предъявляемые требования:

1. Отказоустойчивость. При выходе из строя любого узла системы работоспособность должна сохраняться.

2. Сохранность данных. При полной или частичной потере данных на одном из узлов хранилища данные в системе не должны быть потеряны.

3. Горизонтальное масштабирование. При росте количества процессов должна быть возможность горизонтального расширения за счет увеличения количества узлов в кластере, чтобы избежать деградации времени выполнения запросов с увеличением времени жизни системы. Старые процессы, которые уже давно завершились не должны оказывать негативное влияние на активные.

В качестве хранилища для данных выбрана NoSQL БД MongoDB.

Схема связей микросервиса ECOS Process в случае MongoDB:

В качестве хранилища для данных в будущем может быть выбрана NoSQL БД Cassandra, которая сможет решить сразу несколько поставленных задач:

1. Автоматическая репликация данных на заданное количество узлов (Сохранность данных)

2. Все ноды в кластере Cassandra являются равнозначными. Мастер отсутствует (Отказоустойчивость)

3. Кластер Cassandra можно гибко конфигурировать и добавлять новые ноды в уже работающую систему (Горизонтальное масштабирование)

Схема связей микросервиса ECOS Process, в случае кластера Cassandra:

Особенности:

1. В Enterprise конфигурации мы получаем 3 уровня горизонтального масштабирования - хранилище, gateway для доступа к хранилищу и кластер stateless микросервисов ECOS Process

2. Так как микросервисы ECOS Process не хранят состояние мы можем отправлять запрос от пользователя на любой из них. Для синхронизации действий между инстансами ECOS Process используется Hazelcast

3. Описание процессов хранится во внешнем микросервисе ECOS Apps, который у нас уже реализован и версионирует любые изменения в процессах

4. Интеграция с внешними событиями осуществляется через очередь сообщений RabbitMQ.

5. Cassandra настраивается на QUORUM Read/Write (N/2 + 1), где N - количество узлов Cassandra. Это означает что запись считается успешной если большинство нод в кластере подтвердили, что запись произошла. Для чтения так же требуется, чтобы большинство нод вернуло актуальные данные. Такая настройка позволяет избежать ситуаций когда сетевые проблемы между нодами кластера приводят к их рассинхронизации.

6. Администратор через центральную конфигурацию может настраивать ECOS Process для подключения к кластеру Cassandra

В NoSQL решении нет полноценных транзакций и для гарантии сохранности данных состояние процесса описывается как неизменяемое. При этом каждое состояние процесса хранится как отдельная версия. В инстансе процесса мы только меняем ссылку на новое состояние, после того, как все активности успешно завершились.

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

Жизненный цикл транзакции с запущенным процессом в ecos-process

Транзакция в ECOS Process начинается, когда происходит какое-то событие (например, «Создан Договор») или при поступлении команды (например, «Завершить задачу»).

При возникновении события мы проверяем всех подписчиков на это событие и для каждого из них проверяем условия, если они есть. В случае, если условия не прошли проверку, мы заканчиваем обработку события. Когда условия выполнены, мы запускаем необходимую команду. Далее обработка идет также, как в случае, если в микросервис сразу пришла команда.

При поступлении команды для выполнения действия в процессе мы читаем состояние процесса, производим ряд переходов и действий согласно описанию процесса и, если все операции прошли успешно, то создаем в БД новую версию состояния процесса, после чего меняем ссылку в инстансе процесса на новое состояние. Если в ходе транзакции возникали внешние события или внешние команды, то по завершении транзакции мы отправляем их в RabbitMQ.