Когда микросервисы начинают «рассказывать истории»: как шаблон Saga обеспечивает бесперебойную работу

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

Это кажется знакомым?

В мире распределенных систем такое затруднение слишком распространено. Бизнес охватывает несколько сервисов, и каждый сервис работает в своем маленьком мире. Как обеспечить единообразное выполнение одного дела? Сегодня мы поговорим о методе, позволяющем микросервисам научиться «совместно рассказывать истории» — режиме «Сага». Особенно в среде .NET Core он становится секретным оружием, которое незаметно используют многие команды.

Итак, что же такое Сага?

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

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

Что бы было без этого? Несогласованные данные, частичные обновления, пользователи, получающие странные результаты... эти технические долги в конечном итоге обернутся звонками в службу поддержки и потерей репутации.

Почему .NET Core + Saga?

Выбор инструмента подобен выбору партнера, он зависит от молчаливого понимания. Легкая, кроссплатформенная и модульная конструкция .NET Core делает его естественным для разделения на микросервисы. Каждый сервис можно разрабатывать, развертывать и масштабировать независимо, а за координацию диалога между ними отвечает паттерн Saga.

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

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

Как хорошо рассказать эту «историю»?

Есть два основных метода: оркестровка и хореография.

Оркестрация подобна командному центру, центральному координатору, говорящему каждой службе, что и когда делать. Преимущество состоит в том, что логика централизована, ее легко отслеживать и отлаживать; Недостатком является то, что существует единственная точка риска - как только проводник выйдет из строя, все представление может быть приостановлено.

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

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

Пусть Saga действительно работает на вас

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

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

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

Итак, вы слушаете эту историю?

Микросервисы — это не цель, а средство. Цель разделения — лучше сотрудничать, а не создавать хаос. Модель Saga на самом деле заключается в том, чтобы предоставить этим независимым службам набор сценариев сотрудничества, чтобы они знали, когда начинать, когда уходить и как компенсировать это, если они забудут слова.

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

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

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