Workflow Event pattern

Зрелость системы в том числе определяется её прочностью и устойчивостью. Если адаптируемость — важное архитектурное свойство системы, то она должна уметь подстраиваться под определенные условия эксплуатации. Сегодня хочу поделиться интересным шаблоном, в который очень хорошо вписывается использование AI/ML.

Контекст

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

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

• Интеграция с внешними системами. Источником событий является сервис, на качество которого мы не можем повлиять. Например, какой-то баг или особенность работы внешней системы, приводящая к нарушению контракта.
• Ручной ввод или частичное заполнение. Корректировка пользовательского ввода или необходимость обогащения события данными. Например, уточнить адрес заказа по GPS-координатам пользователя.
• Некачественная или шумная телеметрия. Показания выходят за допустимый диапазон, и трудно сказать, что это было: случайный выброс или начало нового тренда из-за недели распродаж. Постанализ может сделать алармы более интеллектуальными.
• Первичная отбраковка событий. Основной обработчик производит быструю проверку события на пригодность. Например, грубая/быстрая проверка выявила признаки необходимости блокировки транзакции, и нужна более тщательная проверка.
• Устаревшие справочные данные. Внешние системы продолжают присылать события со ссылкой на устаревшие справочные данные. Чтобы не сломать интеграцию, вместо отказа можно делать автоматическое сопоставление и корректировку.

Проблема

Некорректное событие нарушает workflow его обработки или даже останавливает обработку всего потока событий (этого и всех последующих). Последнее характерно для log-based-брокеров.

Решение

Если основной обработчик (Event Consumer) не может обработать очередное событие, оно направляется на детальный анализ и корректировку (Event Collector). Причиной может послужить, например, исключение при чтении данных события (десериализация, приведение к типу, нарушение формата и т.д.), недостаточность данных, нарушение диапазона допустимых значений и т.д. и т.п. в зависимости от прикладного сценария. Анализ и корректировка выполняется асинхронно, а основной обработчик тем временем переходит к следующему событию в очереди.

Корректировщик (Event Collector) может:

• отбросить событие, как действительно некорректное;
• исправить его и направить на повторную обработку;
• отправить на интеллектуальное исправление (AI/ML Corrector).

Предполагается, что корректировщик (Event Corrector) работает на базе аналитического алгоритма, а интеллектуальное исправление (AI/ML Corrector) производится на базе AI/ML как попытка автоматизировать действия человека, например, сотрудников службы поддержки.

Интеллектуальный корректировщик (AI/ML Corrector) может:

• отбросить событие, как действительно некорректное;
• исправить его и направить на повторную обработку;
• призвать на помощь человека.

Шаги аналитической и интеллектуальной корректировки могут взаимодополнять или заменять друг друга. Также допустимо (и даже разумно), если интеллектуальная корректировка будет вызываться асинхронно.

Плюсы

• Непрерывная обработка потока событий — некорректные события не блокируют поток.
• Возможное увеличение скорости обработки — некорректные события откладываются.
• Улучшение адаптируемости системы — подстройка под реалии.

Минусы

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

• Сделать событие, содержащее все элементы, порядок обработки которых важен. Иначе говоря, мелкие события группируются в одно крупное (batch event), которое либо целиком обрабатывается, либо целиком отправляется на корректировку.
• Сделать корректировку частью конвейера обработки. Однако это уже совершенно другой архитектурный подход.