Блог

В микросервисной архитектуре у нас обычно есть два способа взаимодействия двух микросервисов. Допустим, службе A необходимо получить информацию от службы B. Первый вариант — это удаленный вызов, обычно синхронный по протоколу HTTPS, поэтому для обслуживания запроса используется API, размещенный службой B.

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

Первая из них — это высокое потребление дискового пространства, поскольку одни и те же данные могут находиться в базах данных микросервисов, которым это необходимо. Но второй вариант, на мой взгляд, наихудший: данные могут устареть, если служба B не может обработать свою подписку так быстро, как это необходимо, или они не могут быть доступны для службы A в то же время, когда они создаются в службе B, учитывая конечную согласованность модели.

Допустим, мы используем Kafka в качестве центра событий, и его разделы настроены на хранение данных в течение 7 дней. Служба A поддерживается в синхронизации, поскольку служба B публикует свое состояние. Через две недели развернута новая служба C, и ее база данных должна быть обогащена всей информацией, хранящейся в службе B. Мы можем получить только частичную информацию из разделов Kafka, поскольку самые старые события исчезли. Мой вопрос здесь в том, какие шаблоны мы можем использовать для обогащения базы данных этого микросервиса (помимо запроса сервиса B повторно опубликовать все его текущее состояние в event hub).

Есть 2 варианта:

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

2. Предполагая, что вы ежедневно делаете резервную копию базы данных service B, при внедрении новой службы C вам необходимо сначала создать начальное состояние C из последней резервной копии B, а затем воспроизвести события раздела Kafka с определенным идентификатором смещения, который представляет данные после резервного копирования.

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

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

Еще одна вещь, касающаяся микросервиса, заключается в том, что вы сохраняете только ссылку на данные из другого сервиса, и фактических данных из другого сервиса может быть очень мало, но определенно не так много. И это тоже, только если репликация данных делает ваш сервис независимым и автономным, если вы не можете достичь ничего из этого даже после репликации данных, тогда в этом нет смысла. например, Ваша служба доставки будет иметь полную историю перехода заказа, но ваша служба бронирования будет иметь только последний статус заказа (например, в пути, на борту и т.д.). Пользователь переходит к бронированию, и вы показываете текущий статус заказа. Но если пользователь нажмет подробнее, вы получите всю историю перехода заказа из службы доставки microservice. Теперь в какой-то момент ваша служба доставки выходит из строя, и ваш пользователь приходит проверить статус, по крайней мере, у вас есть текущий статус заказа, даже если вы не можете показать детали, потому что статус заказа копируется в службе бронирования.

Что касается новых сервисов, присоединяющихся к системе на более позднем этапе, то для сценариев такого рода используется шаблон поиска событий. Это сложный шаблон, но он приведет ваши недавно добавленные сервисы в то состояние, в котором вы хотите, чтобы они были. По сути, вы сохраняете все свои события в хранилище событий и воспроизводите их для достижения текущего состояния системы и предварительного заполнения базы данных service C этими событиями.