Блог

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

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

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

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

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

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

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

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

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

3. Я согласен

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

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

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

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