Привет, Хабр!
Меня зовут Елизавета Колесникова, и вот уже 4 года я работаю системным аналитиком СПАО «Ингосстрах»
Этой статьёй я бы хотела начать серию материалов для аналитиков и разработчиков, которые только начинают свой путь в ИТ.
Когда-то я сама жестко плавала в бульоне ИТ-терминов, а также тыкалась по разным сайтам в поисках подходящей информации, как слепой котенок, без возможности соединить воедино полученные данные таким образом, чтобы моих интеллектуальных ресурсов хватило для написания ТЗ. Толковых гайдов и памяток я не находила, в основном попадалась или сухая теория, или жидкая вода. Поднабравшись немного опыта, я решила составить серию памяток, где буду расписывать ключевые вопросы, которые помогут начинающим специалистам разобраться, как писать ТЗ по интеграциям.
Если вам прилетала задачка, в рамках которой необходимо продумать, как Kafka будет взаимодействовать с вашей системой, но вы не особо знакомы с этой платформой, то моя памятка — как раз для такого случая.
Что такое Kafka?
Apache Kafka — это брокер сообщений, который используется для обмена сообщениями между различными системами, сервисами или модулями.
Для начала давайте разберемся с базовыми терминами, которые вы наверняка встретите при работе с платформой:
Брокер (Broker) — сервер Kafka, который хранит и обрабатывает сообщения. Именно он распределяет сообщения по топикам и хранит их в распределенной форме для обеспечения доступов для Потребителя.
Топик (Topic) — именованная очередь сообщений с надежным хранением. События из топика можно читать так часто, как это необходимо: в отличие от традиционных систем обмена сообщениями, события не удаляются после использования.
Партиция (Partition) — физическая часть топика, в которую брокер последовательно записывает сообщения. Для масштабирования топик разделяется на несколько партиций. При этом партиции одного топика располагаются на разных брокерах. Сообщения с одним и тем же ключом события (например, идентификатором клиента) записываются в одну и ту же партицию. Для примера топиком можно назвать магазин канцтоваров, в котором есть несколько касс обслуживания. Партициями в этом случае будут сами кассы, к которым стоят очереди.
Производитель (Producer) — это клиентское приложение, которое публикует (записывает) сообщения в Kafka.
Потребитель (Consumer) — это клиентское приложение, которое подписывается на эти события (читает и обрабатывает их).
Задержка (Lag) — разница между количеством сообщений, опубликованных в топиках, и количеством сообщений, уже обработанных Потребителем.
Идемпотентность (Idempotency) — свойство операции, при котором повторная обработка одного и того же сообщения не приводит к дублированию данных.
Метаданные (Metadata) — это служебная информация о самих данных и структуре системы.
Сериализация (Serialization) — процесс преобразования объектов (данных) в массив байтов для их передачи по сети и хранения на дисках брокеров.
Dead Letter Queue (DLQ) или Dead Letter Topic (DLT) — специализированный топик, куда перенаправляются сообщения, которые не удалось успешно обработать.
Алертинг (alerting) — это автоматический процесс обнаружения проблем и уведомления ответственных лиц о них в реальном времени.
Процесс строится следующим образом: приложения публикуют сообщения (фактически проводят запись) на узел Kafka в определенный топик, далее указанные сообщения обрабатываются другими приложениями (потребителями). При этом потребители должны предварительно подписаться на топики для получения сообщений.
Обычно от аналитика при проектировании интеграции с Kafka ожидается решение по количеству топиков (логическое разделение данных), партиций и алертов. При этом, если вопрос касается ресурсов, лучше подключать к решению задачи архитекторов.
Как можно использовать Kafka?
Существует три основных сценария, где можно использовать брокер:
Асинхронный обмен между системами — используется, если другая система не может быстро дать ответ и/или если нет возможности долго его ожидать.
Если нет возможности ждать сразу ответ от другой системы.
Пример: клиент банка делает запрос на кредитование → фронт кладет запрос в Kafka → система скоринга обрабатывает его и возвращает результат в Kafka → фронт забирает или получает результат скоринга из KafkaИнтеграция микросервисов — используется, если несколько микросервисов должны обмениваться событиями.
Пример: клиент сервиса Такси создает заказ→ сервис заказов публикует сообщение о новом заказе→ Платежный, логистический сервисы и сервис уведомлений «слушают» Kafka и обрабатывают полученные сообщения, независимо друг от друга и реагируют на них.
Есть еще не основной сценарий: потоковая аналитика — используется, если нужно обрабатывать данные в реальном времени и/или фиксировать все бизнес-события. Пример: Kafka собирает данные для агрегации и подсчета событий, обнаружения аномалий.
Вопросы, которые нужно себе задать при проектировании интеграции с Kafka
Чтобы спроектировать интеграцию с Kafka и написать ТЗ, необходимо ответить для себя на следующие вопросы:
Тип взаимодействия: является ли система производителем (producer) или потребителем (consumer)?
Модель взаимодействия с брокером: через push-модель или pull-модель?
Преимущества pull-модели: высокая пропускная способность, контроль скорости обмена данными.
Недостатки pull-модели: сообщения могут не доставляться мгновенно, так как ждут запроса от Потребителя; может возникать неравномерная нагрузка на Потребителей, в случае если они быстро обрабатывают потоки сообщений.
Преимущества push-модели: минимальная задержка при передаче данных; Производителю не нужно хранить состояние или ждать запроса, что снижает на него нагрузку.
Недостатки push-модели: большой риск перегрузки системы, если Потребитель не справится с потоком данных; сложнее эффективно группировать сообщения, так как Производитель пытается быстрее отправить их.
Чаще всего используется pull-модель, когда consumer подписывается на брокер и сам забирает сообщения из него.
Какое событие будет инициировать публикацию сообщения в Kafka (что изменилось в системе и о чем другие сервисы должны знать)?
Событие, инициирующее сообщение в Kafka, — это факт, который произошёл в системе и требует уведомления других сервисов. Например: создание заявления, закрытие задачи и т.д.
Какой состав данных: какие поля содержит сообщение и какие из них являются минимально необходимым?
Минимально необходимые поля:
value (значение) — это чащесего массив в виде JSON, который содержит бизнес-данные;
Метаданные:
key (ключ) — используется для определения партиции;
timestamp (метка времени) — указывает время создания сообщения или время лога в брокере;
headers (заголовки) — коллекция пар «ключ-значение» (метаданные), похожая на HTTP-заголовки.
Каким будет направление обмена: односторонним или двусторонним?
Чаще всего используется односторонний обмен, так как он имеет максимальную пропускную способность. Двусторонний обмен используется микросервисами, которым нужно подтверждение логической обработки данных, а не просто факт их доставки в брокер (например, при проверке баланса, подтверждении заказа или создании запроса).
Какое будет название топиков?
Наименования топиков должны:
Отражать смысл данных — любой топик должен быть понятен без просмотра кода.
Разделять бизнес и технику — чтобы логи, метрики и телеметрия не мешали бизнес-событиям.
Сохранять консистентность — единый формат во всех командах и доменах.
Поддерживать долговечность — минимизировать переименования при изменениях архитектуры.
Связь топика с другими системами: кто подписан на этот топик, какая последовательность взаимодействия?
В каком формате данные будут храниться в сообщении?
Формат данных может быть следующим: JSON, Avro, Protobuf, XML. Формат данных сообщения влияет на сериализацию. Чаще всего используется JSON Schema.
Срок жизни данных: нужно ли хранить сообщения после обработки? Если да, то сколько?
Нет смысла хранить сообщения вечно. Срок хранения сообщений может зависеть как от бизнес-потребностей, так и от максимально возможного объема данных в топике.
Какие идентификаторы сообщения будут использоваться для идемпотентности и трассировки?
Идентификаторы сообщения для идемпотентности нужны для предотвращения повторной обработки одного и того же сообщения. В качестве таких идентификаторами могут выступать номера сообщения или запроса.
Идентификаторы сообщения для трассировки нужны для отслеживания пути сообщений от Производителя до Получателя. Такими идентификаторами могут выступать номер шага или номер цепочки событий.
Будет ли выполняться проверка успешной доставки и проверка корректности структуры: сценарий, минимально необходимый состав данных?
Сама по себе Kafka не гарантирует доставку сообщений до потребителя.
Можно проверять корректность структуры данных и обязательность минимально необходимых полей.
Для защиты от дублирования Потребитель может проверять обрабатывал ли он это сообщение ранее.
Так же можно логировать: ошибки валидации, события в dead-letter queue, сбои при обработке, дубликаты.
Нужен ли мониторинг и алертинг?
Мониторинг метрик в Kafka нужен для своевременного обнаружения сбоев.
Что можно мониторить:
Lag — если Потребитель отстает от Производителя, это может говорить о несвоевременной обработки данных;
Число брокеров — падение одного и более брокеров могут повлечь за собой потерю данных.
Сообщения в Dead Letter Queue (DLQ) — увеличение количества сообщений в DLQ может говорить об ошибках в обработке сообщений.
Соответствует ли процесс требованиям информационной безопасности: есть ли аутентификация, шифрование, имеются ли чувствительные данные?
У каждой компании свои требования к информационной безопасности, в данном вопросе следует опираться на внутренние регламенты.
Как будет происходить версионирование (управление изменениями формата сообщений)?
Для обеспечения обратной совместимости необходимо определить ,как будет изменяться формат сообщений без багов для новых и старых Потребителей.
Небольшой чек-лист для ТЗ по интеграции с Kafka:
Определено, какое событие публикуется: учтены размеры сообщения, скорость роста\вычитки\хранения топика.
Известно, кто Производитель, кто Потребитель.
Есть описание топика (имя, формат, ключ, схема).
Продуман формат данных и валидация.
Учтены ошибки и сценарий повторной отправки.
Есть пример сообщения и пример ошибки.
Прописаны правила логирования, мониторинга и алертинга.
Проверено наличие dead-letter queue.
Описано версионирование сообщений.
Небольшой чек-лист по созданию топика:
Имя соответствует формату (бизнес / технический).
Используются строчные буквы и только допустимые символы ([a-z0-9.-]).
Сообщение — в прошедшем времени (created, updated, completed).
Нет упоминаний названий технологий или баз данных.
Пример описания топиков Kafka
Надеюсь, что эта статья поможет вам разобраться с вашей задачей! Если у вас остались вопросы, буду рада ответить на них в комментариях.
А в следующей статье мы разберем вопросы, которые помогут написать ТЗ по API.