У меня есть программа в реальном времени, которая делает сетевые вызовы службы A для выполнения действия с отслеживанием состояния и сетевые вызовы службы B для регистрации истории этого действия. Подвох в том, что:
У меня было несколько мыслей, ни одна из которых не была идеальной:
Есть ли решение, в котором мы можем получить полное зеркало журналов, удовлетворяющее требованиям со 100% точностью?
Вы не упомянули протокол, по которому общаются все ваши службы, ради этого ответа я предполагаю HTTP.
Как вы сказали, ни одно из ваших возможных решений не звучит так, как будто они сработают для вас.
Для служб слишком легко изменить состояние до или после проверки состояния, и, как вы сказали, любое корректирующее действие после этого также может легко потерпеть неудачу.
Я думаю, что в сценарии, который вы описали, о двухфазной фиксации не может быть и речи. даже если вы владеете всеми сервисами, сложно сделать это правильно, используя только HTTP.
я согласен
Из всех вариантов у этого есть ноги. Все зависит от ваших требований к «реальному времени». Всякий раз, когда кто-то говорит это, я спрашиваю: «Что вы имеете в виду?» ничто не происходит в режиме реального времени, все требует времени для обработки. Всегда есть период времени, когда кто-то или что-то просит что-то сделать, чтобы это действительно было сделано! разница между миллисекундами, секундами и минутами - это просто вопрос требований и того, сколько денег вы должны разбрасывать.
Итак, вы говорите, что вызов вашей службы (давайте назовем ее X) через HTTP синхронно снова вызывает две службы A и B через HTTP. Если у вас есть много вызовов X одновременно, нет способа (или, по крайней мере, это очень сложно) гарантировать, что порядок вызовов A приводит к тому же порядку вызовов B. Но это снова зависит от ваших требований и того, что система поживает и как, может в вашу систему каждый день поступает только один звонок?
Лично я бы рекомендовал использовать очереди и перейти к архитектуре, управляемой событиями. Даже с стабильной системой вы можете заставить ее работать в горячем режиме и получать «реальное время», которое вы желаете, это будет стоить вам дороже!
Я надеюсь, что это было полезно для вас. Мне очень интересно услышать ваше мнение относительно моих предложений.
Существует так много технологий, которые помогут вам в этой области, что вы не будете разрабатывать новое решение для этого. Просто взгляните на все технологии, доступные сегодня у облачных провайдеров. Мы активно используем sqs в AWS, и если вы работаете в локальной среде, вы можете использовать множество вариантов kafka, zeroMQ или rabbitMQ. разработка системы, управляемой событиями, проще, чем вы думаете.
Я думаю, что минуты - это приемлемое время для ожидания, и трафик не должен быть слишком высоким. Хотя я думаю, что потребуются значительные усилия для разработки решения, обеспечивающего устойчивую локальную очередь.