Наша миссия в Kesque — дать разработчикам возможность создавать распределенные облачные приложения, сделав высокопроизводительную технологию обмена сообщениями независимую от типа облака доступной для всех. Разработчики хотят писать распределенные приложения или микросервисы, но не хотят возиться с управлением сложной инфраструктурой сообщений или быть привязанными к конкретному поставщику облачных услуг. Им нужно решение, которое просто работает. Везде.
Когда вы собираетесь создать лучшую инфраструктуру службы обмена сообщениями, первым делом необходимо выбрать правильную базовую технологию обмена сообщениями. Существует множество вариантов: от различных проектов с открытым исходным кодом, таких как RabbitMQ, ActiveMQ и NATS, до проприетарных решений, таких как IBM MQ или Red Hat AMQ. И, конечно же, есть Apache Kafka, являющийся чуть ли не синонимом потоковой передачи. Но мы выбрали не Apache Kafka, мы выбрали Apache Pulsar.
Итак, почему же мы создали нашу службу обмена сообщениями с использованием Apache Pulsar? Вот семь основных причин, по которым мы выбрали Apache Pulsar вместо Apache Kafka.
1. Потоковая передача и организация очередей в одном решении
Apache Pulsar — это два продукта в одном. Он не только может обрабатывать высокоскоростные real-time юзкейсы, как Kafka, но также поддерживает стандартные шаблоны очередей сообщений, такие как конкурирующие потребители (competing consumers), подписки с переключением при отказе (fail-over subscriptions) и простое ветвление сообщений (message fan out). Apache Pulsar автоматически отслеживает позицию чтения клиента в топике и сохраняет эту информацию в своем высокопроизводительном распределенном реестре Apache BookKeeper.
В отличие от Kafka, Apache Pulsar может обрабатывать многие юзкейсы традиционной системы очередей, такой как RabbitMQ. Таким образом, вместо запуска двух систем — одной для потоковой передачи в реальном времени и одной для организации очередей — вы используете обе системы с Pulsar. Это два по цене одного, что всегда хорошо.
2. Партиции, но можно и без партиций
Если вы используете Kafka, вы точно слышали о партициях. Все топики в Kafka партиционированны. Партиционирование важно, потому что оно увеличивает пропускную способность. Распределяя работу между партициями и, следовательно, несколькими брокерами, рейт, который может обрабатывать один топик, увеличивается. Но что, если у вас есть топики, которые не требуют высоких рейтов. Было бы неплохо в этих простых случаях не беспокоиться о партициях, API и сложности управления, которые с ними связаны?
Что ж, с Apache Pulsar у вас есть выбор. Если вам нужен только топик, то просто используйте топик. Вам не нужно указывать количество партиций или думать о том, сколько потребителей топик может иметь. Подписки Pulsar позволяют вам добавлять столько потребителей, сколько вы хотите для вашего топика, и Pulsar отслеживает все это. Если ваше приложение-потребитель не поспевает, вы просто используете общую подписку для распределения нагрузки между несколькими потребителями.
А если вам в самом деле понадобится производительность партиционированного топика, у вас есть такая опция. Pulsar имеет партиционированные топики, если они вам нужны - но только если они вам нужны.
3. Логи — это хорошо, распределенные логи — лучше
Команда Kafka заслуживает похвалы за понимание того, что лог является отличной абстракцией для системы обмена данными в реальном времени. Поскольку логи предназначены только для добавления данных, данные могут быть записаны в них быстро, а поскольку данные в логе являются последовательными, их можно быстро извлечь в том порядке, в котором они были записаны. Последовательное чтение и запись происходит быстро, а вот случайное — нет. Взаимодействие с постоянным хранилищем является узким местом в любой системе, которая предлагает гарантии данных, и абстракция логов делает это максимально эффективным.
Простые логи — это здорово. Но они могут доставить вам немало хлопот, когда станут большими. Размещение лога на одном сервере становится проблемой. Что произойдет, если он заполнится и вам потребуется масштабирование? А что произойдет, если сервер, на котором хранится лог, выйдет из строя и его нужно будет воссоздать из реплики?
Копирование большого лога с одного сервера на другой, хотя и эффективно, но все же может занять много времени. Если ваша система пытается сделать это, не отставая от данных в реальном времени, это может обернуться серьезным вызовом. Ознакомьтесь с разделом «Добавление нового брокера привело к ужасной производительности» в статье «Истории с фронта: уроки, извлеченные из поддержки Apache Kafka», чтобы узнать об этом подробнее.
Apache Pulsar избегает проблемы копирования больших логов, разбивая логи на сегменты. Он распределяет эти сегменты по нескольким серверам, пока данные записываются, используя Apache BookKeeper в качестве уровня хранения. Это означает, что лог никогда не хранится на одном сервере, поэтому один сервер никогда не является узким местом. Сценарии отказов легче обрабатывать, а масштабирование — несложно. Просто добавьте еще один сервер. Ребалансировка не требуется.
4. Брокеры без состояний, что?
Stateless (без состояний/стейтов) — это музыка для ушей любого, кто создает облачные приложения. Компоненты без состояний запускаются быстро, взаимозаменяемы и легко масштабируются. Разве не было бы замечательно, если бы брокер сообщений не имел состояний?
Брокер Kafka не stateless. Каждый брокер содержит полный лог для каждой из своих партиций. Если один брокер отказывает, не любой брокер может его заменить. Если нагрузка становится слишком высокой, вы не можете просто добавить еще одного брокера. Брокеры должны синхронизировать состояние с другими брокерами, которые содержат реплики их партиций.
В архитектуре Apache Pulsar брокеры не имеют состояния. Да, вы не ослышались. Система совсем без состояний не сможет сохранять сообщения, поэтому Apache Pulsar поддерживает состояния, но не в брокерах. В архитектуре Pulsar передача данных отделена от хранения данных. Брокеры принимают данные от продюсеров и отправляют данные потребителям, но данные хранятся в Apache BookKeeper.
Поскольку брокеры Pulsar не имеют состояний, если нагрузка становится высокой, вам просто нужно добавить еще одного брокера. Брокер быстро запускается и сразу же приступает к работе.
5. Георепликация для чайников
Георепликация — это первоклассная фича Pulsar. Это не надстройка или проприетарное дополнение. Pulsar был разработан с учетом георепликации. Настроить ее легко, и она просто работает. Итак, будь то глобально распределенное приложение или сценарий аварийного восстановления, вы можете настроить его с помощью Pulsar. Научной степенью обладать не нужно.
6. Устойчиво быстрее
Тесты производительности показали, что Pulsar обеспечивает более высокую пропускную способность при более низкой и стабильной задержке. Чем быстрее и устойчивее, тем лучше. Что тут еще можно сказать?
7. Это все тот же Apache с открытым исходным кодом
Pulsar имеет многие из тех же фич, что и Kafka, такие как георепликация, обработка сообщений в потоке (Pulsar Functions), входные и выходные коннекторы (Pulsar IO), тематические запросы на основе SQL (Pulsar SQL), реестр схем, а также фичи, которых нет в Kafka, таких как многоуровневое хранилище и мультитенантность.
Все эти фичи являются частью проекта с открытым исходным кодом Apache.
Pulsar — это не набор функций с открытым и закрытым исходным кодом или функций с открытым исходным кодом, контролируемых коммерческой организацией. Все его многочисленные полезные функции имеют открытый исходный код под эгидой Apache. И если не произойдет что-то немыслимое, все это добро останется опенсорсным.
Заключение
Как видите, у нас было много причин выбрать Apache Pulsar для создания нашей инфраструктуры обмена сообщениями. И мы даже не вдавались в причины, по которым создать сервис проще на основе Pulsar, например, мультитенантность, пространства имен, аутентификация и авторизация, документация, удобство использования Kubernetes.
Если вы хотите создать инфраструктуру обмена сообщениями, попробуйте Pulsar. Вы не пожалеете.
Хотите попробовать Apache Pulsar? Подпишитесь сейчас на Astra Streaming, нашу полностью управляемую службу Apache Pulsar. Мы предоставим вам доступ ко всем его возможностям совершенно бесплатно через бету. Убедитесь сами, насколько легко создавать современные приложения для обработки данных, и сообщите нам, что вы хотели бы увидеть, чтобы сделать вашу работу еще лучше.
(Примечание редактора: DataStax приобрела Kesque в январе 2021 года)
Материал подготовлен в рамках курса "Data Engineer". Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн.
Регистрация здесь.
