для заказчика). При этом события обладают следующими свойствами:
• События должны быть «тонкими». Исключается передача в составе одного события больших объемов данных, создающих избыточную нагрузку на инфраструктуру.
• Фиксация событий. События отражают уже случившиеся изменения в микросервисах или системах, а не являются отложенными командами на исполнение.
• Независимость сериализации. Поскольку микросервисы (группы микросервисов) представляют собой независимые единицы развертывания, то взаимодействие между ними предполагает сериализацию данных. Возможность выбора различных технологий реализации микросервисов диктует необходимость отделения правил и технологий сериализации событий от микросервисов – в противном случае гибкость ИТ-ландшафта будет нарушена.
• Наличие реестра схем. Общая структура событий и возможность быстрого получения ее, в том числе во время исполнения разработанных решений, позволит снизить число ошибок при выполнении микросервисов и информационных систем в течение их жизненного цикла.
• Валидация событий. При взаимодействии микросервисов и информационных систем между собой посредством EDA возможна публикация событий с некорректной структурой, что особенно актуально для распределенной мелко гранулированной информационной системы. Структуры событий должны проверяться на соответствие схемам для обеспечения надежности.
• Бизнес-ориентированность. События должны отражать значимые изменения в состоянии микросервисов и информационных систем. В противном случае в архитектуре возникнут риски создания большого количества незначимых событий, не несущих ценности, но снижающих прозрачность ИТ-ландшафта и создающих избыточную нагрузку на инфраструктуру.
• Мониторинг и отладка. Событийная инфраструктура должна обеспечивать мониторинг создаваемых событий и реакции на них, отладку выявляемых ошибок на максимально раннем этапе.
• Возможность самопотребления. Микросервисы могут сами реагировать на опубликованные ими события. Такая возможность должна обеспечиваться при реализации.
Пример решения, выстроенного в соответствии с концепциями микросервисной архитектуры, продуктового подхода и EDA, представлен на Рисунке 10.
Рисунок 10. Пример продуктовой микросервисной архитектуры в сочетании с EDA
На Рисунке 10 показаны два банковских продукта, автоматизируемых в соответствии с принципами микросервисной архитектуры и EDA. Основной интеграционный поток осуществляется посредством публикации событий, управление которыми осуществляет платформа событийного обмена, представляющая собой внешний по отношению к микросервисам технический компонент. Отличие указанной платформы от ESB-решений эпохи
