шаблон саги в микросервисах

Решить проблемы в микросервисах? Попробуйте режим Саги

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

В микросервисной архитектуре подобные проблемы встречаются слишком часто. Каждый сервис управляет своим собственным участком земли, и данные не передаются. Как мы можем гарантировать, что серия операций либо увенчается успехом, либо потерпит неудачу? Традиционную пакетную транзакцию (транзакцию ACID) легко использовать в одном приложении, но в распределенной среде, где сервисы разбросаны по частям, ее немного недостаточно. В это время вам необходимо изменить свое мышление.

Что такое режим Саги? Это что-то вроде «директора-координатора».

Проще говоря, модель Saga заключается в том, чтобы разбить крупную бизнес-транзакцию на серию небольших, независимых локальных транзакций. Каждая служба выполняет только свой шаг, а затем запускает следующее действие службы. Если определенный шаг посередине окажется неудачным, Saga начнет серию «компенсационных операций», точно так же, как кадр в фильме испорчен, и соответствующие части, которые были сняты ранее, должны быть перенастроены или удалены по порядку, чтобы можно было вернуться в состояние системы до того, как произошел инцидент.

Он не использует большую блокировку для блокировки всех ресурсов, а управляется событиями и сообщениями, обеспечивая «совместную работу в чате» между службами. Например, если заказ успешно создан, в службу инвентаризации отправляется сообщение: «Списать одну позицию»; если запасы успешно вычтены, служба логистики уведомляется: «Оно готово к отправке». Если отгрузка не удалась, служба инвентаризации должна знать: «Добавьте обратно только что вычтенный товар», а службе заказов также может потребоваться изменить статус на «ожидание обработки».

Кто-то спросил: «Разве это не просто план Б?» Да, не совсем верно. Компенсация — это не просто откат, это обратная оркестровка бизнес-логики. Ключевым моментом является то, что при проектировании вы должны четко продумать, как «изящно выйти», если каждый шаг окажется неудачным.

Почему вам нужно об этом заботиться? Заходите в меньшее количество ловушек и больше спите

Представьте, что вас разбудило текстовое сообщение будильника в три часа ночи. Поскольку статус заказа зависает, все исходящие и последующие данные не совпадают... Кто когда-либо мог себе представить такой день? Основное преимущество принятия такой модели, как Saga, заключается в повышении конечной согласованности и устойчивости системы. Службы слабо связаны. Если одна служба временно зависает, это не повлияет на работу других служб. Когда он восстановится, механизм компенсации может помочь догнать данные.

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

Конечно, это тоже не панацея. Designing is more brain-intensive, as you have to carefully define each forward operation and corresponding compensation action. Компенсация сама по себе также может дать сбой, что потребует более сложных стратегий обработки ошибок и мониторинга. Но по сравнению с тушением пожара вручную после возникновения ошибки, заблаговременная разработка автоматизированного процесса исправления избавит вас от многих проблем в долгосрочной перспективе.

Как его использовать? Несколько прагматичных идей

1. Организуйте свой бизнес-поток: Не спешите писать код. Сначала возьмите лист бумаги и нарисуйте кросс-сервисный бизнес-процесс, например «Пользователь размещает заказ -> Вычесть запасы -> Вычесть оплату -> Создать накладную». Уточните входные и выходные данные каждого шага.
2. Дайте определение «компенсационному действию».: Для каждого шага спрашивайте себя: «Если этот шаг позже не удастся, как вы сможете отменить или компенсировать его влияние?» Компенсацией за вычет запасов является добавление запасов обратно; компенсация за вычет может привести к возврату средств. Убедитесь, что компенсационная операция также экономически целесообразна.
3. Выберите метод координации: Обычно есть два типа. Один из нихпоставленныйсоздать централизованного координатора, который будет руководить тем, кто и что должен делать, например, дирижера оркестра; второйСовместный, пусть каждый сервис уведомляет следующий после завершения своей работы, больше похоже на эстафету. Первый имеет сильный контроль, а второй более децентрализован и гибок. Выбирайте в зависимости от структуры вашей команды и предпочтений по сложности.
4. Внедрение и тестирование: используйте привычную очередь сообщений или платформу потоковой передачи событий для сообщения об изменениях состояния. Главным приоритетом является тестирование, особенно сценариев сбоя: моделирование сбоя службы на полпути, чтобы увидеть, можно ли правильно запустить компенсационную цепочку и являются ли данные в конечном итоге согласованными.
5. Мониторинг и оповещение: Добавьте четкие журналы и индикаторы на каждый этап и компенсационную операцию Saga. Если компенсация срабатывает часто, это может быть ранним сигналом о нестабильности определенной службы.

Пусть надежные технологии станут молчаливой поддержкой бизнеса

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

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

В следующий раз, когда вы будете разрабатывать функцию, включающую многоэтапные операции и межсервисные вызовы, подумайте об этом: если эта связь повреждена посередине, сможет ли она очиститься самостоятельно? Возможно, режим Saga — это тот чертеж, который вам нужен.

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.