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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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