📎 Подборка материалов по изучению REST

📄 Статьи
1. REST, что же ты такое? — статья и вебинар от Systems Education
2. Что такое REST API? — IBM
3. Базовые понятия REST API
4. Разработка web API — краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя
5. Лучшие практики разработки REST API: 20 советов
6. Как тестировать методы REST API
7. REST в реальном мире и практика гипермедиа

▶️ Видео и вебинары
1. REST, что же ты такое?! Понятное введение в технологию. Андрей Бураков
2. Андрей Бураков. REST, почему ты такой? Скрытые смыслы популярной парадигмы.
3. Серия коротких видео Всё о REST API
4. Как аналитику спроектировать свой REST API // Демо-занятие курса «Специализация «Системный аналитик»
5. Документация REST API / Артём Кузвесов (Ideco)

🎓 Курсы
1. Бесплатный курс по документированию REST API

📖 Книги
1. Арно Лоре. Проектирование веб-API
2. Сергей Константинов. API
3. REST in Practice: Hypermedia and Systems Architecture

➕ Другое
1. Шаблон документации REST API
2. Шаблон документации микросервисов от МТС

#api #интеграции #подборка

⚙️ Что нужно знать про асинхронные интеграции

Асинхронная интеграция – это такая интеграция, когда одна система отправляет сообщение другой и не ждет подтверждения или ответа, а продолжает работу. Наиболее частый способ реализации асинхронной интеграции – это очереди (брокеры) сообщений, такие как Kafka или RabbitMQ. Очереди сообщений позволяют передавать сообщения между компонентами распределенных приложений. Передавать сообщения в очереди можно с помощью API.

Зачем нужна асинхронная интеграция:

✅ Слабая связанность сервисов. Наиболее часто применяется паттерн "издатель-подписчик". Сервис-издатель публикует сообщения в очереди и далее судьбой сообщений не интересуется. Т.е количество подписчиков и алгоритм использования сообщений сервис-издатель никак не задевают. В любой момент времени сообщения может читать один подписчик, тысяча, миллион или даже вообще никто не читать.

✅ Легкость масштабирования. Архитектура "издатель-подписчик" позволяет нам в любой момент поменять архитектуру приложения, изменить количество микросервисов, но при этом не менять код сервиса(ов)-публикатора(ов). Сервисы-потребители, при этом никак не влияют на работу друг друга. Наоборот, это также работает: можно увеличить количество публикаторов и их логику, подписчики, при этом, разницы не почувствуют.

✅ Повышение надежности. Выход из строя одного из компонентов не сказывается на работе всей системы: при восстановлении он обработает сообщение, находящееся в очереди. Ваш веб-сайт по-прежнему может работать, даже если задерживается часть обработки заказа, например, из-за проблем с сервером БД или системой электронной почты. Правда, при этом очередь сама приобретает статус SPoF (Single Point Of Failure), поэтому необходимо заранее предусмотреть действия на случай ее аварийного отключения.

Когда асинхронное взаимодействие лучше не использовать:

⛔️ У вашего приложения простая архитектура и функции, и вы не ожидаете его роста. Важно понимать, что очереди сообщений — это дополнительная сложность. Эту систему также необходимо настраивать, поддерживать, осуществлять мониторинг ее работы и так далее. Да, можно использовать Managed-решение, но вряд ли это будет оправдано для небольших приложений. Добавление очередей должно упрощать архитектуру, а не усложнять ее.

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

❗️ Также стоит учесть:

1. Очередь – это ещё одна система, которую необходимо поддерживать и на которую нужны мощности.

2. Если брокер выйдет из строя, это может остановить работу многих систем, взаимодействующих с ним. Как минимум необходимо позаботиться о резервном копировании данных.

3. Усложняется отладка. Нужна позаботиться о системе трассировки, чтобы для обнаружения причины ошибок

Как понять, следует ли выбрать асинхронную интеграцию?
Правильный выбор подхода зависит от следующих факторов:

▪️Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным. Асинхронное взаимодействие подходит, когда не требуется немедленный ответ или подтверждение от получателя.

▪️Надежность. Если надежность и отказоустойчивость критичны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.

▪️Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.

📎 Полезные материалы
1. Асинхронная интеграция. Что это такое и как её дружить
2. Зачем нужны очереди сообщений в микросервисной архитектуре
3. Что такое очереди сообщений и почему они широко используются в распределенных системах?
4. Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры
5. Брокеры сообщений

Совсем скоро выложим подборку полезных материалов по асинхронной интеграции 😉

#интеграции #async

Очереди сообщений. Основные понятия

Очереди сообщений помогают справится с высокой нагрузкой, сокращают время ответа за счёт асинхронной обработки и предотвращает потерю информации при сбоях.

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

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

🔹 Компонент, который добавляет сообщение в очередь, называется производителем (Producer).

🔹 Компонент, который извлекает сообщение из очереди и обрабатывает его, называется потребителем (Consumer).

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

Два подхода к обмену сообщениями

➡️ Метод Pull: потребитель периодически опрашивает очередь на наличие новых сообщений и извлекает их по одному или нескольким за раз.

⬅️ Метод Push: очередь уведомляет потребителя о поступлении нового сообщения и отправляет его ему. Этот метод реализует модель “Издатель/Подписчик” (Publisher/Subscriber), когда потребитель подписывается на определенный тип или тему сообщений и получает только те сообщения, которые ему нужны.

Типы гарантии доставки сообщений

1️⃣ At least once: производитель отправляет сообщение в очередь и ждет подтверждения от брокера. Потребитель извлекает сообщение из очереди и отправляет подтверждение о его обработке. Если производитель не получает подтверждения от брокера, он повторно отправляет сообщение. Сообщение будет обработано хотя бы один раз, но при этом возможны ситуации, когда одно и то же сообщение будет обработано несколько раз. Например, когда соединение прервется в момент отправки или получения подтверждения. Для предотвращения последствий дублирования сообщений необходимо, чтобы компоненты были идемпотентными, то есть повторная обработка одного и того же сообщения не приводила бы к изменению состояния системы или ее данных. Также можно использовать уникальные id для сообщений и хранить список уже обработанных сообщений.

2️⃣ At most once: производитель отправляет сообщение в очередь и не ждёт подтверждения от брокера. Потребитель извлекает сообщение из очереди и не отправляет подтверждение о его обработке. Исключается возможность дублирования сообщений, но при этом сообщение может быть потеряно. Например, когда брокер не сможет сохранить сообщение в очереди или потребитель упадет во время обработки сообщения. Этот тип доставки подходит для тех случаев, когда двойная обработка сообщения может привести к серьезным проблемам, а потеря сообщения не является критичной.

3️⃣ Exactly once. Брокер гарантирует, что каждое сообщение будет доставлено и обработано ровно один раз, без потерь или дублирования. Этот тип доставки является самым желательным, но также самым сложным в реализации. Производитель отправляет сообщение в очередь и ждет подтверждения от брокера о его приеме. Потребитель извлекает сообщение из очереди и отправляет подтверждение об обработке.
В реальности полностью исключить вероятность потери или дублирования сообщений невозможно, поэтому этот тип доставки часто реализуется с некоторыми оговорками или допущениями.

Протоколы

🌐 AMQP — бинарный протокол, который проектировался для взаимодействия между различными вендорами. Основными особенностями AMQP является надежность и совместимость.

🌐 STOMP — простой текстовый протокол обмена сообщениями, который очень похож на HTTP и работает поверх TCP.

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

📎 Ссылки
1. Асинхронное взаимодействие. Брокеры сообщений
2. Очереди сообщений
3. Apache Kafka: основы технологии
4. Очереди сообщений в бэкенд-архитектуре: как построить надежную систему
5. Стратегии доставки и дедупликации сообщений

