В этой серии статей я постараюсь объяснить вам, почему вы должны тратить свое время на изучение Kafka и Karafka, и как это может изменить способ проектирования и разработки приложений Ruby. Я также постараюсь ответить на некоторые из наиболее распространенных вопросов по этим двум и дать вам несколько реальных примеров использования того, как вы можете быстро получить выгоду от их добавления в свой технологический стек.
Что такое Кафка?
Позвольте процитировать Wiki по этому поводу:
Apache Kafka - это платформа обработки потоков с открытым исходным кодом, разработанная Apache Software Foundation, написанная на Scala и Java. Проект направлен на создание единой платформы с высокой пропускной способностью и малой задержкой для обработки потоков данных в реальном времени.
Теперь давайте переведем это на несколько общих понятий (скопировано отсюда):
- Он позволяет публиковать потоки записей и подписываться на них. В этом отношении он похож на очередь сообщений или корпоративную систему обмена сообщениями.
- Это позволяет вам хранить потоки записей отказоустойчивым способом.
- Это позволяет обрабатывать потоки записей по мере их появления.
- Он позволяет создавать приложения на основе конвейера данных в реальном времени, которые надежно обмениваются данными между системами и / или приложениями.
- Он позволяет создавать потоковые приложения в реальном времени, которые преобразуют поток данных и / или событий и реагируют на них.
- Это позволяет упростить реализацию дизайна драйверов домена как в новых, так и в существующих приложениях и позволяет сделать это более технологически независимым.
Почему мне это должно быть интересно?
Потому что это позволяет вам расширяться. И я имею в виду не только то, что вы добьетесь гораздо большей производительности и сможете обрабатывать больше и быстрее.
На самом деле я имею в виду, что как только вы поймете концепции, лежащие в основе этого, вы получите совершенно новый набор возможностей для работы с вашими данными. Вы расширите свой кругозор и измените способ разработки кода.
Системы, которые мы создаем, управляются данными, и, имея больше способов работы с ними, мы получаем совершенно новый набор инструментов и решений, которые мы можем использовать, чтобы сделать нашу работу лучше и эффективнее.
Я все время говорю, что сообществу Ruby (и Rails в частности) не хватает архитекторов и хорошей архитектуры для систем после MVP. Одна из причин, почему это так, заключается в том, что мы должны придерживаться образа мышления «запрос-ответ». Как только вы узнаете, что все можно сделать по-другому, это повлияет на ваш способ работы с любой используемой вами технологией, включая Ruby on Rails.
Базовая терминология Kafka
Есть много общих вводных статей о Кафке, в том числе и официальная. Здесь я опишу наиболее важные части экосистемы Kafka, чтобы вы могли начать работать с ней как можно быстрее.
Примечание. приведенное ниже описание может быть неточным на 100%, но его должно быть достаточно, чтобы вы усвоили основы и продолжали работать.
Примечание: вы можете найти более подробную информацию о Kafka в отличной статье Kafka in a Nutshell.
Общая концепция системы обмена сообщениями "публикация-подписка"
Система обмена сообщениями позволяет отправлять сообщения между процессами, приложениями и серверами. Приложения должны иметь возможность подключаться к такой системе и передавать сообщения в обоих направлениях.
Примечание. Издатель (отправляющий сообщение) может одновременно быть получателем / подписчиком.
Иллюстрации взяты отсюда.
Брокеры Kafka
Kafka - это распределенная система, работающая в кластере. Каждый узел в кластере называется брокером Kafka. Брокер - это отдельный процесс Kafka, работающий в кластере.
Кафка темы с перегородками
Тема Kafka - это просто именованный поток записей. Это немного похоже на концепцию очереди Sidekiq или RabbiMQ. В общем, это пространство имен, в котором вы собираетесь хранить сообщения, похожие друг на друга с точки зрения вашей бизнес-логики.
Все организовано вокруг тем, и большинство гарантий Kafka относятся либо к теме, либо к разделу темы. Вы отправляете и получаете сообщения из тем. Темы в Kafka всегда имеют многоабонентский характер; то есть у темы может быть ноль, один или несколько потребителей, которые подписываются на записанные в нее данные.
Каждая тема Kafka всегда разбита на разделы. Даже если у вас один раздел, он все равно там. Каждый раздел представляет собой упорядоченную неизменяемую последовательность записей, которая постоянно добавляется в структурированный журнал фиксации. Каждой записи в разделах присваивается порядковый номер идентификатора, называемый смещением.
Вы можете получать данные из нескольких разделов с помощью одного потребителя, но вы должны знать, что их гарантированный порядок доставки будет поддерживаться в наборе данных из одного раздела. Это означает, что вы не должны полагаться на многораздельный порядок сообщений в своей бизнес-логике.
Kafka продюсеры
Производитель Kafka - это приложение или процесс, который отправляет сообщения Kafka.
Потребители Kafka и группы потребителей
Потребитель Kafka - это приложение, которое читает сообщения от Kafka.
Потребитель может начать чтение сообщений с любого смещения. Это означает, что вы можете создавать системы, которые будут запускаться с начала темы и воспроизводить все события / сообщения, которые содержит Kafka или которые будут начинаться с текущей позиции, и работать только с новыми поступающими сообщениями.
В большинстве случаев для первого запуска потребителя вы выбираете один из них, а позже вы всегда будете потреблять от последнего смещения, с которым вы работали, до выключения потребителя, но все же хорошо знать, что вы всегда можете начать с любого желаемого смещения. Это позволяет потребителям присоединяться к кластеру в любой момент.
Потребители могут быть организованы в группы. В группу потребителей входят потребители, которые подписываются на одни и те же темы. Kafka назначит каждому потребителю в группе набор разделов, с которыми он будет работать. Этот подход позволяет вам значительно масштабироваться, поскольку вы можете увеличить количество разделов и привлечь больше потребителей в одной и той же группе потребителей. Kafka гарантирует, что сообщение будет прочитано только одним потребителем в группе.
У вас может быть больше потребителей, чем разделов, но они не будут активно участвовать в процессе потребления. Они начнут выполнять работу в случае сбоев или других отказов других потребителей.
Стоит отметить, что Kafka никогда не отправляет сообщения потребителям самостоятельно. Это потребитель запрашивает сообщения, когда готов их обработать. Этот подход очень гибкий, так как он позволяет вам временно выключить потребителя, а после его возврата он будет догонять все сообщения, которые еще не были обработаны. Действительно отличная функция для микросервисов на основе SOA, которая не теряет никаких данных. В худшем случае они просто обработают их чуть позже.
Что Kafka может сделать для меня и моих приложений Ruby on Rails?
Примечание. Мы подробно рассмотрим все эти преимущества в следующих частях этой серии. Вот лишь краткое изложение.
Много. И это действительно зависит от вашей точки зрения и вашей роли в организации. Использование Kafka в качестве основы сообщений для систем Ruby и Rails принесет вам пользу во многих местах.
Представление
Большинство систем Ruby on Rails разрабатываются с учетом конкретных целей. Это верно как для сквозных клиентских запросов, так и для фоновых заданий Sidekiq.
Необходимость обновлять или пересчитывать некоторые вещи в системе при изменении, которое часто случается во время всплесков, которые происходят время от времени? Перестройка этой части системы и возможность получать сообщения партиями могут значительно снизить потребность в постоянном пересчете.
Системы на основе Kafka также действительно хорошо масштабируются, а благодаря модели подписки для нескольких потребителей вы можете оптимизировать и масштабировать отдельные части системы независимо.
Архитектура
Это, безусловно, самое большое преимущество, которое вы получите от своих систем Ruby и Rails, когда добавите к ним Kafka. Вы сможете разрабатывать, строить и тестировать независимые компоненты, которые могут делать что-то за пределами типичной области обработки Rails, подобной HTTP.
Вам не придется беспокоиться (почти) ни о чем другом, кроме ограниченного контекста и домена вашего бизнеса. Из-за того, как работает Kafka, иногда вам даже придется использовать инструменты и решения, отличные от Rails.
Удалось ли вам создать доказательство концепции приложения, которое можно было бы подключать в реальном времени к постановке или производству без появления побочных эффектов? Удалось ли вам запустить его со своего локального компьютера и посмотреть, как все работает? С Kafka это может быть очень просто.
Примечание. Не поймите меня неправильно, это не сам Kafka в вашем стеке, который автоматически все изменит. Это вы, имея это и понимаете, чего с его помощью можно достичь, кто инициирует и возглавит изменение. Kafka просто позволит вам делать это легко и быстро.
Процесс развертывания
Возможность повторно использовать и повторно обрабатывать сообщения позволяет отключать определенные части системы, не затрагивая другие. Поскольку сообщения Kafka не отправляются, они не исчезают, если не потребляются немедленно. Имея немного хорошей архитектуры, вы можете развертывать, выполнять обслуживание и делать другие вещи, пока система работает, без ведома пользователей.
Производительность разработки
Чем больше становится система, тем чаще разработчики наступают друг другу на пятки. Затраты на разработку и разочарование разработчиков будут расти экспоненциально, если они:
- изменить одно и то же одновременно,
- необходимо помнить о крайних случаях, выходящих за рамки нашей текущей бизнес-области,
- приходится иметь дело с дополнительными действиями обратного вызова и / или неявными процессами.
Kafka позволяет вам легко использовать DDD для создания систем, основанных на событиях, которыми можно управлять и разрабатывать с гораздо меньшими накладными расходами, чем типичная система Ruby on Rails MVC, основанная на обратном вызове.
Свобода выбора
Ruby on Rails время от времени может быть обузой. Обычный Ruby действительно хорошо справляется. ActiveRecord можно заменить на ROM и Dry-Validation, что принесет вам множество преимуществ. Однако может быть действительно сложно ввести новые концепции в огромную устаревшую систему. Если у вас есть Kafka и Karafka, вы можете развернуть новые экспериментальные приложения, которые будут работать в ограниченном контексте и не причинят никакого вреда существующей логике и / или данным.
Устали от Руби в целом? Замените один компонент на основе Kafka на другой с другой технологией, которая может лучше соответствовать вашим потребностям.
У меня уже есть шина сообщений (Redis + Sidekiq)
Кафка - это не шина сообщений. Это распределенная потоковая платформа.
Сравнивать их не совсем точно, поскольку они не совпадают. Есть много бизнес-кейсов, которые можно решить с помощью любого из них. Однако есть некоторые существенные различия, если смотреть с точки зрения Sidekiq, которые полезно знать и понимать:
- Kafka не обрабатывает повторный вход - в случае сбоя обработки сообщения решать вам, что с этим делать. Он не будет автоматически возвращен и повторен,
- Kafka не поддерживает повторную отправку того же сообщения в очередь (вы можете отправить его обратно, но это будет новое сообщение в разделе). Сообщения неизменяемы и после размещения в Kafka не могут быть изменены,
- Sidekiq не поддерживает рассылку сообщений и более ориентирован на команды, чем на события (do-this vs did-this), особенно в рамках Ruby on Rails и Sidekiq.
- Sidekiq не поддерживает пакетное потребление,
- Kafka может хранить события намного (по желанию) дольше из-за постоянства,
- События Kafka могут использоваться несколько раз несколькими группами потребителей,
- Kafka может быть единственной шиной сообщений для любых потоков публикации-подписки,
- Использованное сообщение Sidekiq удаляется из очереди, что означает, что вы не можете повторно использовать его при необходимости.
В некоторых ситуациях действительно хорошо, когда они работают вместе, поэтому есть даже бэкэнд Karafka Sidekiq для обработки сообщений Kafka внутри рабочих Sidekiq. Мы вернемся к этому в следующих частях этой серии.
Резюме - Карафка как основа Ruby Kafka
Все это введение преследовало одну цель: познакомить вас с основными концепциями и преимуществами использования Kafka с вашими новыми и существующими системами на основе Ruby и Rails.
В следующих частях этой серии мы рассмотрим Karafka, фреймворк, используемый для упрощения разработки приложений Ruby на основе Apache Kafka.
Мы начнем с создания небольших приложений, использующих Karafka в качестве внутренней и внешней магистрали сообщений, а затем перейдем к интеграции Karafka с существующими монолитами и их использованию для декомпозиции и изменения существующей базы кода.
Где-то в дальнейшем в этой серии я также представлю другие инструменты стека, не относящиеся к Rails, включая Traiblazer, Dry-Validation, ROM и некоторые другие, чтобы дать вам более широкое представление о том, сколько вы можете выгода при сочетании правильных инструментов.
Karafka предоставляет вам множество возможностей, и вы сами убедитесь, что при использовании других отличных инструментов качество вашего кода, архитектура, производительность и способ работы могут перейти на совершенно другой уровень.
Будьте на связи :-)
Изначально опубликовано в Running with Ruby.
