CC BY
10
УДК 004.6
АРХИТЕКТУРА МЕТАДАННЫХ СЕРВИСА ПОТОКОВОЙ ОБРАБОТКИ СОБЫТИЙ И ИСПОЛНЕНИЯ АКТИВНЫХ ПРАВИЛ
С. В. Шибанов1, А. С. Гусаров2, Я. С. Шлепнев3
1'2'3Пензенский государственный университет, Пенза, Россия
1serega@pnzgu.ru 2alexandergusarovv@gmail.com 3yaroslav.shlepnev@yandex.ru
Аннотация. Рассматриваются вопросы организации метаданными сервиса потоковой обработки событий и исполнение активных правил. Приведено описание механизмов управления, транспортировки и кэширования метаданных.
Ключевые слова: метаданные, потоковая обработка событий, ЕСА, активные правила, микросервисная архитектура, метамодель
Для цитирования: Шибанов С. В., Гусаров А. С., Шлепнев Я. С. Архитектура метаданных сервиса потоковой обработки событий и исполнения активных правил // Вестник Пензенского государственного университета. 2023. № 3. С. 95-103.
Введение
Проблема обработки данных становится все более важной, поскольку объем генерируемых и собираемых данных продолжает расти беспрецедентными темпами. Эти данные могут поступать из различных источников, таких как социальные сети, устройства Интернета вещей, объекты на производственных предприятиях и т.д. Зачастую такие данные генерируются в режиме реального времени, что затрудняет их обработку традиционными методами. Потоковая обработка данных позволяет проводить анализ и обработку данных по мере их возникновения, обнаруживать различные события в реальном масштабе времени. Механизм активных правил позволяет оперативно реагировать на те или иные события.
Сервис потоковой обработки событий получает данные, соответствующие элементарным событиям, от внешних наблюдаемых систем. На основе полученных данных с применением соответствующих алгоритмов обнаруживаются сложные, агрегированные и составные события. Механизм активных правил позволяет соответствующим образом реагировать на события и их контекст [1]. Сервис может быть использован в различных отраслях, включая производство, контроль и управление техническими объектами, розничную торговлю, финансы и пр. Сервис может быть применен на промышленных предприятиях для управления производственными линиями или в медицинских учреждениях для наблюдения за пациентами. Он может помочь предприятиям и организациям управлять огромными объемами данных, которые они генерируют, управлять бизнес-
© Шибанов С. В., Гусаров А. С., Шлепнев Я. С., 2023
95
процессами, своевременно обнаруживать неисправности и собирать статистические данные о работе конкретных элементов инфраструктуры. Сервис идентифицирует важные события из наблюдаемых систем и обеспечивает реагирование в режиме реального времени на события от бизнес-приложений или другие сторонних служб.
Обработка событий осуществляется с помощью технологии Event Stream Processing (ESP), которая позволяет идентифицировать часто встречаемые шаблоны поведения системы и обнаруживать зацикленные сценарии, конфликты взаимодействия компонентов системы и иные проблемные ситуации [2].
Метамодель сервиса
Метамодель сервиса включает спецификации различных систем и их компонентов, событий и активных правил, а также описание процедур обработки событий, формирования управляющих воздействий и т.д. [3].
Множество внешних систем мониторинга (Monitoring Systems) Sm = {Smi, Sm2, ..., Smn}, где n - количество наблюдаемых систем. Каждая система мониторинга может содержать вложенные системы, образуя уровни иерархии.
Объект наблюдения (Monitoring Objects) может быть включен в систему мониторинга, он является непосредственным источником событий и представляется в виде множества Omi = {Om1i, Om2i, ..., Omki}, где к - количество объектов наблюдения в í-й системе или подсистеме.
Множество внешних систем управления (Control Systems) Se = {Sci, SC2, ..., Sci}, где l - количество подключенных систем управления. Системы управления могут иметь несколько подсистем, и каждая подсистема может включать в себя различные объекты управления (Control Objects).
Элементарное событие связано с получением какой-либо информации от сторонних систем мониторинга в определенный момент времени. Элементарные события представляются в виде кортежа e_primitive = <PEid, Context, S, Г, t>, где PEid - уникальный номер элементарного события; Context - набор метаданных, описывающих событие; S - объект-источник события; Т - тип события; t - временные метки возникновения события.
Агрегированные события представляются следующим кортежем e_agregated = <AEid, Context, Q, T, tb, te> где AEid - уникальный номер агрегированного события; Context - набор метаданных, описывающих событие; Q - шаблон агрегации; Т - тип события; tb, te - временные метки начала и завершения события (te > tb).
Составное событие - это сочетание элементарных и/или сложных событий с использованием ограничений или логических ассоциаций. Составное событие может быть представлено в виде кортежа e_composite = <CEid, Context, C, T, tb, te>, где CEid - уникальный номер составного события; Context - набор метаданных, описывающих событие; С - правила ассоциации элементарных и других сложных событий; Т - тип события; tb, te - время начала и время окончания события (te > tb).
Реакция сервиса на возникновение экземпляра события происходит при помощи выполнения одного или нескольких активных правил, связанных с этим событием. Помимо стандартного правила ECA, также могут быть определены другие типы активных правил. Это связано с необходимостью сократить количество активных правил и удовлетворить требования более сложных бизнес-процессов.
Расширенное правило выглядит следующим образом: r = <e, c, {abase, aait}>, где abase - основное действие, которое выполняется в случае истинности условия; aait - альтернативное действие, которое выполняется в случае ложности условия. Расширенное ECA-правило - это комбинация двух активных правил, которые являются взаимоисклю-
чающими на основе условия, в одном правиле. Этот тип правила аналогичен структуре if-then-else в языках программирования.
Присутствуют многоблочные активные правила. Для них могут быть заданы несколько вариантов обнаружения r = <{еъ Ci, ai}, ...,{en, Cn, an}>, где еъ ..., en - множество результирующих событий для сложного события; Ci, ..., Cn - множество условий, соответствующих множеству результирующих событий; ai, ..., an - множество действий, соответствующих множеству результирующих событий.
Многофункциональное активное правило, которое выполняет множество действий в ответ на появление события при выполнении условия, определяется как r = <e, c, A>, A = {ai, ..., ak} - множество экземпляров выходных действий, применяемых к управляемым объектам.
Структура метаданных сервиса
В сервисе потоковой обработки событий метаданные - это информация, описывающая свойства и характеристики событий или активных правил. Эта информация может включать такие сведения, как тип события, временная метка, источник или любая другая дополнительная информация, которая имеет отношения к обработке события или исполнения правила.
При потоковом получении событий основной набор метаданных приходит в связке с самим событием. Одним из способов использования метаданных в сервисе является исполнение активных правил. Активные правила - это предопределенные действия, которые являются реакцией на возникновение заданных событий. Активные правила реализованы на основе парадигмы ECA (event-condition-action): события (event), которое поступает от сторонних наблюдаемых систем; условия (condition), в зависимости от выполнения которого будет принято решение о запуске действия; действия (action), которое будет запущено если событие соответствует условиям.
Действия применяются по отношению к управляемым системам. Они могут включать различные действия, начиная от реализации обычного триггера или преобразования данных события, заканчивая запуском сложного бизнес-процесса внешней системы.
Сервис обрабатывает несколько различных типов событий: простые (атомарные) и сложные. Простые, или атомарные, события - это отдельные события, которые являются самодостаточными и не зависят от каких-либо других событий, поступают от наблюдаемой системы и имеют собственный контекст.
Сложные события подразделяются на агрегированные и составные события. Агрегированные события характеризуются наличием шаблона агрегации. Эти события формируются путем объединения нескольких простых событий, которые имеют общую структуру или свойства. Шаблон агрегирования определяет правила и критерии для группировки и комбинирования этих событий. Составные события формируются на основе связей других событий. Эти события более сложны по своей природе и могут потребовать сочетания простых и агрегированных событий.
Отдельные метаданные описывают ассоциации между событиями и активными правилами. Эти ассоциации делятся на две категории - «От события к активному правилу» и «От активного правила к событию», описывающие контекст и значение событий, что позволяет сервису предпринять соответствующие действия на основе механизма активных правил.
Также поддерживаются метаданные для предоставления информации о конкретной наблюдаемой или управляемой системе. Такие метаданные описывают уровни доступа пользователей для модерирования системы, взаимоотношения с другими система-
ми, иерархии систем, общие конфигурации того, как система реагирует на различные шаблоны поведения.
Каждая система включает в себя набор компонентов, от которых поступают события. Метаданные для этих компонентов описывают роли и конфигурацию каждого компонента в системе, важность и приоритет событий, исходящих от конкретного компонента, системы, которые взаимодействуют с этим компонентом, различные статистические данные, такие как количество полученных событий и среднее время обработки.
Как и любое другое многопользовательское приложение, сервис имеет набор пользовательских метаданных, которые включают в себя: метаданные учетных записей и метаданные ролей доступа. Крайне важно иметь в виду, что конфиденциальные пользовательские данные, такие как пароли, хранятся в зашифрованном виде для обеспечения безопасности. Шифрование достигается с помощью криптографических хэш-функций. Они обеспечивают безопасное хранение пользовательских данных и авторизацию пользователей во время взаимодействия с сервисом.
На этапе реализации структура метаданных отображается в реляционную схему данных [4].
Архитектура программных средств управления метаданными сервиса
Архитектура сервиса основана на сочетании событийно-ориентированного и микросервисного подходов (рис. 1), что обеспечивает масштабируемость, быструю транспортировку данных в режиме реального времени, отказоустойчивость и высокую доступность. События отправляются в микросервисы через очереди брокера сообщений, который собирает и направляет сообщения в соответствии с предопределенной логикой [5].
Рис. 1. Архитектура сервиса потоковой обработки событий
98
Архитектура обеспечивает повышенную автономность каждого компонента системы, отделяя логику независимых компонентов друг от друга. Также данный подход позволяет настраивать взаимодействие между компонентами, написанными на разных языках программирования. В зависимости от увеличения нагрузки компоненты системы могут масштабироваться независимо друг от друга. Сбой одного компонента не окажет критического влияния на работу всего сервиса.
Программное обеспечение сервиса можно разделить на четыре основных уровня: управление метаданными, разработка алгоритмов и систем взаимодействия, обработка событий и исполнение активных правил, а также публикация/подписка на бизнес-приложения [6].
Сервис поддерживает три группы репозиториев метаданных:
- центральный репозиторий, который содержит спецификации событий и активных правил, информацию о наблюдаемых системах и их компонентах, информацию о системах управления, важные промежуточные результаты работы, правила обработки событий и формирования управляющих воздействий, пользовательские метаданные, результаты анализа событий и правил и многое другое;
- локальные оперативные репозитории микросервисов, которые содержат информацию, необходимую для функционирования отдельного компонента системы;
- репозиторий журнализации, используемый для сбора и хранения диагностической информации о работе сервиса.
Центральный репозиторий метаданных представляет собой реляционную базу данных PostgreSQL (рис. 2). Доступ к репозиторию метаданных осуществляется при помощи средств SequalizeORM.
Э RoleComponent
Eg и
uuid
явс neme varchdr(255) ЯВС description varchsr(255) O createdAt timestamptz O updated At timestamptz
Э С o mpo nentRoleC o mp o rient
EJj id uuid
Pâ componentld uuid
Hj roleComponentld uuid
Q createdAt timestamptz
O updatedAt timestamptz
S3 Component
gid uuid
ftEt code varchar(255) «с description varchar(255) a Mid uuid 0 system! d uuid ^ createdAt timestamptz 9 updatedAt timestamptz
3 Syster
Sa
duc code varchar(255)
яос name varch«r(255)
Q parent Id uuid
O createdAt timestamptz updatedAt timestamptz
ir.
H ContextParam EJj id uuid
abc code varchar(255) "ВС name varchar(255) овс description varchar(255) ЯСС dataType varchar(255) О createdAt timestamptz Q updatedAt timestamptz
3 LvlComponent
an
uuid varehar(255] nsc description varchar(255) 1 parentld uuid
Q createdAt timestamptz О updatedAt timestamptz
S И
uuid
fisc codePair varchar(255) S componentld uuid
Q eventld uuid
Q createdAt timestamptz О updatedAt timestamptz
m Event
Ш и uuid
явс code varchar(255)
явс description varchar[255)
вис categoryEvent enum_Event_categoryEvent
contextParamld uuid
9 createdAt timestamptz
О updatedAt timestamptz
SB ActrveRuleEvent
uuid
яое typeBind enum_ActtveRuleEvent_typeBind
S eventld uuid
S activeRulefd uuid
0 createdAt timestamptz
О updatedAt timestamptz
EB AtomicAggiegationEvent El id uuid
Q a ggregationEvent I d uuid
Q atomicEventld uuid
О createdAt timestamptz
О updatedAt timestamptz
EB AggregationEvent
@¡d uuid
s eventld uuid
Juh aggregationQuery jsonb
net gnixWindowStart varchar(255)
яое unixWindowEnd varchar(255)
O createdAt timestamptz
О updatedAt timestamptz
EB Complex Event
Э eventld uuid
мм, templateEvent jscnb О createdAt timestamptz О updatedAt timestamptz
9 InboundComplexEvent
uuid
Я complex Eventld uuid
РЭ eventld uuid
О createdAt timestamptz Q updatedAt timestamptz
ffl Role
S3« uuid
явс name enum.Rote.name
явс description varchar(255)
Q createdAt timestamptz
О updatedAt timestamptz
PI userld uuid Pi roleld uuid
fflUser
El id uuid
явс code varchar(255) явс email varchar(2SS) явс password varchar(25S) ABC refreshLink varchar(2SS) Q createdAt timestamptz Q updatedAt timestamptz
aa
uuid
noc code varchar(255J ne с description varehar(255) 123 priority int4
im condition jsonb
ji^M action jsonb
О createdAt timestamptz О updatedAt timestamptz
luid
S userld uuid
RDC refresh Token varchar(255) 9 createdAt timestamptz ^ updatedAt timestamptz
ffl CodeCounter
El« uuid
явс name enum_CodeCounter_name
123 counter int8
О createdAt timestamptz
О updatedAt timestamptz
Рис. 2. Реляционная схема центрального репозитория метаданных
Конструирование событий и активных правил осуществляется через портал управления, который использует протокол HTTP для доступа к REST-серверу (рис. 3). Портал управления метаданными позволяет создавать составные и агрегированные события,
объявлять новые правила или редактировать существующие, а также устанавливать различные ассоциации между событиями, правилами или системами в целом.
Рис. 3. Архитектура программных средств управления метаданными
Контроль и управление метаданными осуществляется через сервер REST, который отвечает за своевременную передачу новых или обновленных метаданных в микросервисы, которые на их основе обрабатывают поступающие события и инициируют выполнение правил. REST-сервер предоставляет доступ к созданию новых метаданных, которые могут быть созданы автоматически через механизм «публикация/подписка» на новые бизнес-приложения или вручную администратором [7].
Обращение к центральному репозиторию происходит во время всего функционирования сервиса. Центральный репозиторий развернут при помощи средств PostgreSQL. Благодаря PostgreSQL обеспечиваются надежность хранения метаданных и быстрая скорость обмена большим набором информации. Он поддерживает расширенные типы данных, такие как массивы, hstore (хранилище ключей и значений) и JSON, что делает его хорошо подходящим для хранения метаданных под сложные и агрегированные события [8].
Доставка метаданных в локальные репозитории микросервисов
Каждый микросервис следует модели «База данных на сервис» («Database Per Service») и обладает собственным локальным хранилищем [9], что повышает отказоустойчивость и независимость каждого элемента архитектуры. Задача согласования локальных хранилищ с центральным репозиторием решается с помощью специального сценария, который сводит к минимуму время ожидания запросов метаданных без ущерба для их актуальности.
Доставку метаданных из центрального репозитория обеспечивает REST-сервер. Он на основании SQL запросов получает метаданные, которые в дальнейшем будут отправлены микросервисам. Каждый микросервис имеет свой собственный репозиторий Redis [10], который представляет собой резидентную NoSQL базу данных. Когда микросервисы получают метаданные, они сначала фиксируют их в своем репозитории. Затем они могут использовать метаданные для различных целей, например, для анализа входного события.
Зачастую Redis используется в качестве базы данных, кэша или посредника сообщений. В работе микросервисов он играет ключевую роль, поскольку позволяет кэширо-вать метаданные, полученные от сервера. Данное программное средство имеет множество преимуществ, рассмотрим основные из них.
Скорость. Redis - это хранилище данных в оперативной памяти. Это делает его намного быстрее, чем традиционные дисковые базы данных, особенно когда дело доходит до операций чтения. Это может быть особенно полезно, когда микросервисам необходимо быстро получить доступ к большим объемам метаданных.
Масштабируемость. Redis обладает высокой степенью масштабируемости и может легко обрабатывать большие объемы данных. Это делает его идеальным выбором для микросервисной архитектуры, где многим сервисам может потребоваться доступ к одним и тем же метаданным для их обработки.
Гибкость. Redis поддерживает широкий спектр структур данных, включая строки, хэши, связанные списки, множества и многое другое. Это упрощает хранение различных типов метаданных и управление ими.
Высокая доступность. Redis поддерживает различные механизмы для достижения высокой доступности, такие как репликация master-slave, Sentinel и Cluster.
Использование данного средства обеспечивает более производительную и масштабируемую архитектуру. Однако Redis также имеет некоторые недостатки, которые следует учитывать:
- ограниченный срок службы. Redis хранит данные в памяти, и это означает, что они могут быть потеряны в случае отключения питания или другого сбоя. Redis поддерживает механизмы сохранения данных, такие как RDB и AOF, которые сохраняют данные на диске и автоматически восстанавливают после сбоя;
- ограничения памяти. Поскольку Redis хранит данные в памяти, объем данных, которые могут быть сохранены, ограничен объемом доступной оперативной памяти. Это может быть проблемой, если объем метаданных очень велик и превышает объем памяти микросервиса.
В целом Redis может быть мощным инструментом для кэширования метаданных в микросервисе. Важно иметь в виду, что этот тип архитектуры имеет свои собственные компромиссы, например, трудность в работе с очень большим набором метаданных сложных событий. Для решения этой проблемы каждый микросервис обладает перечнем необходимых ему для работы метаданных. В архитектуре каждый микросервис выполняет свою задачу и, следовательно, работает со своим набором метаданных. REST-сервер не будет доставлять те данные микросервису, которые он не использует в своих бизнес-процессах.
В сервисе потоковой обработки событий за транспортировку метаданных от REST-сервера до конкретного микросервиса отвечает Apache Kafka. Kafka - это распределенная потоковая платформа, которая обеспечивает отказоустойчивую и масштабируемую транспортировку потоков данных в режиме реального времени.
Каждый набор метаданных имеет свою тему (topic). Темы - это средства, с помощью которых данные организуются и распределяются внутри Kafka. Каждая тема идентифицируется уникальным именем и может рассматриваться как категория или поток
данных. В кластере Kafka темы могут быть реплицированы на несколько серверов для обеспечения отказоустойчивости и высокой доступности.
Микросервисы настраиваются на получение метаданных из одной или нескольких тем. Каждый микросервис может подписаться на одну или несколько тем и получать метаданные, опубликованные в этих темах. Сами данные публикуются REST-сервером или другими микросервисами. Элемент архитектуры, который публикует данные, далее будем называть производителем. Производитель берет метаданные и отправляет их в соответствующую тему в виде сообщений, затем сообщения принимаются потребляющими микросервисами, которые могут обрабатывать их по мере необходимости.
Одним из главных преимуществ использования Kafka для доставки метаданных в микросервисной архитектуре является ее возможность обрабатывать большие объемы данных и обеспечивать высокую пропускную способность. Kafka идеально подходит в тех случаях, где многим микросервисам может потребоваться доступ к одним и тем же наборам данных.
Еще одним преимуществом являются высокая надежность и отказоустойчивость. Kafka хранит все опубликованные сообщения в течение настраиваемого периода времени и реплицирует данные на нескольких серверах, чтобы гарантировать, что они не будут потеряны в случае сбоя. Это делает его надежным средством доставки метаданных в микросервисы. Кроме того, Kafka допускает разделение сервисов и позволяет производителям и потребителям метаданных развиваться независимо, не влияя друг на друга. Это добавляет дополнительный уровень гибкости микросервисной архитектуре.
Заключение
Представлены результаты исследований и разработок, посвященных реализации архитектуры метаданных сервиса потоковой обработки событий с применением механизма активных правил. Показана роль метаданных на всех этапах работы сервиса.
Представлена метамодель сервиса, на основе которой определяются структура и состав метаданных. Приведены архитектурные и сценарные решения программных средств управления метаданными в составе событийно-ориентированной микросервисной архитектуры сервиса.
В настоящее время создан прототип программных средств управления метаданными, в том числе центральный репозиторий метаданных, REST-сервер, пользовательское web-приложение. Выполняются исследования и разработки, направленные на развитие и совершенствование сервиса в целом и механизмов работы с метаданными, в частности, с учетом развития функциональных возможностей, удобства работы пользователей, повышения эффективности функционирования.
Список литературы
1. Шибанов С. В., Скоробогатько А. А., Лысенко Э. В. Интегрированная модель активных правил // Математическое и программное обеспечение систем в промышленной и социальной сферах : Междунар. сб. науч. тр. Магнитогорск : Изд-во Магнитогорского гос. техн. ун-та им. Г. И. Носова, 2011. С. 41-46.
2. Jiang Q., Adaikkalavan R., Chakravarthy S. Towards an Integrated Model for Event and Stream Processing // Technical Report CSE. Texas, 2004. Р. 35.
3. Шибанов С. В., Шлепнев Я. С., Гусаров А. С. Метамодель сервиса потоковой обработки событий // Методы, средства и технологии получения и обработки измерительной информации («Шляндинские чтения-2022») : материалы XIV Междунар. науч.-техн. конф. с элементами науч. шк. и конкурсом науч.-исслед. работ для обучающихся и молодых ученых (г. Пенза, 24-26 октября 2022 г.). Пенза : Изд-во ПГУ, 2022. С. 240-243.
4. Дзюба Е. А., Шибанов С. В., Хмелевской Б. Г. [и др.]. Отображение метаданных в реляционную модель данных // Труды Международного симпозиума Надежность и качество. 2010. Т. 1. С. 295-297.
5. Стопфорд Б. Проектирование событийно-ориентированных систем: Концепции и шаблоны проектирования сервисов потоковой обработки данных с использованием Apache Kafka : пер. с англ. 2-е изд., испр. Иркутск : ITSumma Press, 2019. 175 с.
6. Шибанов С. В., Шлепнев Я. С. Сервис потоковой обработки событий и исполнения активных правил // Математическое моделирование и суперкомпьютерные технологии : тр. XXI Междунар. конф. (г. Нижний Новгород, 22-26 ноября 2021 г.). Н. Новгород : Национальный исслед. Нижегородский гос. ун-т им. Н. И. Лобачевского, 2021. С. 403-407.
7. Шибанов С. В., Курбатова М. Н., Шлепнев Я. С. REST-сервер для реализации портала управления сервисом конструирования и исполнения активных правил // Информационные технологии в науке и образовании. Проблемы и перспективы : сб. ст. по материалам VIII Всерос. межвуз. науч.-практ. конф. (г. Пенза, 17 марта 2021 г.). Пенза : Изд-во ПГУ, 2021. С. 183-185.
8. Obe R., Hsu L. PostgreSQL: Up and Running. Sebastopol : O'Reilly Media, 2017. 312 р.
9. Pattern: Database per service // Microservice Architecture. URL: https://microservices.io (дата обращения: 05.03.2022).
10. Carlson J. L. Redis in Action. MANNING Shelter Island, 2013. 322 р. URL: goodreads. com>book...
Информация об авторах
Шибанов Сергей Владимирович, кандидат технических наук, доцент, доцент кафедры «Математическое обеспечение и применение ЭВМ», Пензенский государственный университет.
Гусаров Александр Сергеевич, магистрант, Пензенский государственный университет.
Шлепнев Ярослав Сергеевич, аспирант, Пензенский государственный университет.
Авторы заявляют об отсутствии конфликта интересов.