#интеграции #async

🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений

📄 Статьи
1. Зачем нужны очереди сообщений в микросервисной архитектуре — основы от VK Cloud
2. Асинхронная интеграция. Что это такое и как её дружить — обзорная статья на Хабре
3. Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры — статья на Хабре от Сбера
4. Брокеры сообщений — статья от Timeweb Cloud по основам брокеров сообщений
5. Стратегии доставки и дедупликации сообщений — статья на Хабре от OTUS

6. Асинхронное взаимодействие. Брокеры сообщений — чуть глубже по брокерам сообщений и немного про Кафку
7. Apache Kafka: основы технологии — от Слёрм
8. RabbitMQ для аналитика: практический ликбез — BABOK School
9. AMQP на примере RabbitMQ: как же «готовить кролика»? — простым языком о RabbitMQ

10. Соседняя очередь всегда движется быстрее — углубленная статья на Хабре про то, как устроены очереди и какие есть решения

11. Угнать за 5 миллисекунд: как мы наладили быструю доставку данных в сложной биржевой системе с помощью Tarantool — практический кейс проекта для Московской биржи
12. Как построить систему, способную выдерживать нагрузку в 5 млн rps — практический пример от Ozon. Тут будет про gRPC-прокси перед Кафкой


▶️ Видео и вебинары
1. Принципы и приёмы обработки очередей / Константин Осипов (то же, только статья)
2. Интеграция распределенных систем через обмен сообщениями — базовый вебинар
3. Реализация геораспределенной персистентной очереди сообщений / Василий Богонатов (Яндекс)
4. Микросервисы: Коммуникации через очередь сообщений
5. Очереди сообщений с RabbitMQ: что такое, когда нужно, какие проблемы решает
6. Как правильно выбирать очередь / Владимир Перепелица (Mail.Ru Group)
7. Битва брокеров сообщений: Kafka, RabbitMQ, SQS — Яндекс.Практикум


📖 Книги
1. Гайвин Рой. RabbitMQ для профессионалов — онлайн книга на русском
2. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
3. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — на русском
4. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka

Если у кого есть, чем поделиться - пишите в комментариях!

#интеграции #подборка #async

🔒 HTTPS и его отличие от HTTP

HTTPS – это защищённая версия протокола HTTP, которая шифрует передаваемые данные между клиентом и сервером. HTTPS не является отдельным протоколом. Это обычный HTTP, который работает через шифрованный протокол TLS. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.

