Глубокое понимание компонента распределенных транзакций Seata (1)

Микросервисы распределенный

Проблема распределенных транзакций всегда была сложной проблемой в микросервисной архитектуре. Одно приложение может реализовывать локальные транзакции, но в распределенной среде ситуация усложняется. Запрос может включать несколько служб, и между восходящим и нисходящим потоками существуют зависимости.Если одна из ссылок выходит из строя, необходимо откатить всю транзакцию. В первой половине прошлого года автор открыл исходный код компонента распределенных транзакций микросервиса:lottorГибкая схема реализации распределенных транзакций на основе надежных сообщений. Представленный клиент Lottor более сложный и инвазивный для бизнеса. Эффект от поощрения использования не очень хороший. Али открыл SEATA (оригинальный FESCAR) в начале этого года, что вызвало бурный отклик. Недавно автор задумал улучшить Lottor, научиться практиковать сита и поделиться этим с вами.

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

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

Ненавязчивое решение для бизнеса

Среди существующих основных решений для распределенных транзакций только решения на основе XA ненавязчивы для бизнеса (Примечание: JTA, упомянутый в вопросе, является Java-версией решения XA), но при применении решения XA возникают три проблемы:

  1. База данных требуется для обеспечения поддержки XA. Если вы столкнулись с базой данных, которая не поддерживает XA (или поддерживает ее плохо, например версии MySQL до 5.7), ее нельзя использовать.

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

  3. Реализованные распределенные решения на основе XA полагаются на тяжеловесные серверы приложений (Tuxedo/WebLogic/WebSphere и т. д.), которые не подходят для микросервисной архитектуры.

Деловая программа проникновения

Фактически единственным решением для распределенных транзакций поначалу был XA. XA завершена, но на практике по разным причинам (включая, но не ограничиваясь 3 пунктами, упомянутыми выше) часто приходится сдаваться и обращаться к бизнес-уровню для решения проблемы распределенных транзакций. Например:

  • Схема возможной согласованности на основе надежных сообщений
  • TCC
  • Saga

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

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

Представляем Сеата

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

Он включает в себя TXC группы (облачная версия называется GTS) и TCC Ant Financial.В настоящее время количество звезд на Github превысило 10 000, что делает его единственным решением для распределенных транзакций, одобренным крупными производителями. TXC также называется режимом AT в Seata, что означает, что метод компенсации автоматически генерируется фреймворком, который полностью экранирован для пользователей. Пользователи могут использовать распределенные транзакции, как и с использованием локальных транзакций. Недостатком является то, что только реляционные базы данных (в настоящее время MySQL поддерживаются). Для службы Seata AT требуется локальная таблица для хранения rollback_info, а уровень изоляции RU по умолчанию применим к ограниченным сценариям.

TCC - это не новая концепция. Это было в течение длительного времени. Пользователь имитает двухступенчатую представление на уровне приложения, определив три метода: попробуйте / подтвердить / отменить. Разница в том, что метод TRY в TCC также должен Управляйте базу данных, чтобы заблокировать ресурсы. Следующие две методы компенсации он автоматически вызывается в рамках для выполнения подачи ресурсов и отката соответственно, что отличается от простого слоя 2 шт. Ant Financial предоставляет свою собственную реализацию TCC в SACA, который, как говорят, развивались более десяти лет и широко используются в финансах, торгах, складировании и других областях.

Эта статья в настоящее время посвящена режиму AT в Seata.

Состав Seata

С точки зрения дизайна, Seata делит все на три основных модуля, а именно TM, RM и TC, Конкретные объяснения заключаются в следующем:

  • TM (менеджер транзакций): диспетчер глобальных транзакций, который управляет границей глобальной транзакции и отвечает за открытие глобальной транзакции, глобальную фиксацию и глобальный откат.

  • RM (менеджер ресурсов): менеджер ресурсов, контролирует транзакции филиалов, отвечает за регистрацию филиалов, отчеты о состоянии и получает инструкции от координатора транзакций для управления фиксацией и откатом транзакций филиала (локальных).

  • TC (координатор транзакций): координатор транзакций, поддерживает рабочее состояние глобальных транзакций, отвечает за координацию и управление фиксацией или откатом глобальных транзакций.

Режим Seata AT разработан на основе режима двухэтапной фиксации и решает проблемы распределенных транзакций, возникающие в сценарии микросервиса, эффективным и неинтрузивным способом.

