Согласованность БД с микросервисами

Это супер-красиво и элегантно, но на практике становится немного сложно.

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

эти службы не могут напрямую подключаться к БД, "принадлежащей" другой службе.

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

Теперь к вашему вопросу:

Каковы наилучшие шаблоны, позволяющие сохранять последовательность и жить счастливой жизнью?

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

Если вы используете .NET, некоторые примеры инфраструктуры, поддерживающей такую ​​надежность, включают NServiceBus и MassTransit. Полное раскрытие - я основатель NServiceBus.

Обновление: после комментариев относительно проблем с бонусными баллами: «если обновления баланса обрабатываются с задержкой, клиент может фактически заказать больше товаров, чем у него есть баллы».

Многие люди борются с такими требованиями к строгой согласованности. Дело в том, что с подобными сценариями обычно можно справиться, вводя дополнительные правила, например, если пользователь получает отрицательные баллы лояльности, уведомляйте их. Если T проходит без сортировки баллов лояльности, сообщите пользователю, что с него будет взиматься плата M на основе некоторого коэффициента конверсии. Эта политика должна быть видна клиентам, когда они используют баллы для покупок.

Обычно я не занимаюсь микросервисами, и, возможно, это не лучший способ делать что-то, но вот идея:

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

Одним из возможных решений может быть реализация некоторого типа двухфазной фиксации:

1. Во-первых, интерфейс помещает запись в свою базу данных со всеми данными. Назовите это записью внешнего интерфейса.
2. Интерфейс запрашивает у серверной части управления заказами идентификатор транзакции и передает ему все данные, которые потребуются для выполнения действия. Бэкэнд управления заказами хранит эти данные в промежуточной области, привязывая к ним новый идентификатор транзакции и возвращая его во внешний интерфейс.
3. Идентификатор транзакции управления заказами хранится как часть записи внешнего интерфейса.
4. Интерфейс запрашивает у серверной части программы лояльности идентификатор транзакции и передает ему все данные, которые потребуются для выполнения действия. Бэкэнд программы лояльности хранит эти данные в промежуточной области, связывая с ним новый идентификатор транзакции и возвращая его во внешний интерфейс.
5. Идентификатор транзакции программы лояльности хранится как часть записи внешнего интерфейса.
6. Интерфейс сообщает серверу управления заказами завершить транзакцию, связанную с идентификатором транзакции, который хранится во внешнем интерфейсе.
7. Интерфейс сообщает серверу программы лояльности завершить транзакцию, связанную с идентификатором транзакции, который хранится во внешнем интерфейсе.
8. Интерфейс удаляет свою запись внешнего интерфейса.

Если это будет реализовано, изменения не обязательно будут атомарными, но они будут в конечном итоге согласованными. Давайте подумаем, где это могло произойти:

• Если это не удается на первом этапе, данные не изменятся.
• Если это не удается во втором, третьем, четвертом или пятом, когда система возвращается в оперативный режим, она может сканировать все записи внешнего интерфейса, ища записи без связанного идентификатора транзакции (любого типа). Если он встречает любую такую ​​запись, он может воспроизвести ее, начиная с шага 2. (Если на шаге 3 или 5 произошел сбой, в бэкэндах останутся некоторые заброшенные записи, но они никогда не будут перемещены из промежуточной области, поэтому все хорошо.)
• В случае сбоя на шестом, седьмом или восьмом шаге, когда система возвращается в режим онлайн, она может искать все записи внешнего интерфейса с заполненными идентификаторами обоих транзакций. Затем он может запросить серверные части, чтобы увидеть состояние этих транзакций - совершенные или незафиксированные. . В зависимости от того, какие из них были совершены, он может возобновиться с соответствующего шага.

Я согласен с тем, что сказал @Udi Dahan. Просто хочу добавить к его ответу.

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

1) Устранить отказ API программы лояльности. Другими словами, он может сохранять запросы, чтобы они не терялись и могли быть восстановлены (повторно выполнены) в какой-то более поздний момент.

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

3) Делайте то, что сказал Уди, и ставьте это в хорошую очередь (точнее, шаблон pub / sub). Обычно для этого требуется, чтобы подписчик выполнял одно из двух действий ... либо сохранял запрос перед удалением из очереди (goto 1) - ИЛИ - сначала заимствовал запрос из очереди, а затем, после успешной обработки запроса, получил запрос удален из очереди (это мое предпочтение).

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

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

Даже для распределенных транзакций вы можете попасть в «статус транзакции под сомнением», если один из участников выйдет из строя во время транзакции. Если вы спроектируете службы как идемпотентную операцию, жизнь станет немного проще. Можно писать программы для выполнения бизнес-условий без XA. Пэт Хелланд написал отличную статью по этому поводу под названием «Life Beyond XA». В основном подход состоит в том, чтобы делать как можно меньше предположений об удаленных объектах. Он также проиллюстрировал подход под названием «Открытые вложенные транзакции» (http://www.cidrdb.org/cidr2013/Papers/CIDR13_Paper142.pdf) для моделирования бизнес-процессов. В этом конкретном случае транзакция покупки будет потоком верхнего уровня, а управление лояльностью и заказами - потоками следующего уровня. Уловка состоит в том, чтобы разделить гранулированные сервисы как идемпотентные сервисы с логикой компенсации. Поэтому, если что-то выходит из строя где-либо в потоке, отдельные службы могут это компенсировать. Так, например, если заказ по какой-либо причине не выполняется, лояльность может вычесть баллы, начисленные за эту покупку.

Другой подход заключается в моделировании с использованием конечной согласованности с использованием CALM или CRDT. Я написал блог, чтобы осветить использование CALM в реальной жизни - http://shripad-agashe.github.io/2015/08/Art-Of-Disorderly-Programming Может быть, это вам поможет.