Протокол TLS (Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. TLS расположен на уровень ниже протокола HTTP в модели OSI. Это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением. TLS пришёл на смену устаревшего протокола SSL.

Зачем нужно шифрование

В HTTP данные передаются в незашифрованном виде. Злоумышленник может просто перехватить пакет. HTTPS призван защитить соединение, чтобы данные никто не мог перехватить.

Принцип работы TLS

Чтобы защитить данные, TLS создаёт во время передачи специальный канал, где их нельзя прочитать или изменить без секретного ключа. Ключ — это подсказка, как именно читать сообщение.

В зависимости от количества ключей в TLS используется один из двух классов шифрования: симметричное и асимметричное.

Симметричное шифрование — это когда используется один и тот же ключ для шифрования и дешифрования данных. Оно работает эффективно и быстро, но требует предварительного обмена ключом между клиентом и сервером, в ходе которого ключ могут перехватить.

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

В протоколе TLS симметричное шифрование используют для шифрования непосредственно сообщений, а асимметричное шифрование — во время рукопожатия, то есть в начале сессии для обмена ключами и аутентификации.

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

Таким образом, нужно использовать HTTPS, если нужно обеспечить безопасность данных, передаваемых между клиентом и сервером. Например, если вы обрабатываете личные данные, пароли, данные кредитных карт или другую чувствительную информацию.

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

📎 Материалы по теме
1. В чем разница протоколов HTTP и HTTPS — обзорная статья от Selectel
2. Как HTTPS обеспечивает безопасность соединения — статья на Хабре про принцип работы HTTPS
3. Протокол TLS: что это, зачем нужен и как работает — обзорная статья по TLS от Skillbox
4. Что такое TLS — подробнее о TLS | Хабр
5. Введение в протоколы HTTP и HTTPS — глава из руководства от Microsoft
6. Полное руководство по переходу с HTTP на HTTPS — про использование HTTPS на практике
7. Введение в криптографию и шифрование, часть первая — теория криптографии от Яндекса

#интеграции #безопасность

🧼 SOAP. Краткий обзор

SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт. В отличие от REST, SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. А ещё SOAP не может использовать другой формат представления данных, кроме XML. Применяется в системах, где нужна жёсткая стандартизация, а также в legacy.

Протокол SOAP обычно использует HTTP в качестве транспорта (SOAP over HTTP). Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP. Сообщения передаются POST-запросами.

Структура XML-сообщения

> Envelope — корневой элемент, который определяет сообщение и пространство имен, использованное в документе.

> Header — содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации.

> Body — содержит сообщение, которым обмениваются приложения.

> Fault — необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.

Все данные в SOAP-сообщении размечаются <тегами>. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают <открывающие> (перед данными) и </закрывающие>.

Как понять, какие теги использовать? А это как раз описывается отдельно – в файле WSDL.

WSDL (Web Services Denoscription Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML. В SOAP для описания своего сервиса нужно использовать строгие правила в виде файла WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как составить запрос, на какой эндпоинт его отправлять, как прочитать ответ.

Для каждого веб-сервиса SOAP есть только одна конечная точка (endpoint). Эта конечная точка может иметь несколько функций. Какие у сервиса есть функции и по каким правилам их использовать также описывается в WSDL-файле.

✅ Преимущества SOAP
1. Наличие официального стандарта
2. Наличие встроенного механизма обработки ошибок

❌ Недостатки SOAP
1. Сложность использования ввиду необходимости придерживаться строгого стандарта и правил
2. Низкая скорость обработки из-за избыточного объёма передаваемых сообщений

Применение SOAP

В настоящее время SOAP применяется в системах, где требуется жёсткая стандартизация и соблюдение строгих правил безопасности. Например, госструктуры, банкинг, финансы, здравоохранение.

В остальном SOAP теряет популярность и применяется в legacy-системах.

📎Материалы по теме
1. Применение SOAP при интеграции систем: статья и вебинар
2. Официальный учебник по SOAP на русском от w3.org
3. Пример API: Взаимодействие с API Яндекс Директа по протоколу SOAP
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API
5. SOAP API — обзорная мини-статья
6. Вебинар: Что такое SOAP, WSDL, XSD / Урок 28 / Тестировщик с нуля

#интеграции #api

🆚 REST vs SOAP. Главное

Определение
🔹 SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт.
🔸 REST – это архитектурный стиль, а не протокол. REST лишь определяет набор принципов и ограничений.

Протокол
🔹 SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. Но в большинстве случаев SOAP использует HTTP в качестве транспорта (SOAP over HTTP).
🔸 REST, как правило, хотя и не обязательно, использует HTTP. С одной стороны, REST не говорит, что нужно обязательно использовать HTTP. С другой стороны, HTTP специально спроектирован под REST. Более того, создатель REST Рэй Филдинг также является соавтором HTTP.

Формат сообщений
🔹 SOAP работает только с XML
🔸 В REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, RSS, CSV, HTML и другие

Подход к API
🔹 SOAP основан на подходе удалённого вызова процедур (RPC). Это вызов функции в коде, только по сети. Например, чтобы получить информацию о заказе, нужно вызвать SOAP-метод getOrder, чтобы оформить заказ – makeOrder и т.д.
🔸 REST фокусируется на ресурсах, доступ к которым осуществляется через URL. Это значит, например, что наш интернет-заказ имеет URI — /api/v1/order. Если мы хотим получить информацию о заказе, нужно вызвать HTTP метод GET /api/v1/order, чтобы оформить заказ, вызовем POST /api/v1/order. В обоих случаях ресурс один и тот же, а методы работы с ним разные.

Производительность
🔹 SOAP работает медленнее из-за избыточного объёма передаваемых сообщений
🔸 REST быстрее благодаря кэшированию (принцип №3) и меньшему размеру сообщений

Гибкость
🔹 SOAP сложнее масштабировать и вносить изменения. Сервер приложений также должен сохранять состояние каждого клиента. Это означает, что при обработке нового запроса он должен помнить все предыдущие, что усложняет масштабирование
🔸 REST проще масштабировать, так как сервер не сохраняет состояние клиента, поэтому REST API обрабатывает каждый новый запрос независимо от предыдущих.

Простота
🔹 SOAP сложнее, требует глубокого понимания всех задействованных протоколов и их строгих правил. Реализация SOAP API требует описания WSDL для каждого сервиса, обрабатывать и анализировать XML сложнее.
🔸 REST проще в реализации и более “человекопонятен”. Он не привязан к XML и чаще всего использует JSON.

Обработка ошибок
🔹 В протокол SOAP встроена логика обработки ошибок. SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
🔸 REST использует протокол HTTP, который может возвращать коды состояний

Раскрытие API
🔹 SOAP-сервис всегда должен иметь WSDL. Плюс этого в том, что WSDL даёт чёткие правила, как отправлять и по какой структуре отправлять запросы и принимать ответы
🔸 REST не имеет языка описания веб-сервисов. Однако на помощь приходит Swagger (OpenAPI)

Безопасность
🔹 SOAP имеет встроенное расширение безопасности – WS Security, которое регулирует процедуры конфиденциальности и аутентификации для обмена сообщениями
🔸 REST не предусматривает никаких специальных мер безопасности. Безопасность REST может быть обеспечена только за счет HTTPS

Использование
🔹 SOAP применяется в системах, где нужна жёсткая стандартизация, а также в legacy
🔸 REST используется повсеместно


📌 Выводы
SOAP и REST – не конкуренты. Они представляют разные весовые категории и вряд ли найдется задача, для которой будет сложно сказать, какой подход рациональнее использовать – SOAP или REST. Каждая задача сама диктует наиболее разумный подход к интеграции.

📎 Полезные материалы
1. О REST на нашем канале
2. Про SOAP
3. Статья про разницу SOAP и REST от Amazon (на русском)
4. SOAP и REST API: Ключевые различия, объясненные для новичков
5. REST vs SOAP на Medium (через VPN)
6. Что происходит, когда мы отправляем SOAP или REST запрос — 3,5 минуты видео

#api #интеграции #сравнение

Сравнение REST vs SOAP картинкой для Вашего удобства #сравнение

🏭 PlantUML: полезные материалы

Небольшая подборка для тех, кто давно хотел начать применять PlantUML, но никак не доходили руки. К счастью, это не займёт много времени.

PlantUML — это крайне полезный инструмент для аналитика, который превращает псевдокод в UML-диаграммы. Это значительно быстрее и удобнее, чем вечно тыкаться со стрелочками и ручным выравниванием в draw.io или в Visio. Жирный плюс — есть плагин для Confluence.

Синтаксис очень простой, пугаться кода не нужно. По примерам становится всё понятно.

Для начала выберете место, где вам будет удобнее писать диаграмму: это может быть:
1. planttext.com — онлайн редактор
2. расширение для Notepad++
3. расширение для IDE (лучший вариант, ссылки кликабельны): IDEA, PyCharm, Visual Studio

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

Документация
1. Официальная документация (почти всё на русском)
2. Гайд на русском в pdf

Статьи
1. Диаграммы без боли и страданий: PlantUML — хороший гайд с примерами
2. Пишу диаграммы последовательностей текстом (кодом). Вы тоже можете — тут только про sequence

Видео
1. PlantUML с нуля до гуру: учимся «кодить» sequence-диаграммы — доклад Никиты Харичкина с Flow 2022 (скачать презентацию)
2. PlantUML на всю катушку: Автоматизация и лайфхаки для диаграмм последовательности — доклад всё того же Никиты, но с Analyst Days #14 (скачать презентацию)

#инструменты #подборка

24 сентября — День Системного Аналитика, наш профессиональный праздник.

Нас поздравляет само ChatGPT

Основы Kafka – что нужно знать аналитику

Неделей ранее мы рассматривали основные понятия очередей сообщений. Пришло время копнуть чуть глубже и познакомиться с Кафкой.

Apache Kafka – популярный брокер сообщений с открытым исходным кодом. Применяется в высоконагруженных системах для асинхронной интеграции, где требуется гарантированная доставка сообщений.

Подход к обмену сообщениями
Те, кто отправляют сообщения в Kafka, называются продюсерами, а те, кто читает, косьюмерами. В Kafka используется подход pull, когда консьюмеры сами отправляют запросы в брокер раз в n миллисекунд для получения новой порции сообщений. Такой подход позволяет группировать сообщения в пакеты, достигая лучшей пропускной способности. К минусам модели можно отнести потенциальную разбалансированность нагрузки между разными консьюмерами и более высокую задержку обработки данных.

После прочтения косньюмерами сообщения в Kafka не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.

Архитектура Kafka
Kafka является распределенной системой. Все серверы объединяются в кластеры. Хранение и пересылка сообщений идёт параллельно на разных серверах, это даёт большую надежность и отказоустойчивость. Такая архитектура упрощает горизонтальное масштабирование: достаточно добавить дополнительные серверы.

Хранение сообщений в Kafka
Каждое сообщение (event или message) в Kafka состоит из ключа, значения, таймстампа и опционального набора метаданных (headers). Сообщения хранятся в топиках, которые делятся на партиции (partitions). Партиции распределены между брокерами в кластере и могут быть реплицированы для надёжности. Сообщения с одинаковыми ключами попадают в одну партицию, что обеспечивает порядок записи и чтения.

Чтение сообщений в Kafka
Как не читать одно сообщение дважды? Консьюмеры в Kafka отмечают обработанные сообщения с помощью оффсетов. Оффсет – это номер сообщения в партиции. Консьюмер отправляет брокеру запрос offset-commit с офсетом, который нужно сохранить. Брокер хранит эти офсеты в специальном топике. Консьюмеры могут получить последний закоммиченный оффсет у брокера и продолжить чтение сообщений с него.

Процесс обмена сообщениями в Kafka
0️⃣ Создается именованный топик, который является точкой интеграции между продюсером и консьюмером. Топик делится на несколько партиций, которые распределяются между брокерами в кластере
1️⃣ Продюсер отправляет сообщение в топик брокера. Сообщение содержит ключ, значение, таймстамп и опциональные хедеры. Ключ определяет, в какую партицию попадет сообщение.
2️⃣ Консьюмер пытается забрать сообщение и его уникальный идентификатор (оффсет), присвоенный брокером (как правило, порядковый номер).
3️⃣ Брокер хранит сообщение до запланированной очистки журнала. Kafka не отслеживает, какие сообщения были обработаны консьюмерами.
4️⃣ Консьюмер обрабатывает сообщение, исходя из своей бизнес-логики и отправляет запрос обратно на сервер, используя его уникальный офсет и сообщает брокеру либо об успешной обработке (offset-commit), либо об ошибке (offset-reset).
5️⃣ В случае успеха офсет помечается как закоммиченный и сохраняется в специальном топике. В случае ошибки оффсет сбрасывается на предыдущее значение или на дефолтное. Сообщение не удаляется из партиции и доступно для повторного чтения консьюмерами.

Где используется Kafka
Kafka используется для обработки больших объёмов данных, сотен тысяч сообщений в секунду, которые читаются тысячами подписчиков. Kafka — это легко масштабируемая система, обладающая повышенной отказоустойчивостью, что очень важно в крупных проектах, например, банкинг, телеком социальные сети, IoT.

Материалы по Kafka выйдут в следующем посте завтра, а на следующей неделе рассмотрим RabbitMQ и сравним его с Kafka.

#интеграции #очереди #async

Подборка бесплатных материалов по Kafka
Делитесь с коллегами 📢

📑 Статьи (теория)
1. Apache Kafka: основы технологии от Слёрм
2. Короткая статья на Яндекс.Практикум
3. Apache Kafka для аналитика: ТОП-7 требований к интеграционной шине
4. Kafka за 20 минут от СберМаркета
5. Перевод на русский главы "Kafka" из книги «Understanding Message Brokers»
6. Микросервисы, Apache Kafka и Domain-Driven Design

📝 Статьи (практика)
1. Как построить систему, способную выдерживать нагрузку в 5 млн rps
2. Разбираемся в технологии и собираем простое приложение на базе managed-решения
3. Как мы автоматизировали работу с Kafka

⏯ Вебинары
1. Apache Kafka, открытый базовый курс — 3 видеоурока от Слёрм
2. Про Kafka (основы) — Владимир Богдановский
3. Основы работы с Kafka с Павлом Вейником — видеолекция с примерами от разработчика

📚 Книги
1. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
2. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — книга про Kafka на русском
3. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka

Если у кого есть ещё чем поделиться, пишите в комментариях 👇

#подборка #интеграции #очереди #async

🐇 Основы RabbitMQ – что нужно знать аналитику

В предыдущих постах мы немного рассмотрели Кафку, пришла очередь Кролика.

RabbitMQ – это брокер сообщений с открытым исходным кодом, который реализует протокол AMQP (Advanced Message Queuing Protocol). Применяется в системах для асинхронной интеграции, где требуется гибкая и надежная маршрутизация сообщений.

Основная фишка RabbitMQ — это гибкая маршрутизация сообщений между различными поставщиками (продьюсерами) и потребителями (косьюмерами) событий. RabbitMQ – это не просто очередь данных между двумя сторонами, это менеджер очередей, который маршрутизирует данные в разные очереди сообщений. Продьюсер отправляет сообщения не в саму очередь, а на обменник, который сам распределяет сообщения между очередями.

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

Подход к обмену сообщениями

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

В RabbitMQ после получения консьюмерами сообщение удаляется из очереди. Благодаря этому одно и то же сообщение может быть обработано только одним консьюмером и не хранится дольше необходимого.

К минусам подхода push относится меньшая гибкость для потребителей. В отличие от модели pull, когда потребитель сам ходит за новыми сообщениями, когда ему надо, push не оставляет выбора потребителю – тот должен обработать поступившее сообщение. Кроме того, RabbitMQ не гарантирует порядок доставки сообщений.

Процесс обмена сообщениями в RabbitMQ

0️⃣ Создается именованный обменник, который является точкой интеграции между продюсером и консьюмером. Обменник задает правила маршрутизации сообщений.
1️⃣ Создаются одна или несколько очередей, которые привязываются к обменнику с помощью ключей маршрутизации.
2️⃣ Продюсер отправляет сообщение в обменник
3️⃣ Обменник, получив сообщение, маршрутизирует его в одну или несколько очередей в соответствии с правилами привязки между ним и очередью
4️⃣ Очередь отправляет сообщение потребителям (одному или нескольким), которые подписались на “push-уведомления” (поставили 🔔 на канале 😄)
5️⃣ Потребитель обрабатывает сообщение, исходя из своей бизнес-логики и отправляет брокеру подтверждение об успешной обработке (ack) или отказе (nack)
6️⃣ В случае успешной обработки брокер удаляет сообщение из очереди. В случае неудачной обработки со стороны потребителя (nack) сообщение остается в очереди, пока не будет успешно обработано

В случае некорректного завершения работы сервера, данные в очереди не теряются. И при последующем запуске обработка продолжается с того места, где был обрыв.

Архитектура RabbitMQ
RabbitMQ является распределенной системой. Все серверы объединяются в кластеры. Пересылка сообщений идёт через специальные узлы, называемые обменниками (exchanges), которые могут иметь разные типы и правила маршрутизации. Обменники отправляют сообщения в очереди (queues). Обменники и очереди связаны через binding – правила, которое сообщает имеющемуся обмену в какой из очередей эти сообщения должны сохраняться. Очереди могут быть распределены между брокерами в кластере и реплицированы для надёжности.

Где используется RabbitMQ
RabbitMQ — это универсальный брокер сообщений. Он отлично подходит для интеграции микросервисов, потоковой передачи данных в режиме реального времени или при передаче работы удалённым работникам. Его используют крупные компании, в числе которых Bloomberg, Reddit, NASA и др.

Подборка полезные материалов о RabbitMQ будет в следующем посте. В понедельник выйдет верхнеуровневое сравнение RabbitMQ vs Kafka по пунктам.

#интеграции #очереди #async

🐇 Подборка бесплатных материалов по RabbitMQ
📢 Делитесь с коллегами

0. Официальная документация

📑 Статьи (теория)

1. Цикл конспектов от Слёрм:
✹ RabbitMQ: терминология и базовые сущности
✹ Когда и зачем нужен RabbitMQ
✹ Как запускать RabbitMQ в Docker
✹ Типовое использование RabbitMQ
✹ Разбираемся с RabbitMQ: High Availability и High Load
✹ RabbitMQ: дополнительные возможности

2. RabbitMQ для аналитика: практический ликбез — подробно о RabbitMQ + практический пример
3. AMQP на примере RabbitMQ: как же «готовить кролика»? — о принципе работы RabbitMQ на пальцах


📝 Статьи (практика)
1. 101 способ приготовления RabbitMQ и немного о pipeline архитектуре (то же, только видео с HighLoad++)
2. Построение распределенной системы очередей сообщений с RabbitMQ и Python
3. Highly Available кластер RabbitMQ


▶️ Видео и вебинары
1. Очереди сообщений с RabbitMQ: что такое, когда нужно, какие проблемы решает
2. Разработка требований к Rabbit MQ — Зоя Степчева, Systems Education
3. Системы обмена сообщениями: RabbitMQ и Kafka // Архитектура и шаблоны проектирования
4. Очень (даже слишком) подробная лекция о RabbitMQ и Kafka: часть 1 и часть 2
5. Использование RabbitMQ Streams — лекция от разработчика
6. Брокеры сообщений RabbitMQ, Kafka и Redis в работе системного аналитика: как и когда использовать


🧑‍💻 Для любителей всё попробовать руками есть бесплатный видеокурс на Ютубе.


📖 Книги
1. Гайвин Рой. RabbitMQ для профессионалов — онлайн книга на русском
2. Остальные книги на английском можно скачать здесь

#подборка #интеграции #очереди #async

Юрий Химонин. Сбор и анализ требований к программному продукту

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

На своем канале Pro анализ в ИТ Иннокентий Бодров, аналитик и менеджер продукта с 15-летним стажем, делится полезными материалами по созданию ИТ продуктов и систем, развитию и росту аналитиков, работе аналитиков в РФ и других странах.
👨‍💻 Ревью статьи Евгения Скорикова про проработку нефункциональных требований

🎥 Эфир про работу аналитика в Нидерландах

📶 Обсуждение KPI аналитика

Также подготовили сравнение RabbitMQ vs Kafka в табличном виде
#сравнение