Начните с плана подготовки, как я уже писал. Проработайте сначала структуры данных, поймите, почему они такие. А дальше переходите уже к самим алгоритмам, решая разные задачи, разбитые по темам.
А зачем структура payload? Это не ответственность шины, ответственность шины - передать метаданные и байты сообщения с определёнными гарантиями.
Если говорить на самом низком уровне, Вы совершенно правы, шина — это про гарантированную доставку.
А если подняться на уровень продукта, то схема данных выходит уже на первый план. Вам же важно не только что-то отправить и получить, а ещё и на принимающей стороне суметь однозначно понять, что именно вам пришло. И автоматически получить заполненную структуру данных для дальнейшей работы. Неужели вы не попадали в ситуацию, когда новое поле или измененный тип данных в API ломал вам сериализацию/маршализацию?
Вопрос гарантий доставки также не раскрыт. Что будет, если сообщение провалится ещё до условной кафки под капотом?
Возможно, я не понял или понял Ваш вопрос не правильно. Слабо верится, что можно потерять сообщение до отправки в покрытой тестами и автоматически генерирующейся обертке. Если я не так понял, дайте, пожалуйста, больше контекста.
Вы рассматривали вариант использования стандартной (для Кафки) сериализации AVRO и schema registry ?
В какой-то момент я хотел положиться на schema registry, но если я не ошибаюсь, туда можно складывать только AVRO. Здесь я не возьмусь утверждать.
Ещё одним аргументом за формат protobuf, конечно же, является хорошее знание и опыт применения всеми разработчиками gRPC. То есть мы не добавили ещё один формат/язык/инструмент, а остались в рамках тех, что умеем готовить хорошо и применяем каждый день.
Просто, если абстрагироваться от деталей в статье, мы имеем классическую ситуацию "14 competing standards" из xkcd.
Нет-нет, речи ещё об одном стандарте не идёт и идти не может. Я бы назвал это скетчем, если угодно. Тезисный рассказ о том, как можно было бы поступить, если вам нужно в сжатые сроки и хорошо известными инструментами сохранить порядок и предсказуемость в вашей шине.
Разве отсутствие знания природы шины не приводит к тому, что разработчик ничего не знает о ее гарантиях, что в свою очередь может породить различные проблемы обработки: дубли, потеря ивентов и тд?
Давайте будем честны. Разработчик так или иначе знает, что под капотом в данный момент Kafka. И он так же знает про гарантии доставки. В статье об этом не сказано, но каждое сообщение снабжается ключом идемпотентности.
Основная же цель такого подхода — дать возможность общаться строго типизированными сообщениями, описывая их на привычном языке (protobuf), и снять с разработчика рутинные операции по написанию шаблонного кода. Это очень ускоряет как сам процесс реализации задачи, так и процесс ревью — вы просто игнорируете шаблонный сгенерированный код.
На всякий случай оставлю пару ссылок про идемпотентность для других наших читателей (они не имеют прямого отношения к шине событий, но дают хорошее представление о вопросе):
Мы специально не полагались на возможность доставки сообщений в определенном порядке. Саму возможность добавить можно. Но я бы старался ещё на этапе проектирования не полагаться на строгую последовательность.
Ещё раз спасибо и надеюсь, получилось ответить на вопрос.
В большинстве сервисов миграции запускаются в одном из init-контейнеров.
При этом свежие поды недоступны, пока не пройдёт redinessProbe, в этом заключается очевидное преимущество такого подхода.
Мы используем своё решение для миграций, не хуже и не лучше других OSS-решений, просто оно учитывает некоторую специфику.
Если же ваш фреймворк поддерживает накат миграций при старте приложения — отлично, вы можете использовать и этот способ. Тогда убедитесь, что redinessProbe на новых подах не будет проходить до тех пор, пока база не будет приведена в ожидаемое состояние. Очень часто эндпоинты проверки (/info, /health, /healtz — не важно, как называется) не проверяют готовность, просто отвечают кодом 200.
Что же касается ревью самих миграций.
Большинство миграций содержат в себе определения новых таблиц — с этой задачей справится любой разработчик.
Когда требуется, на помощь приходит команда DBA.
Они же следят (благодаря мониторингу) за состоянием индексов, что-то перестраивают, что-то удаляют.
Поэтому построение/перестроение индекса в concurrenly-режиме — скорее исключение, чем правило.
Мы тоже храним файлы с миграциями в sql-формате.
Поэтому на определённом коммите можем посмотреть только сами миграции.
Свои варианты DDL (отличные от sql) не рассматривались в принципе, так как требуют разработки (что очень непросто) и изучения теми, кто будет их использовать.
Если говорить простым языком, то:
Миграции в sql-формате разложены по подпапкам с именами баз данных (их много) в репозитории с проектом;
Мигратор накатывает неприменённые миграции последовательно на каждую базу данных и заносит информацию о применении миграции в служебную таблицу в той же базе;
Миграции делятся на два вида: линейные (простые) и повторяемые. Линейные выполняются один раз. Повторяемые выполняются каждый раз, как только меняется контрольная сумма sql-файла.
Понимаете, всё предельно просто и не требует никаких специальных знаний.
Мы создали свой инструмент, который очень похож на продукты с открытым исходным кодом.
Информация о примененных миграциях хранится в той же базе, на которую они накатываются.
Доброе утро!
Если понадобится, обращайтесь за советом!
Не на правах рекламы, я бы ещё предложил Вам обратить внимание на этот пост: https://habr.com/ru/companies/avito/articles/527400/ — я участвовал в разработке внутреннего PaaS в Avito.
Спасибо за отзыв!
Начните с плана подготовки, как я уже писал. Проработайте сначала структуры данных, поймите, почему они такие. А дальше переходите уже к самим алгоритмам, решая разные задачи, разбитые по темам.
Добрый день!
Если говорить на самом низком уровне, Вы совершенно правы, шина — это про гарантированную доставку.
А если подняться на уровень продукта, то схема данных выходит уже на первый план. Вам же важно не только что-то отправить и получить, а ещё и на принимающей стороне суметь однозначно понять, что именно вам пришло. И автоматически получить заполненную структуру данных для дальнейшей работы. Неужели вы не попадали в ситуацию, когда новое поле или измененный тип данных в API ломал вам сериализацию/маршализацию?
Возможно, я не понял или понял Ваш вопрос не правильно. Слабо верится, что можно потерять сообщение до отправки в покрытой тестами и автоматически генерирующейся обертке. Если я не так понял, дайте, пожалуйста, больше контекста.
Добрый день и спасибо за вопрос!
В какой-то момент я хотел положиться на schema registry, но если я не ошибаюсь, туда можно складывать только AVRO. Здесь я не возьмусь утверждать.
Ещё одним аргументом за формат protobuf, конечно же, является хорошее знание и опыт применения всеми разработчиками gRPC. То есть мы не добавили ещё один формат/язык/инструмент, а остались в рамках тех, что умеем готовить хорошо и применяем каждый день.
Нет-нет, речи ещё об одном стандарте не идёт и идти не может. Я бы назвал это скетчем, если угодно. Тезисный рассказ о том, как можно было бы поступить, если вам нужно в сжатые сроки и хорошо известными инструментами сохранить порядок и предсказуемость в вашей шине.
Добрый день!
Давайте будем честны. Разработчик так или иначе знает, что под капотом в данный момент Kafka. И он так же знает про гарантии доставки. В статье об этом не сказано, но каждое сообщение снабжается ключом идемпотентности.
Основная же цель такого подхода — дать возможность общаться строго типизированными сообщениями, описывая их на привычном языке (protobuf), и снять с разработчика рутинные операции по написанию шаблонного кода. Это очень ускоряет как сам процесс реализации задачи, так и процесс ревью — вы просто игнорируете шаблонный сгенерированный код.
На всякий случай оставлю пару ссылок про идемпотентность для других наших читателей (они не имеют прямого отношения к шине событий, но дают хорошее представление о вопросе):
https://stripe.com/docs/api/idempotent_requests
https://brandur.org/idempotency-keys
Ваше сообщение немного оборвалось, как мне показалось, но я отвечу Вам полностью, если дополните ниже.
Добрый день! Спасибо за вопрос!
Мы специально не полагались на возможность доставки сообщений в определенном порядке. Саму возможность добавить можно. Но я бы старался ещё на этапе проектирования не полагаться на строгую последовательность.
Ещё раз спасибо и надеюсь, получилось ответить на вопрос.
Как коллега Саши, давайте я попробую ответить.
В большинстве сервисов миграции запускаются в одном из init-контейнеров.
При этом свежие поды недоступны, пока не пройдёт redinessProbe, в этом заключается очевидное преимущество такого подхода.
Мы используем своё решение для миграций, не хуже и не лучше других OSS-решений, просто оно учитывает некоторую специфику.
Если же ваш фреймворк поддерживает накат миграций при старте приложения — отлично, вы можете использовать и этот способ. Тогда убедитесь, что redinessProbe на новых подах не будет проходить до тех пор, пока база не будет приведена в ожидаемое состояние. Очень часто эндпоинты проверки (/info, /health, /healtz — не важно, как называется) не проверяют готовность, просто отвечают кодом 200.
Что же касается ревью самих миграций.
Большинство миграций содержат в себе определения новых таблиц — с этой задачей справится любой разработчик.
Когда требуется, на помощь приходит команда DBA.
Они же следят (благодаря мониторингу) за состоянием индексов, что-то перестраивают, что-то удаляют.
Поэтому построение/перестроение индекса в concurrenly-режиме — скорее исключение, чем правило.
Надеюсь, получилось ответить на Ваши вопросы.
Мы тоже храним файлы с миграциями в sql-формате.
Поэтому на определённом коммите можем посмотреть только сами миграции.
Свои варианты DDL (отличные от sql) не рассматривались в принципе, так как требуют разработки (что очень непросто) и изучения теми, кто будет их использовать.
Если говорить простым языком, то:
Понимаете, всё предельно просто и не требует никаких специальных знаний.
Мы создали свой инструмент, который очень похож на продукты с открытым исходным кодом.
Информация о примененных миграциях хранится в той же базе, на которую они накатываются.