Неотъемлемым атрибутом таких компаний, как Uber, Twitter и LinkedIn, являются обновления в режиме реального времени: уведомления, сопровождающие вашу поездку, в Uber, твиты друзей и полезные советы отраслевых экспертов, которые можно получить и переслать в течении нескольких секунд. Как только информация попадает в сеть, она сразу становится доступной для всех вокруг. Пользователям всегда будет нравится эта простая и быстрая доступность информации - они всегда находятся в поиске подобных улучшений качества их жизни.

Чтобы удовлетворять постоянно растущие требования потребителей, многие компании вынуждены отказываться от традиционных структур “запрос-ответ” (Request-Response) в пользу событийно-ориентированных архитектур (Event Driven Architecture).

Бывший вице-президент AWS и по совместительству выдающийся инженер Тим Брэй (Tim Bray) во время своего выступления на AWS Re: Invent 2019 сказал: “[событийно-ориентированная архитектура] - правильный путь к построению Amazon.com, и любой другой способ будет неправильным”. Полагаю, одного этого заявления уже достаточно, чтобы вызвать интерес к событийно-ориентированной архитектуре.

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

В приведенном выше примере мы узнаем монолитную архитектуру. А теперь представьте, что случится в подобном сетапе, если какой-нибудь сервис на сервере выйдет из строя? Запрос от клиента будет потерян. Для таких коммерческих сайтов, как Amazon, это будет означать потерю продаж на миллиарды долларов. В небольшой компании, которая обрабатывает меньший объем трафика, использование подобной монолитной архитектуры оправданно. Однако, как только компания начинает задумываться о масштабировании в будущем, эта модель не скупится на обилие узких мест.

И тут на сцену выходят событийно-ориентированные архитектуры. Теперь без лишних отлагательств давайте углубимся в них и разберемся со сценариями использования и перспективными инструментами.

Что из себя представляет событийно-ориентированная архитектура?

В отличие от систем “запрос-ответ”, в событийно-ориентированной архитектуре, запрашивающая сторона отправляет событие (обычно это сообщение с заголовком [header] и полезными данными [payload]) на слой распределения (distribution layer). Далее это сообщение может принять сервис, который прослушивает какой-нибудь конкретный топик (тему). Затем этот сервис может каким либо образом использовать полезные данные сообщения или передать это сообщение далее другому сервису.

Первоначальный отправитель этого события называется издателем/продюсер (publisher/producer), а принимающая сторона - потребителем/подписчиком (consumer/subscriber). Эта система позволяет сразу нескольким сервисам принимать одно и то же событие, если их каналы прослушивают один и тот же топик.

Давайте посмотрим на диаграмму выше. Топик в этой диаграмме - “slick car” (навороченный автомобиль). Потребитель (микросервис), который слушает топик “slick car”, получит сообщение, отправленное продюсером. Второй потребитель не получит это сообщение, так как слушает топик “classic car” (классический автомобиль). Слой распределения является посредником, который агрегирует сообщения, отправленные продюсером. Если потребитель вдруг сталкивается с какими-либо проблемами при получении сообщения, слой распределения может сохранить это сообщение, поместив его в очередь, и отправить его потребителю позже, когда он будет готов.

Это очень похоже на то, как работает современная почтовая система. Когда бабушка (продюсер) отправляет посылку (сообщение) внуку (потребителю), ей нужно указать адрес (топик). Когда посылка отправлена, сначала она попадает в почтовое отделение (слой распределения). По прибытии в пункт назначения, если семья внука готова ее принять, посылка может быть доставлена ​​немедленно. В противном случае почтовое отделение может держать посылку у себя до тех пор, пока конечные адресаты не будут готовы ее получить.

Подобный механизм удержания гарантирует, что сообщения никогда не будут потеряны - они будут поставлены в очередь для доставки, как только потребитель будет готов к их получению. Это ключевое различие между событийно-ориентированной архитектурой и архитектурой “запрос-ответ”.

Зачем использовать событийно-ориентированную архитектуру?

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

Вывод в реальном времени

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

Легкая масштабируемость

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

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

Отказоустойчивость и высокая доступность

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

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

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

С чего мне начать?

Ниже приведены известные инструменты, которые вы можете использовать в производственной среде, чтобы начать свой победный путь с событийно-ориентированной архитектурой.

RabbitMQ

RabbitMQ - это продукт с открытым исходным кодом, разработанный Pivotal Software. Примечательной особенностью RabbitMQ является его способность давать сообщениям приоритеты, чтобы потребители могли получать конкретные сообщения быстрее.

Вы можете узнать больше о настройке RabbitMQ на их сайте.

Kafka

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

Вы можете узнать больше о настройке Kafka на его сайте.

Заключение

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

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

Спасибо, что нашли время прочитать эту статью!

Материал подготовлен в рамках курса «Microservice Architecture». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.