[Thinknetica] Event-Driven архитектура в Ruby-приложениях. Слушатель (Игорь Симдянов)

​

Этот воркшоп для вас, если:

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

Почему Event-Driven архитектура сейчас актуальна?

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

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

Все это подтолкнуло сообщество к пересмотру обработки событий. Еще 20 лет назад, брокер сообщений - это реализованный внутри приложения паттерн. Сейчас мы имеем дело с готовыми промышленными брокерами: RabbitMQ, Kafka.

Зачастую на практике события в приложениях используются хаотично, без системы. На воркшопе мы рассмотрим как проблемы при построении Event-Driven архитектуры, так и способы их решения.

Программа воркшопа

День 1. Event-Driven архитектура
В первый день познакомимся с событийной архитектурой и ее основными концепциями. Посмотрим, для каких задач она хорошо подходит, какие проблемы она решает.

Разберемся с базовыми паттернами: производитель (producer), потребитель (consumer), канал сообщений (topic, queue), агрегатор, разветвитель, dead-letter queue, брокер сообщений.

Заложим основы нашего будущего приложения, подберем архитектурные решения по структуре сообщения, количеству и назначению топиков. Проведем краткий обзор брокеров сообщений: sidekiq и resque на базе Redis, RabbitMQ и Apache Kafka.

Результат:

• Познакомимся/вспомним основные паттерны событийной архитектуры
• Построим архитектуру приложения
• Примем архитектурные решения в отношении будущего приложения
• Освоим инструменты документирования асинхронного взаимодействия (AsyncAPI)

День 2. Брокеры сообщений RabbitMQ и Kafka

Детальнее остановимся на брокерах сообщений, как на отдельном типе приложений. Рассмотрим брокеры сообщений первого и второго типов. Плюсы и минусы Kafka и RabbitMQ. Детальнее остановимся на внутренних возможностях: еxchange и binding-и.

Рассмотрим веб-панели управления, особенности эксплуатации и настройки брокеров сообщений. Потрогаем гемы для работы с брокерами сообщений и типичные приемы.

Построим центральную часть нашего приложения: разработаем сервисы для распознавания текста, заложим резервирование в системе, установим взаимодействие между сервисами и обеспечим документирование взаимодействия. Основная часть примеров будет именно на RabbitMQ.

Результат:

• Изучим, как выбирать брокер сообщений под ту или иную задачу
• Познакомимся с брокерами сообщений и инструментами для взаимодействия с ними
• Научимся обрабатывать сообщения, полученные через брокер сообщений и масштабировать решение
• Разработаем основную логику нашего приложения, связав сервисы и обработку

День 3. Event-Driven архитектура на практике

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

Кроме того, мы рассмотрим приемы для долговременного сопровождения проекта. Документируем проект при помощи AsyncAPI, напишем тесты, подключим dead-letter очередь для отлавливания сбойных сообщений в результате неудачных релизов.

Для мониторинга проекта настроим prometheus и grafana, в котором будем отслеживать динамику накопления и разбора очередей.

Результат:

• Завершим разработку приложения для учета чеков
• Применим паттерн dead-letter queue на практике
• Рассмотрим варианты тестирования: mock-сервер vs функциональное тестирование
• Настроим prometheus и grafana для отслеживания размера очередей

Игорь Симдянов
Автор воркшопов "Архитектура современных веб-приложений на Ruby on Rails" и "Domain Driven Design в Ruby-приложениях"

Скрытый текст. Доступен только зарегистрированным пользователям.Нажмите, чтобы раскрыть...