Как стать автором
Обновить

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

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров4.5K
Всего голосов 9: ↑8 и ↓1+9
Комментарии10

Комментарии 10

Интересная статья, спасибо! Подскажи пожалуйста, а предусмотрена ли возможность, чтобы сообщения читались в строгом порядке на косюмере, для одной сущности?
Например в кафке это делается через partition key, в rabbitmq через x-modulus-hash.

Добрый день! Спасибо за вопрос!

Мы специально не полагались на возможность доставки сообщений в определенном порядке. Саму возможность добавить можно. Но я бы старался ещё на этапе проектирования не полагаться на строгую последовательность.

Ещё раз спасибо и надеюсь, получилось ответить на вопрос.

Понял, спасибо:) Был случай, когда у нашей сущности было состояние и для стейт машины на другом микросервисе был важен порядок.

Добрый день! Спасибо за статью!

Разве отсутствие знания природы шины не приводит к тому, что разработчик ничего не знает о ее гарантиях, что в свою очередь может породить различные проблемы обработки: дубли, потеря ивентов и тд?

Также скрытие реализации шины может привести к тому, что разработчик не знает, как много сообщений консумер

Добрый день!

Разве отсутствие знания природы шины не приводит к тому, что разработчик ничего не знает о ее гарантиях, что в свою очередь может породить различные проблемы обработки: дубли, потеря ивентов и тд?

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

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

На всякий случай оставлю пару ссылок про идемпотентность для других наших читателей (они не имеют прямого отношения к шине событий, но дают хорошее представление о вопросе):

Также скрытие реализации шины может привести к тому, что разработчик не знает, как много сообщений консумер (...)

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

Спасибо за статью

Вы рассматривали вариант использования стандартной (для Кафки) сериализации AVRO и schema registry ?

Просто, если абстрагироваться от деталей в статье, мы имеем классическую ситуацию "14 competing standards" из xkcd.

Добрый день и спасибо за вопрос!

Вы рассматривали вариант использования стандартной (для Кафки) сериализации AVRO и schema registry ?

В какой-то момент я хотел положиться на schema registry, но если я не ошибаюсь, туда можно складывать только AVRO. Здесь я не возьмусь утверждать.

Ещё одним аргументом за формат protobuf, конечно же, является хорошее знание и опыт применения всеми разработчиками gRPC. То есть мы не добавили ещё один формат/язык/инструмент, а остались в рамках тех, что умеем готовить хорошо и применяем каждый день.

Просто, если абстрагироваться от деталей в статье, мы имеем классическую ситуацию "14 competing standards" из xkcd.

Нет-нет, речи ещё об одном стандарте не идёт и идти не может. Я бы назвал это скетчем, если угодно. Тезисный рассказ о том, как можно было бы поступить, если вам нужно в сжатые сроки и хорошо известными инструментами сохранить порядок и предсказуемость в вашей шине.

Понятно

Получается статья о том, как перейти на очереди, сохранив корпоративный стандарт передачи данных (протобаф)

Тогда написание корпоративного "адаптера" для Кафки имеет смысл.

А зачем структура payload? Это не ответственность шины, ответственность шины - передать метаданные и байты сообщения с определёнными гарантиями.

Вопрос гарантий доставки также не раскрыт. Что будет, если сообщение провалится ещё до условной кафки под капотом?

Добрый день!

А зачем структура payload? Это не ответственность шины, ответственность шины - передать метаданные и байты сообщения с определёнными гарантиями.

Если говорить на самом низком уровне, Вы совершенно правы, шина — это про гарантированную доставку.

А если подняться на уровень продукта, то схема данных выходит уже на первый план. Вам же важно не только что-то отправить и получить, а ещё и на принимающей стороне суметь однозначно понять, что именно вам пришло. И автоматически получить заполненную структуру данных для дальнейшей работы. Неужели вы не попадали в ситуацию, когда новое поле или измененный тип данных в API ломал вам сериализацию/маршализацию?

Вопрос гарантий доставки также не раскрыт. Что будет, если сообщение провалится ещё до условной кафки под капотом?

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий