Брокеры сообщений — что это и зачем нужны // Курс «RabbitMQ для разработчиков и администраторов»

• Тема вебинара: брокеры сообщений для разработчиков и администраторов.  

• Основные цели: знакомство, рассказ о компании OTUS, обсуждение микросервисов, основные понятия, сравнение брокеров сообщений, команда курса, карьерные возможности и итоги.  

• Максим Иванов, системный архитектор в компании DataJill.  

• Опыт работы в различных сферах, включая IT, торговлю, операторов связи и стартапы.  

• Преподаватель курса "Рабита для разработчиков и администраторов".  

• Призыв к участникам представиться и указать свою специальность.  

• Обсуждение целей участия в курсе.  

• Правила вебинара: активное участие, вопросы в чат.  

• OTUS специализируется на обучении в сфере IT.  

• Преподаватели – практикующие специалисты.  

• Образовательная лицензия, дипломы о повышении квалификации и возможность налогового вычета.  

• Более 130 курсов, более 600 преподавателей.  

• Преподаватели – специалисты из компаний, где работают слушатели.  

• Более 20 тысяч выпускников за 6 лет.  

• Цели вебинара: объяснить проблемы, решить которые помогают брокеры сообщений, основные понятия, использование брокеров в архитектуре, разница между основными брокерами.  

• Пример с регистрацией клиента и отправкой сообщений в смс-сервис.  

• Проблемы: невозможность отдельной разработки, разделение на команды, использование одного языка программирования, необходимость балансировки при использовании нескольких рассыльщиков.  

• Создана отдельная команда для разработки смс-сервиса.  

• Устранена сильная связанность между сервисами.  

• Проблема падения всего сервиса при ошибке в смс-сервисе решена.  

• Возникли сложности с масштабированием и добавлением новых смс-сервисов.  

• Необходимость заполнения конфигов для отправки смс на разные номера.  

• Проблемы решаются по мере усложнения компании и сервисов.  

• Необходимость знать адреса сервисов для взаимодействия.  

• Использование программного обеспечения для управления конфигурациями.  

• Вопросы аутентификации и поведения при перегрузке серверов.  

• Синхронный код может вызвать проблемы при взаимодействии с сервисами.  

• Необходимость балансировки и распределения заданий при наличии подчиненных сервисов.  

• Вопросы балансировки начинают накапливаться в реальной эксплуатации.  

• Брокер как набор очередей для передачи сообщений между сервисами.  

• Решение проблемы знания адресов сервисов через адрес брокера.  

• Брокер упрощает аутентификацию и решает проблему перегрузки сервисов.  

• Брокер позволяет сервисам работать в своем темпе.  

• Решение проблемы балансировки нагрузки и распределения заданий.  

• Брокер работает как демпфер, гася колебания и позволяя сервисам работать в оптимальном темпе.  

• Брокер как паттерн медиатор для взаимодействия сервисов.  

• Преобразование цепочки зависимостей в звездообразную схему через брокер.  

• Брокер помогает в отладке и администрировании сервисов.  

• Брокеры позволяют откладывать содержимое очередей в дополнительную очередь для отладки.  

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

• Брокеры могут обрабатывать негативные подтверждения, что помогает в случае сбоев.  

• Брокеры являются единой точкой отказа, поэтому должны быть надежными и устойчивыми.  

• Современные брокеры, такие как RabbitMQ и Kafka, решают эту проблему через кластеризацию и грамотное написание кода.  

• Использование стандартных протоколов, таких как JSON-RPC, упрощает взаимодействие между сервисами.  

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

• Использование интерфейсов и стандартизированных форматов запросов облегчает разработку и тестирование.  

• Применение инструментов, таких как API-First и Contract-First, помогает в создании и поддержке микросервисной архитектуры.  

• Использование микросервисных фреймворков, таких как Slerry, упрощает разработку многопоточных приложений.  

• Slerry поддерживает работу с RabbitMQ, что делает его более продвинутым брокером по сравнению с Redis.  

• Slerry и другие фреймворки помогают в создании и поддержке микросервисной архитектуры.  

• В отличие от команд, потоки данных могут быть от датчиков или статистики, например, от Яндекс.Метрики.  

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

• Видеоплеер отправляет много информации о видео, разрешении экрана и других параметрах.  

• Пример с двумя площадками в Москве и Норильске с множеством датчиков.  

• Проблемы с полингом данных и потерей информации из-за ограниченной памяти датчиков.  

• Сильная связанность данных и необходимость разделения анализа и оповещений.  

• Проблемы с масштабированием и использованием одного языка программирования.  

• Использование брокеров сообщений для сбора данных с датчиков.  

• Федерация брокеров для объединения данных.  

• Проблемы с производительностью из-за копирования данных между потребителями.  

• Проблема с разрушающим чтением в очередях.  

• Введение концепции стримов, которые работают как журналы.  

• Стримы позволяют читать данные с определенного места и имеют политику удаления старых данных.  

• Задача измерения уровня громкости на игровом столе.  

• Использование брокера для отправки отчетов о громкости.  

• Проблемы с производительностью брокера из-за большого количества сообщений.  

• Важность понимания технических ограничений используемых технологий.  

• Решение проблемы с использованием Redis вместо RabbitMQ.  

• Необходимость расчета нагрузки и количества сообщений в проекте.  

• Обсуждение замены брокеров сообщений на базы данных.  

• Пример использования Redis для отправки и получения данных.  

• Команды pubsub и subscribe в Redis для отправки и получения сообщений.  

• Сравнение терминологии Kafka и RabbitMQ.  

• Приложение pubsub отправляет сообщения в очередь.  

• Консьюмер получает сообщения из очереди по определенным правилам.  

• Метафора с рекой и бумажками для объяснения работы RabbitMQ и Kafka.  

• RabbitMQ использует интеллектуальные заслонки для управления потоком сообщений.  

• Kafka и стримы работают по принципу регистрации фактов прохождения сообщений.  

• Redis как база данных и как брокер сообщений.  

• Команды pubsub в Redis не сохраняют данные, а только отправляют их подписчикам.  

• Возможность использования Redis как брокера сообщений без сохранения данных.  

• Описание типов exchange: direct, topic, fanout, handlers.  

• Direct exchange отправляет сообщения в одну очередь по ключу маршрутизации.  

• Topic exchange позволяет гибко маршрутизировать сообщения по словам и символам.  

• Описание федерации sharding и shunting.  

• Sharding позволяет эффективно распределять сообщения между брокерами.  

• Shunting создает необходимые очереди для передачи информации между брокерами.  

• RabbitMQ используется для обработки небольших объемов данных до 100 МБ/с.  

• Kafka подходит для потоковой обработки больших объемов данных до 600 МБ/с.  

• RabbitMQ поддерживает десятки и сотни тысяч сообщений в секунду, Kafka - миллионы.  

• RabbitMQ имеет более высокую производительность, но Kafka требует меньше ресурсов.  

• RabbitMQ проще в настройке и администрировании, чем Kafka.  

• RabbitMQ использует стандартные протоколы, что упрощает интеграцию с другими системами.  

• RabbitMQ поддерживает множество языков программирования, Kafka - меньше.  

• RabbitMQ поддерживает сложную маршрутизацию, Kafka - менее сложную.  

• Курс начинается 28 февраля, занятия проходят по понедельникам и средам.  

• Вебинары и домашние задания доступны для просмотра и обсуждения.  

• Программа курса обновляется на основе обратной связи.  

• Курс помогает в поиске вакансий для программистов, инженеров и администраторов.  

• Примеры вакансий включают работу с брокерами сообщений и маршрутизацией нагрузки.  

• Курс полезен для бизнес-аналитиков и руководителей.  

• Активность 93 пользователя, отвечают три человека.  

• Подведение итогов вебинара.  

• Рекомендация пройти опрос для авторизированных пользователей.  

• Использование брокеров сообщений при наличии нескольких сервисов.  

• Применение проверенных технологий и протоколов.  

• Анализ ограничений и техническое задание от заказчиков.  

• Мало литературы по RabbitMQ, но есть полезные ссылки.  

• Учебное пособие по RabbitMQ на Хабре.  

• Сравнение RabbitMQ и Kafka от компании Confluent.  

• Курс начинается 29 числа.  

• Обзор тем: теория, установка, основные понятия, объекты системы.  

• Разработка приложений на Python.  

• Модуль по продвинутому конфигурированию RabbitMQ.  

• Модуль по масштабированию и настройке кластера.  

• Модуль по мониторингу и PIT-тюнингу.  

• Проектный модуль с использованием полученных знаний.  

• Вопросы и ответы.  

• Минимальное понимание Linux и Docker.  

• Запись вебинара будет выложена на YouTube.  

• Курс посвящен RabbitMQ, а не Kafka.  

• Завершение вебинара и благодарность за участие.