Микросервис для управления CMMN, BPMN процессами.
Предъявляемые требования:
- Отказоустойчивость. При выходе из строя любого узла системы работоспособность должна сохраняться.
- Сохранность данных. При полной или частичной потере данных на одном из узлов хранилища данные в системе не должны быть потеряны.
- Горизонтальное масштабирование. При росте количества процессов должна быть возможность горизонтального расширения за счет увеличения количества узлов в кластере, чтобы избежать деградации времени выполнения запросов с увеличением времени жизни системы. Старые процессы, которые уже давно завершились не должны оказывать негативное влияние на активные.
В качестве хранилища для данных выбрана NoSQL БД MongoDB.
Схема связей микросервиса ECOS Process в случае MongoDB:
В качестве хранилища для данных в будущем может быть выбрана NoSQL БД Cassandra, которая сможет решить сразу несколько поставленных задач:
- Автоматическая репликация данных на заданное количество узлов (Сохранность данных)
- Все ноды в кластере Cassandra являются равнозначными. Мастер отсутствует (Отказоустойчивость)
- Кластер Cassandra можно гибко конфигурировать и добавлять новые ноды в уже работающую систему (Горизонтальное масштабирование)
Схема связей микросервиса ECOS Process, в случае кластера Cassandra:
Особенности:
- В Enterprise конфигурации мы получаем 3 уровня горизонтального масштабирования - хранилище, gateway для доступа к хранилищу и кластер stateless микросервисов ECOS Process
- Так как микросервисы ECOS Process не хранят состояние мы можем отправлять запрос от пользователя на любой из них. Для синхронизации действий между инстансами ECOS Process используется Hazelcast
- Описание процессов хранится во внешнем микросервисе ECOS Apps, который у нас уже реализован и версионирует любые изменения в процессах
- Интеграция с внешними событиями осуществляется через очередь сообщений RabbitMQ.
- Cassandra настраивается на QUORUM Read/Write (N/2 + 1), где N - количество узлов Cassandra. Это означает что запись считается успешной если большинство нод в кластере подтвердили, что запись произошла. Для чтения так же требуется, чтобы большинство нод вернуло актуальные данные. Такая настройка позволяет избежать ситуаций когда сетевые проблемы между нодами кластера приводят к их рассинхронизации.
- Администратор через центральную конфигурацию может настраивать ECOS Process для подключения к кластеру Cassandra
В NoSQL решении нет полноценных транзакций и для гарантии сохранности данных состояние процесса описывается как неизменяемое. При этом каждое состояние процесса хранится как отдельная версия. В инстансе процесса мы только меняем ссылку на новое состояние, после того, как все активности успешно завершились.
Кроме сохранности данных это так же позволяет производить возврат процесса в любое из предыдущих состояний и очень помогает в случае возникновения нештатных ситуаций.
Транзакция в ECOS Process начинается, когда происходит какое-то событие (например, «Создан Договор») или при поступлении команды (например, «Завершить задачу»).
При возникновении события мы проверяем всех подписчиков на это событие и для каждого из них проверяем условия, если они есть. В случае, если условия не прошли проверку, мы заканчиваем обработку события. Когда условия выполнены, мы запускаем необходимую команду. Далее обработка идет также, как в случае, если в микросервис сразу пришла команда.
При поступлении команды для выполнения действия в процессе мы читаем состояние процесса, производим ряд переходов и действий согласно описанию процесса и, если все операции прошли успешно, то создаем в БД новую версию состояния процесса, после чего меняем ссылку в инстансе процесса на новое состояние. Если в ходе транзакции возникали внешние события или внешние команды, то по завершении транзакции мы отправляем их в RabbitMQ.