Этот воркшоп для вас, если:
вы хотя бы раз в жизни сталкивались с ситуацией, когда длительная операция тормозит ваше приложение
вы отлаживали фоновые операции днями и неделями, пытаясь договориться с отправителем или получателями о "протоколе" обмена
при разработке микросервисного приложения, у вас каждый раз получается "жирный" оркестратор, который в курсе всех бизнес-процессов
вы хотите разобраться с особенностями современных брокеров сообщений, в какой ситуации подходит тот или иной брокер
Почему 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-приложениях"
Скачать:
Для просмотра содержимого вам необходимо авторизоваться