Основанная на событиях связь между микросервисами без общей библиотеки событий?

Question

Я изучаю микросервисы.

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

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

Принимаю ли я сумасшедшие таблетки? Разве эти микросервисы не связаны с этими событиями, если они полагаются на них? Если да, то в чем преимущество кодирования одинаковых событий с одинаковым определением в двух (или даже более) разных местах? Разве это не полное нарушение принципа СУХОЙ?

Я начинаю чувствовать запах кода, который начинается с инициалов BS. Поможет ли кто-нибудь мне выпить остаток этого коалаида? Или я просто видел императора на секунду без одежды?

Answer 1

Если да, то в чем преимущество кодирования одинаковых событий с одинаковым определением в двух (или даже более) разных местах?

Там может быть ряд преимуществ - микросервисы могут быть реализованы с использованием разных языков. Или используя один и тот же язык, но разные представления в памяти данных для удовлетворения конкретных потребностей. Или даже «то же самое» в представлениях памяти, но в разных версиях , потому что они находятся в разных расписаниях развертывания.

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

Две службы, которые соглашаются, что сообщения будут использовать кодированные в кодировке UTF-8 документы JSON, не требуютсяиспользовать тот же parser - выбор синтаксического анализатора является деталью реализации. Связь осуществляется со схемой (соглашение о семантике байтов в сообщении), а не с реализацией.

Answer 2

Если вы рассматриваете события как простые объекты данных, вам не нужна библиотека для их обработки - кроме общего кода обмена сообщениями и сериализации / десериализации.

Весь смысл микросервисов в том, чтобы иметь независимую разработкуциклы, поэтому, как только вы вводите общую библиотеку, вы начинаете делать «распределенный монолит». Любое изменение в этой библиотеке приведет к перераспределению всех микросервисов.

Без библиотеки событий, единственной зависимостью, которую вы представляете, является знание структуры конкретного события из другого микросервиса. Ну, это неизбежное зло.