Кросс-сервисные транзакции или атомарность

Question

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

1. Мы должны отменить действие A, если B не удается (по «причинам» нам нужна полная история, или действие вообще не может произойти). Другими словами, мы не можем написать контрольный журнал, если мы определенно и успешно не вызвали службу, чтобы выполнить действие (т.е. мы не можем изменить порядок, чтобы сначала вызвать контрольный журнал, а затем вызвать службу).
2. Есть недопустимые упорядочения истории в B, которых у нас не может быть (Это аспект состояния A)

У меня было несколько мыслей, ни одна из которых не была идеальной:

• Получите статус A перед выполнением действия (который является доступным методом), и если вызов B завершится неудачно, мы можем просто снова вызвать первый сервис с исходным состоянием. Проблема, которая заключается в подходе, заключается в том, что «обратный» вызов A также может быть неудачным.
• На высоком уровне это, кажется, можно решить с помощью «транзакций» на уровне обслуживания (где оба вызова службы оба успешны или оба терпят неудачу). Кажется, что основным алгоритмом является 2-фазная фиксация , но мы не можем использовать его, потому что нам не принадлежат сервисы, которые мы вызываем, поэтому нет гарантии стабильного хранения, и мы не можем добавить функциональность, чтобы он "соглашался" с "координатором транзакций"
• Реализуем нашу собственную лучшую имитацию транзакций на нашей стороне. Мне кажется, это довольно сложный подход, который трудно или невозможно понять правильно
• Иметь возможность войти в «в конечном итоге непротиворечивое состояние». Однако, согласно пункту 2, некоторые упорядочения невозможны, поэтому нам придется подождать всех действий в очереди, чтобы выполнить его, прежде чем продолжить. Это сделало бы наш сервис потенциально не anyore

Есть ли какое-нибудь решение, в котором мы можем получить полное зеркало бревен, удовлетворяющее требованиям со 100% -ной точностью?

Answer 1

Вы не упомянули протокол, по которому взаимодействуют все ваши сервисы, ради этого ответа я предполагаю HTTP.

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

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

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

3. Согласен

4. Из всех вариантов у этого есть ноги. Все зависит от ваших требований к «в реальном времени». Всякий раз, когда кто-то говорит это, я спрашиваю: что ты имеешь в виду? ничто не является «реальным временем», все занимает некоторое время для обработки. У кого-то всегда есть промежуток времени или что-то просящее, чтобы что-то было сделано, чтобы это действительно было сделано! разница между миллисекундами и секундами - это вопрос или требования, и сколько денег вы должны бросить.

Итак, вы говорите, что вызов вашей службы (давайте назовем его X) по HTTP вызывает две службы A и B снова синхронно и через HTTP. Если у вас много вызовов к X одновременно, нет способа (или, по крайней мере, его очень сложно) обеспечить порядок вызовов к A, что приведет к тому же порядку вызовов к B. Но это опять-таки зависит от ваших требований и того, что система работает и как, может быть, в вашу систему поступает только один звонок в день?

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

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