Шаблоны репликации данных микросервисов

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

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

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

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


microservices apache-kafka event-driven database-replication eventual-consistency
person Fabio    schedule 12.03.2019    source источник

Ответы (2)


arrow_upward
5
arrow_downward

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

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

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

person Saptarshi Basu    schedule 12.03.2019

arrow_upward
1
arrow_downward

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

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

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

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

person Imran Arshad    schedule 12.03.2019