Руководство по шаблонам и рекомендации по достижению атомарности базы данных в распределенной архитектуре (микросервисы)

Question

Ребята, я оцениваю варианты / шаблоны и практики, связанные с ключевой проблемой поддержания атомарности БД (для нескольких таблиц), с которой мы сталкиваемся в распределенной (микросервисной) архитектуре.

Атомность, надежность и масштабность - все это очень важнодля бизнеса (это может быть обычным явлением для всего бизнеса, просто поставить его там).

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

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

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

Цените ваше время и усилия.

Answer 1

CAP теорема

Теорема CAP - ключ к распределенным системам. Начните с этого, чтобы узнать, хотите ли вы доступность против согласованности.

Распределенные транзакции

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

SAGA vs 2PC

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

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

У меня нет наследства. С чего вы взяли, что у устаревших БД будут проблемы? SAGA не имеет ничего общего с устаревшей системой. Это просто означает, если вы должны принять событие или нет. Если да, то сохраните его в базе данных. Если нет, то поднять компенсацию транзакции, чтобы все другие услуги могли отменить.

Какой правильный подход?

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

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

Answer 2

Один из возможных вариантов - это разделение ответственности по командным запросам (CQRS) - поддержка одного или нескольких материализованных представлений, которые содержат данные из нескольких служб.Представления хранятся службами, которые подписываются на события, которые каждая служба публикует при обновлении своих данных.Например, интернет-магазин может реализовать запрос, который находит клиентов в определенном регионе и их последние заказы, поддерживая представление, объединяющее клиентов и заказы.Представление обновляется службой, которая подписывается на события клиента и заказа.