Введение в архитектуру и принципы реализации режима AT

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

  • Фаза 1: Выполнение транзакций филиала (локально). Локальная транзакция используется как ветка распределенной транзакции, поэтому несколько локальных транзакций, распределенных по разным микросервисам, вместе образуют глобальную транзакцию, структура ее следующая.

  • Фаза 2: транзакция ветки фиксируется или откатывается. Фаза 2 завершает окончательную фиксацию или откат глобальной транзакции. Когда все транзакции ветвей в глобальной транзакции завершены и выполнены успешно, TM инициирует фиксацию глобальной транзакции. После того, как TC получит сообщение о фиксации глобальной транзакции, он уведомит каждую Транзакция ответвления фиксируется; аналогичным образом, когда все транзакции ответвления в глобальной транзакции завершаются, а транзакция ответвления терпит неудачу, TM уведомляет TC о необходимости координировать откат глобальной транзакции, а затем TC уведомляет каждую транзакцию о переходе к откату. назад.

В процессе запуска бизнес-приложения, благодаря внедрению клиента Seata, RmRpcClient будет запущен вместе с приложением. RmRpcClient реализован в Netty и может получать сообщения TC и отправлять сообщения TC. Поэтому RmRpcClient ключевой модуль для отправки и получения сообщений с ТС.

Общий процесс реализации распределенных транзакций в Seata выглядит следующим образом:

  • TM уведомляет TC о начале новой глобальной транзакции. TC генерирует XID, представляющий глобальную транзакцию.
  • XID распространяется по цепочке вызовов микрослужбы.
  • RM регистрирует локальную транзакцию как ответвление соответствующей глобальной транзакции XID для TC.
  • TM уведомляет TC о необходимости фиксации или отката глобальной транзакции, соответствующей XID.
  • TC управляет всеми транзакциями ветвей в соответствии с соответствующей глобальной транзакцией XID для завершения фиксации или отката ветвления.

Начало работы с режимом Seata AT

Пример использованияseata-samplesПроект Seata-JPA в формате .

Задействованные услуги следующие:

Клиент инициирует бизнес-службы, а Business вызывает Storage для блокировки запасов и Order для создания заказов. Заказ вызывает Аккаунт для вычета баланса. Роли, соответствующие каждой службе, отмечены на рисунке выше.

Запустить службу ТС

Во-первых, мы запускаем SEATA-Server, а именно TC. Скачать пакет релиз Seata-Server. Запустите следующую команду, чтобы запустить сервер.

sh distribution/bin/seata-server.sh -p 8091 -h 127.0.0.1 -m file

Новая таблица базы данных

Таблицы базы данных, участвующие в выполнении нескольких сервисов:

У каждой службы есть соответствующая бизнес-таблица и таблица undo_log.

CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  `ext` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

Создайте новую таблицу undo_log в базе данных служб, участвующих в цепочке транзакций, для хранения информации UndoLog для двухэтапной операции отката.Таблица содержит информацию о ключевых полях, такую ​​как xid, branchId и rollback_info.

Добавить глобальные аннотации транзакций

    @GlobalTransactional
    public void purchase(String userId, String commodityCode, int orderCount) {
        storageFeignClient.deduct(commodityCode, orderCount);

        orderFeignClient.create(userId, commodityCode, orderCount);
    }

Положитесь на клиентский SDK Seata, а затем добавьте его в бизнес-метод всего инициатора распределенной транзакции.@GlobalTransactionalаннотация.

Настройка прокси-источника данных

Seata в основном переупаковывает четыре интерфейса DataSource, Connection, Statement и PreparedStatement в пакет java.sql. Классы упаковки: DataSourceProxy, ConnectionProxy, StatementProxy, PreparedStatementProxy, которые очень хорошо печатают один к одному. Его функция находится в пакете java.sql. Оператор SQL.Некоторые операции, связанные с распределенными транзакциями Seata, выполняются до и после выполнения, фиксации или отката транзакции, например регистрация ветки, отчет о состоянии, запрос глобальной блокировки, хранение моментальных снимков, обратное генерирование SQL и т. д.

@Configuration
public class DataSourceConfig {

    @Bean
    @ConfigurationProperties(prefix = "spring.datasource")
    public DruidDataSource druidDataSource() {
        return new DruidDataSource();
    }

    @Primary
    @Bean("dataSource")
    public DataSource dataSource(DruidDataSource druidDataSource) {
        return new DataSourceProxy(druidDataSource);
    }
}

DataSourceProxy должен быть установлен в качестве основного источника данных, иначе транзакцию нельзя будет откатить.

проверять

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

GET http://127.0.0.1:8084/purchase/commit
Accept: application/json

###
GET http://127.0.0.1:8084/purchase/rollback
Accept: application/json

Вы можете проверить результат самостоятельно.

резюме

В этой статье кратко вводит концепцию распределенной транзакции с открытым исходным кодом ALI SEATA, фокусируясь на режиме SEATA, MT, MT будет описан позже. Эта статья относительно проста, является входной практикой. SEATA - это отличная рамка для распределенной транзакции, я сочетую в более поздней статье описывает реализацию принципа источника SACA.

Рекомендуемое чтение

Коллекция микросервисов

Подписывайтесь на свежие статьи, приглашаю обратить внимание на мой публичный номер

微信公众号

Категории