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