Блог

У меня есть 3 микросервиса, например, A, B, C. Службы A выполняют некоторые задачи и соответствующим образом обновляют свою базу данных. То же самое для остальных двух служб.

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

Как мне правильно обработать этот сценарий, если —

1. У меня есть одна общая база данных для всех служб?
2. Отдельные базы данных, связанные с каждой службой?

Спасибо за ваши ответы!

Для отдельных баз данных вы можете использовать шаблон архитектуры SAGA в Google. Это помогает вам управлять транзакциями между различными микросервисами, каждый из которых имеет соответствующую базу данных. Мне потребовалось бы много места, чтобы описать это здесь, поэтому я думаю, что лучший совет, который я могу вам дать, — это сослаться на эту статью Шаблон САГИ для архитектуры базы данных для каждой службы

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

Здесь вы можете рассмотреть несколько подходов:

1. Каждый микросервис обновляет свою собственную базу данных и информирует другие о том, что произошло обновление. Это позволяет каждому микросервису привести в соответствие свою собственную базу данных (в конечном итоге согласованную).
2. Лучшим подходом, если вам нужна координация, является создание четвертого координирующего микросервиса, задачей которого является организация трех других микросервисов. Исследуйте шаблон saga. Это особенно полезно, если вам нужна транзакционная координация (т. Е. Все службы должны обновлять свои базы данных или ни одна из них). Если вы считаете, что вам нужна транзакционная координация, подумайте еще раз очень тщательно — во многих (большинстве?) Ситуациях в конечном итоге последовательности достаточно. Если вам действительно нужна транзакция, то вам следует изучить саги и схемы проскальзывания маршрутизации, которые включают компенсацию в случае сбоя.

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

Хорошим методом обеспечения взаимодействия микросервисов является использование шины сообщений, такой как RabbitMQ или Azure Service Bus, но есть много других вариантов, включая Spring Boot.

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

Вы можете использовать RabbitMQ для обмена сообщениями между микросервисами. RabbitMQ будет содержать всю информацию об обновлении базы данных. Таким образом, даже если микросервис умрет до обновления базы данных, то, когда микросервис снова запустится, он заглянет в RabbitMQ и узнает, что он пропустил. Таким образом, он может выполнять обновление базы данных после восстановления после сбоя.