С быстрым развитием мобильного интернета и интернета все больше приложений нуждаются в обработке больших объемов данных и большом количестве одновременных запросов. Традиционные программные архитектуры не могут удовлетворить эти потребности, поэтому некоторые новые архитектурные стили начинают привлекать внимание. Событийно-ориентированная архитектура (EDA) становится популярным выбором благодаря своей эффективности, масштабируемости и гибкости. В этой статье рассматриваются преимущества и проблемы событийно-ориентированной архитектуры в практических приложениях.

Обзор событийно-ориентированной архитектуры

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

По сравнению с традиционной моделью запрос-ответ, метод обработки событийно-ориентированной архитектуры отличается. Традиционная модель запрос-ответ основана на транзакциях, когда клиент инициирует запрос, сервер его обрабатывает и затем возвращает ответ. Событийно-ориентированная архитектура основана на сообщениях, когда система асинхронно отправляет сообщения заинтересованным компонентам для обработки, когда происходит событие. Этот асинхронный метод обработки делает систему более гибкой, масштабируемой и эффективной.

Преимущества событийно-ориентированной архитектуры

Масштабируемость

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

Эффективность

Событийно-ориентированная архитектура улучшает эффективность обработки системы. Поскольку события асинхронны, компоненты могут немедленно обрабатывать события, когда они происходят, без ожидания ответов на запросы. Этот асинхронный метод обработки повышает скорость реакции системы и пропускную способность.

Когда классы или компоненты имеют высокую связанность, их сопряженность должна быть низкой. Когда компоненты нуждаются в сотрудничестве, например, когда компонент A должен вызвать логику в компоненте B, естественный способ – напрямую вызвать метод в компоненте B. Однако A должен быть осведомлен о существовании B, что делает систему сложнее для изменения и поддержки. Поэтому для предотвращения такого прямого сопряжения можно использовать события.

Использование событий для разделения компонентов имеет другие преимущества. Если есть команда, отвечающая только за компонент B, им не обязательно общаться с командой, отвечающей за компонент A. Они могут независимо реагировать на изменения логики компонента A. Это позволяет обеим командам развиваться независимо, делая систему приложений более гибкой.

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

Проблемы в практических приложениях

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

Существует три сценария использования событий:

1. Разделение компонентов

2. Выполнение асинхронных задач

3. Отслеживание изменений состояния (журналы аудита)

Разделение компонентов (Микросервисы)

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

Выполнение асинхронных задач

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

Отслеживание изменений состояния (журналы аудита)

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

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