Слияние кода завершено, страница обновится автоматически
Дизайн Saga Pack
Введение в Background
Следующая иллюстрация показывает типичный вызов распределённой транзакции, в которой пользователь запрашивает вызов распределённой службы, и начальная служба последовательно вызывает две участвующие службы (Служба A, Служба B). Когда Служба A успешно выполняется, а Служба B сталкивается с проблемой, наша распределённая транзакция должна вызвать компенсационную операцию Службы A для обеспечения согласованности распределённой транзакции (одна транзакция завершается неудачно, и вся распределённая транзакция должна быть отменена), поскольку между двумя участвующими службами нет связи. Поэтому требуется координатор для помощи в соответствующем восстановлении.
В процессе выполнения компенсации для распределённых транзакций мы можем разделить их на два разных набора методов компенсации в зависимости от выполнения компенсации:
Обзор
Пакет содержит два компонента: альфа и омега. Альфа является лидером пакета и поддерживается базой данных, чтобы гарантировать постоянное хранение событий транзакций, в то время как омега является рабочим пакетом и внедрена в службы для перехвата вызова транзакции и сообщения о событиях альфе.
Внутренняя часть омеги Омега играет роль встроенного агента внутри служб. Когда поступает запрос на обслуживание, омега перехватывает его заголовок и извлекает глобальный идентификатор транзакции в качестве своего глобального идентификатора транзакции (идентификатор события Saga) и извлекает локальный идентификатор транзакции в качестве идентификатора родительской транзакции. На этапе предварительной обработки событие начала транзакции будет записано в альфа. На этапе последующей обработки событие завершения транзакции будет записано в альфу, чтобы отметить конец подтранзакции.
Межсервисное взаимодействие Процесс межсервисного взаимодействия аналогичен процессу Zipkin. На стороне производителя омега перехватывает идентификаторы транзакций из запроса для извлечения контекста транзакции. На стороне потребителя омега внедряет глобальные идентификаторы транзакций в запрос для передачи контекста транзакции. Подтранзакции могут объединяться в одну глобальную транзакцию путём сотрудничества производителей и потребителей.
Системная архитектура Мы можем узнать больше об отношениях между модулями Альфа и Омега на диаграмме системной архитектуры Пакета.
Вся архитектура разделена на три части: один — координатор Альфа (который поддерживает несколько экземпляров для обеспечения высокой доступности поддержки), другой — Омега, внедрённая в экземпляр микрослужбы, и протокол взаимодействия между Альфой и Омегой, который в настоящее время поддерживает реализацию двух протоколов координации распределённых транзакций SagaSaga и TCC.
Омега содержит модули, связанные с анализом логики распределённых транзакций пользователя:
Контекст транзакции: контекст транзакции предоставляет Omega способ передать информацию о вызове транзакции. С помощью упомянутого ранее глобального идентификатора транзакции и соответствия локальных идентификаторов транзакций Alpha может легко получить всю информацию о событиях локальной транзакции, связанную с распределённой транзакцией.
Исполнитель транзакции: исполнитель транзакции — это модуль, предназначенный в первую очередь для обработки тайм-аутов вызова транзакций. Поскольку соединение между Alpha и Omega может быть ненадёжным, стороне Alpha трудно определить, вызван ли тайм-аут выполнения локальной транзакции Omega собственным вызовом Alpha или Omega. Поэтому исполнитель транзакций предназначен для мониторинга локальной производительности Omega, что упрощает обработку тайм-аута Omega. В реализации по умолчанию Omega напрямую вызывает метод транзакции, а фоновый сервис Alpha определяет, превышено ли время выполнения транзакции, сканируя таблицу событий.
Обратный вызов транзакции: когда Omega устанавливает соединение с Alpha, она регистрируется в Alpha. Когда Alpha необходимо скоординировать действия, она напрямую вызывает зарегистрированный обратный вызов метода Omega для связи. Поскольку экземпляры микросервисов часто запускаются и останавливаются в облачных сценариях, мы не можем предполагать, что Alpha всегда сможет найти обратные вызовы транзакций при первоначальной регистрации. Поэтому мы рекомендуем, чтобы экземпляры микросервиса были без сохранения состояния, чтобы Alpha могла взаимодействовать с соответствующей Omega только на основе имени службы.
Модуль транспорта транзакций отвечает за связь между Omega и Alpha. В процессе конкретной реализации Pack определяет методы взаимодействия транзакций TCC и Saga, определяя соответствующий интерфейс описания Grpc, а также события, связанные с взаимодействием. Мы включили взаимные вызовы между Omega и Alpha с помощью двустороннего потока интерфейса, предоставляемого Grpc. Передачи Omega и Alpha основаны на многоязычной поддержке Grpc и обеспечивают основу для многоязычной версии Omega.
Чтобы реализовать свою функцию координации транзакций, Alpha сначала должна получать события, загруженные Omega через транспорт транзакций. В модуле Event Store Alpha использует API событий для предоставления услуг запроса событий внешнему миру. Alpha сканирует информацию о событиях выполнения для распределённых транзакций через Event Scanner, идентифицирует транзакцию с тайм-аутом и отправляет инструкции Omega для завершения координации транзакции. Поскольку координация Alpha обеспечивает высокодоступную архитектуру в подходе с несколькими экземплярами, это требует, чтобы менеджер кластера Alpha управлял координацией перед экземплярами кластера Alpha. Пользователи могут отслеживать выполнение распределённых транзакций с помощью управляющих терминалов.
Event Store: хранилище событий Alpha в настоящее время построено поверх базы данных. Чтобы уменьшить сложность реализации системы, высокодоступная архитектура альфа-кластеров основана на кластерах баз данных. Для повышения эффективности запросов к базе данных мы разделяем хранилище данных на онлайн-библиотеку и архивную библиотеку на основе глобальной производительности транзакций события. Неоплаченные события распределённых транзакций хранятся в онлайн-библиотеке, а завершённые события распределённых транзакций — в архивной библиотеке.
API событий: который представлен как служба запросов событий Restful. Эта функция модуля впервые применяется в приемочном тесте пакета. Через код приемочного теста API событий можно легко понять события, полученные Alpha внутри. Приёмочные тесты проверяют правильность соответствующих функций координации транзакций путём моделирования различных исключений выполнения распределённых транзакций (ошибки или тайм-ауты) по сравнению с событиями транзакций, полученными Alpha. Консоль: терминал управления предоставляет статистический анализ производительности распределённой транзакции путём доступа к Rest-сервису, предоставляемому Event API, и может отслеживать выполнение отдельной глобальной транзакции, чтобы выяснить причину сбоя транзакции.
Alpha Cluster Manager: отвечает за регистрацию экземпляра Alpha, управление выполнением отдельных сервисов в Alpha и предоставление Omega актуального списка сервисов. Пользователь менеджера кластера может легко реализовать операции запуска-остановки экземпляра сервиса Alpha и возможность постепенного обновления экземпляра сервиса Alpha.
В рабочем процессе Saga субтранзакция должна предоставить метод компенсации. Если что-то пойдёт не так, координатор отправит команду омеге для выполнения прямого или обратного восстановления.
При успешном сценарии все начатые события будут иметь соответствующее завершённое событие.
В сценарии исключения омега внутри аномального сервиса сообщит об прерванном событии альфа. Затем альфа отправит команды компенсации завершённым событиям в рамках глобальной транзакции, чтобы убедиться, что все субтранзакции либо завершены, либо откачены назад.
В сценарии тайм-аута события с тайм-аутом будут обнаружены сканером периода альфа, соответствующая глобальная транзакция будет прервана одновременно.
По сравнению с Saga, TCC (попробуй-подтверди-отмени) имеет ещё один метод (попробуй), чтобы проверить, достаточно ли у нас ресурсов для завершения транзакции. Инициатор транзакции знает о состоянии всех распределённых субтранзакций, поэтому он может работать с альфа-версией, чтобы подтвердить или отменить транзакции.
При успешном сценарии все события попытки подтверждаются.
В случае исключения инициатор отправит событие отмены альфа, и альфа сможет вызвать методы отмены, которые зарегистрированы на сервере Alpha, для очистки предварительно выделенных ресурсов.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )