Комментарии 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 ломал вам сериализацию/маршализацию?
Вопрос гарантий доставки также не раскрыт. Что будет, если сообщение провалится ещё до условной кафки под капотом?
Возможно, я не понял или понял Ваш вопрос не правильно. Слабо верится, что можно потерять сообщение до отправки в покрытой тестами и автоматически генерирующейся обертке. Если я не так понял, дайте, пожалуйста, больше контекста.
Как мы сделали для разработчиков универсальную шину событий, не требующую знаний Kafka и прочих брокеров