Введение
Традиционные методы обработки и получения данных (такие как пакетная обработка и опрос) неэффективны в контексте микросервисов, используемых в современных приложениях. Эти методы работают с большими объёмами данных, что приводит к задержке получения конечного результата и вынуждает накапливать значительный объём данных перед обработкой. Они создают дополнительную сложность, необходимую для синхронизации исполнителей, и потенциально приводят к неполной загрузке некоторых из них, несмотря на их ресурсоёмкость. В отличие от этого, поскольку облачные вычисления обеспечивают быструю масштабируемость локальных ресурсов, входящие данные можно обрабатывать в режиме реального времени, делегируя их нескольким исполнителям параллельно.
Потоковая передача событий — это подход к гибкому сбору и делегированию входящих событий для обработки с сохранением непрерывного потока данных между различными системами. Планирование входящих данных для немедленной обработки обеспечивает максимальное использование ресурсов и оперативное реагирование. Потоковая передача событий разделяет производителей и потребителей, позволяя использовать непропорционально большое количество каждого из них в зависимости от текущей нагрузки. Это позволяет мгновенно реагировать на динамические условия реального мира.
Такая оперативность может быть особенно важна в таких областях, как финансовая торговля, мониторинг платежей или дорожного движения. Например, Uber использует потоковую передачу событий для подключения сотен микросервисов, передавая данные о событиях из приложений для взаимодействия между пассажирами и водителями в режиме реального времени и архивируя их для последующего анализа.
Благодаря широковещательной рассылке событий, вместо традиционного ожидания исполнителем пакета данных с регулярным интервалом, брокер событий может уведомить потребителя (обычно микросервис) сразу после возникновения события и предоставить ему данные о событии. Брокер событий отвечает за маршрутизацию, получение и доставку событий. Он также обеспечивает отказоустойчивость в случае сбоя исполнителя или отказа обрабатывать событие.
В этой концептуальной статье мы рассмотрим подход к потоковой передаче событий и его преимущества. Мы также познакомимся с Apache Kafka, брокером событий с открытым исходным кодом, и рассмотрим его роль в этом подходе.
Архитектура потока событий
По своей сути, поток событий представляет собой реализацию архитектурного шаблона pub/sub. В общем случае шаблон pub/sub включает в себя:
- Темы, которым адресованы сообщения (включая любые данные, которые вы хотите передать).
- Издатели, которые создают сообщения
- Подписчики, которые получают сообщения и действуют в соответствии с ними
- Брокер сообщений, который принимает сообщения от издателей и доставляет их подписчикам наиболее эффективным способом.
Тема аналогична категории, к которой привязано сообщение. Темы постоянно хранят последовательность сообщений и обеспечивают добавление новых сообщений в конец последовательности. После добавления сообщения в тему его нельзя изменить.
В случае с трансляцией событий предпосылка та же, хотя и более специализированная:
- События и связанные с ними метаданные отправляются в виде сообщений.
- События в теме обычно сортируются по времени появления.
- Подписчики (также называемые потребителями) могут транслировать события с любой точки потока вплоть до текущего момента.
- В отличие от фактической публикации/подписки, события по теме могут храниться в течение определенного периода времени или храниться бесконечно (в виде архива).
Поток событий не накладывает никаких ограничений и не делает никаких предположений о природе события. С точки зрения базового брокера, это означает, что производитель уведомил его о том, что что-то произошло. Что именно произошло, вы определяете и осмысливаете в своей реализации. По этой причине, с точки зрения брокера, события называются сообщениями или записями взаимозаменяемо.
Для иллюстрации приводим подробную схему архитектуры потока событий Kafka из документации Confluent:
Существует две модели получения данных потребителями от брокера: push и pull. Push означает, что брокер событий инициирует процесс отправки данных изначально доступному потребителю, а pull означает, что потребитель запрашивает последующие доступные записи у брокера. Это различие кажется безобидным, но на практике pull предпочтительнее.
Одна из основных причин, по которой push-уведомления не получили широкого распространения, заключается в том, что брокер не может быть уверен, что потребитель действительно сможет отреагировать на событие. В результате он может отправлять событие несколько раз без необходимости, сохраняя его в теме. Брокеру также следует рассмотреть возможность пакетной обработки событий для повышения пропускной способности, что противоречит идее максимально быстрой трансляции.
Получение данных потребителем по мере готовности к обработке сокращает ненужный сетевой трафик и повышает надёжность. Это гарантирует, что данные будут получены только тогда, когда они будут готовы к обработке. Время обработки зависит от бизнес-логики и влияет на распределение количества рабочих процессов. В обоих случаях брокер должен помнить, какие события подтвердил потребитель.
Теперь, когда вы знаете, что такое потоковая передача событий и на какой архитектуре она основана, вы узнаете о преимуществах этого динамического подхода.
Преимущества потоковой трансляции событий
Основные преимущества трансляции событий:
- Согласованность: брокер событий обеспечивает правильную отправку событий всем заинтересованным потребителям.
- Отказоустойчивость: если потребитель не принимает событие, его можно перенаправить в другое место, чтобы гарантировать, что ни одно событие не останется необработанным.
- Повторное использование: события, хранящиеся в потоке, неизменяемы. Их можно воспроизвести полностью или с определённого момента времени, что позволяет повторно обрабатывать события при изменении бизнес-логики.
- Масштабируемость: производители и потребители являются отдельными сущностями и не должны ждать друг друга, что означает, что их масштаб можно динамически увеличивать или уменьшать в зависимости от спроса.
- Простота использования: брокер событий управляет маршрутизацией и хранением событий, абстрагируя сложную логику и позволяя вам сосредоточиться на самих данных.
Каждое событие должно содержать только необходимую информацию о нём. Брокеры событий, как правило, очень эффективны, и хотя рекомендуется, чтобы события не исчезали после регистрации в теме, их не следует рассматривать как традиционную базу данных.
Например, было бы неплохо показать, что количество просмотров статьи изменилось, но нет необходимости хранить вместе с этим фактом всю статью и её метаданные. Вместо этого событие может содержать ссылку на идентификатор статьи во внешней базе данных. Таким образом, историю можно отслеживать, не добавляя лишнюю информацию и не засоряя ветку.
Теперь вы узнаете об Apache Kafka и других популярных брокерах событий, чем они отличаются друг от друга и как вписываются в экосистему потоковой трансляции событий.
Роль Апачи Кафки
Apache Kafka — это брокер событий с открытым исходным кодом, написанный на Java и поддерживаемый Apache Software Foundation. Он состоит из распределённых серверов и клиентов, взаимодействующих по специальному сетевому протоколу TCP для максимальной производительности. Kafka отличается высокой надёжностью и масштабируемостью, может работать на виртуальных машинах, физическом оборудовании, контейнерах и других облачных средах.
Для обеспечения надежности Kafka развёртывается как кластер из одного или нескольких серверов. Этот кластер может охватывать несколько облачных регионов и центров обработки данных. Кластеры Kafka отказоустойчивы, то есть в случае сбоя или отключения сервера оставшиеся серверы перегруппировываются для обеспечения высокой доступности операций без внешнего воздействия и потери данных.
Для достижения максимальной эффективности не все серверы Kafka выполняют одинаковую функцию. Некоторые серверы объединены в группы и действуют как посредники, образуя уровень хранения данных. Другие серверы можно интегрировать с существующими системами и получать данные в виде потоков событий с помощью Kafka Connect — инструмента для надежной потоковой передачи данных из существующих систем (например, реляционных баз данных) в Kafka.
Kafka рассматривает производителей и потребителей как своих клиентов. Как объяснялось ранее, производители передают события брокеру Kafka, который отправляет их заинтересованным потребителям. В конфигурации по умолчанию Kafka гарантирует, что событие в конечном итоге обрабатывается только один раз одним из потребителей.
В Kafka темы разделены на разделы. Это означает, что тема распределяется по частям между разными брокерами Kafka, что обеспечивает масштабируемость. Kafka также гарантирует, что события, хранящиеся в определённой комбинации тем и их разделов, всегда будут считаны в том же порядке, в котором они были записаны.
Обратите внимание, что простое разделение темы не гарантирует избыточности, которая может быть достигнута только путём репликации между регионами и центрами обработки данных. В производственной среде обычно имеется не менее трёх копий кластера, что означает, что всегда доступны три комбинации темы и раздела.
Интеграция с Кафкой
Как уже упоминалось, данные из существующих систем можно импортировать и экспортировать с помощью Kafka Connect. Kafka Connect подходит для импорта целых баз данных, отчётов или показателей с ваших серверов в потоках с низкой задержкой. Kafka Connect предоставляет коннекторы для различных систем данных, позволяющие управлять данными стандартным образом. Ещё одно преимущество использования коннекторов по сравнению с собственными решениями заключается в том, что Connect масштабируется по умолчанию (несколько рабочих процессов можно объединить в группу) и автоматически отслеживает ход выполнения.
Существует множество клиентов, которые могут взаимодействовать с Kafka через ваши приложения. Поддерживаются многие языки программирования, такие как Java, Scala, Python, .NET, C++, Go и другие. Для Java и Scala также доступна высокоуровневая клиентская библиотека Kafka Streams. Эта библиотека абстрагирует внутренние компоненты и позволяет легко подключаться к серверу Kafka и получать широковещательные события.
Результат
В этой статье рассматриваются парадигмы современного подхода к обработке данных и событий на основе потока событий и его преимущества перед традиционными процессами категоризации данных. Вы также узнали об Apache Kafka как о брокере событий и его клиентской экосистеме.
