Распределённые транзакции в Yii2

[amstr1k]

Необходимо реализовать микросервисную архитектуру. Для начала будет 3 сервиса:

1. ID (отвечающий на аутентицикацию/регистрацию)
2. Документы
3. Контрагенты

Документы и контрагентов могут добавлять только авторизованные пользователи.

Предусмотрен функционал объединения контрагентов, для этого в документах где фигурируют контрагенты необходимо подменить ID контрагента на выбранного, остальных перевести в дубликаты. Соответственно данный функционал будет в 2ух микросервисах. Причём нужно убедиться что замена ID контрагентов в документах прошла успешно, и только после этого проставлять флаг дубликатам.

Подскажите как реализовать данный функционал? Как сохранить целостность данных? и как проверять права у пользователей?

[amstr1k]

ни у кого никаких мыслей?

[zelenin]

ни у кого никаких мыслей?

думаю, тут пара человек кто слышал о микросервисах, и пара человек кто их делал.
да и судя по всему к yii вопрос не относится.

[samdark]

Транзакций из коробки у вас не будет, раз уже раздробили систему. Если у вас с хранилищами больше ничего не работает, можно попробовать организовать транзакции через блокировку. Что-то вроде mutex. В Yii, кстати, есть: http://www.yiiframework.com/doc-2.0/yii ... mutex.html

[samdark]

Если хранилище одно на все сервисы, то можно сделать отдельный сервис, делающий всё это средствами СУБД.

[zelenin]

Транзакций из коробки у вас не будет, раз уже раздробили систему. Если у вас с хранилищами больше ничего не работает, можно попробовать организовать транзакции через блокировку. Что-то вроде mutex. В Yii, кстати, есть: http://www.yiiframework.com/doc-2.0/yii ... mutex.html

я так понимаю, он хочет атомарно выполнить два запроса к двум микросервисам (через апи) и быть уверенным что успешно завершились оба.

[samdark]

Ну да.

1. Каждый из микросервисов должен в том или ином виде поддерживать откат изменений.
2. Лочим изменяемое.
3. Меняем в одном месте, если ок, меняем во втором. Если что-то не так, откатываем.
4. Разлочиваем.

[samdark]

Это, конечно, если не завязываться на особенности хранилища и подразумевать, что у каждого сервиса оно своё.

[amstr1k]

у каждого сервиса своё хранилище

[zelenin]

вообще очевидно, что если вам нужны транзакции на уровне нескольких микросервисов, то у вас неправильная архитектура. Микросервисы - независимые единицы сами по себе.
Тем не менее у фаулера или где-то читал про 2 phase commits, но на вскидку не могу придумать реализацию - возможно для этого надо создать надсервис, который в свою очередь будет работать с теми двумя.

[zelenin]

в целом вопрос интересный, так что держите в курсе ваших решений.

[zelenin]

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

1. отправляем два запроса в два сервиса: new TransactionalCommand($uuid, new UnionContragentCommand(....)) и new TransactionalCommand($uuid, new ChangeDocumentUserCommand(....)), где $uuid - uuid транзакции. На стороне сервисов записываем команды в uncommitted_commands (таблица хранилища). В ответ отдаем true.
2. Получив обратно два true коммитим обе команды, послав два new CommitCommand($uuid) - на стороне сервисов соответственно выполняем конечные команды и удаляем команды из uncommitted_commands. Шлем подтверждения успешности коммита.
3. Если неуспешно, шлем new RollbackCommand($uuid).

[amstr1k]

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

1. отправляем два запроса в два сервиса: new TransactionalCommand($uuid, new UnionContragentCommand(....)) и new TransactionalCommand($uuid, new ChangeDocumentUserCommand(....)), где $uuid - uuid транзакции. На стороне сервисов записываем команды в uncommitted_commands (таблица хранилища). В ответ отдаем true.
2. Получив обратно два true коммитим обе команды, послав два new CommitCommand($uuid) - на стороне сервисов соответственно выполняем конечные команды и удаляем команды из uncommitted_commands. Шлем подтверждения успешности коммита.
3. Если неуспешно, шлем new RollbackCommand($uuid).

пока что решили не париться по поводу целостности данных, чуть позже реализуем скорее всего, то что вы предлож

вообще очевидно, что если вам нужны транзакции на уровне нескольких микросервисов, то у вас неправильная архитектура. Микросервисы - независимые единицы сами по себе.
Тем не менее у фаулера или где-то читал про 2 phase commits, но на вскидку не могу придумать реализацию - возможно для этого надо создать надсервис, который в свою очередь будет работать с теми двумя.

тут могу не согласиться, в .net есть сервис распределённых транзакций как раз для этого

[zelenin]

я не знаю как у вас все это дело реализовано, но самое удобное общаться с микросервисами командами

Sam Dark, как раз сейчас смотрю конференцию из Воронежа - вижу ваш вопрос по теме REST+Commands.
На самом деле CQRS там не к месту был упомянут, так как речь там идет не о CQRS, а только о паттерне Command как способе общения с апи. Но данный паттерн на самом деле действительно очень удобен для императивного взаимодействия, но если подумать команды - это ничто иное как rpc api ('method': 'CreateTrain', params: {...}). Вывод: rest api красивый, но подходит для базовых крад-операций, а для более сложных rpc.

[ElisDN]

Sam Dark, как раз сейчас смотрю конференцию из Воронежа - вижу ваш вопрос по теме REST+Commands.
На самом деле CQRS там не к месту был упомянут, так как речь там идет не о CQRS, а только о паттерне Command как способе общения с апи. Но данный паттерн на самом деле действительно очень удобен для императивного взаимодействия, но если подумать команды - это ничто иное как rpc api ('method': 'CreateTrain', params: {...}). Вывод: rest api красивый, но подходит для базовых крад-операций, а для более сложных rpc.

Смотрел в трансляции и тоже заметил подозрительное отношение к командам. При переходе от CRUD с Transaction Script к осмысленному доменному Task Based UI простой и славный REST с GET/POST/PUT/DELETE уже неприменим, а команды удобны.

[zelenin]

Sam Dark, как раз сейчас смотрю конференцию из Воронежа - вижу ваш вопрос по теме REST+Commands.
На самом деле CQRS там не к месту был упомянут, так как речь там идет не о CQRS, а только о паттерне Command как способе общения с апи. Но данный паттерн на самом деле действительно очень удобен для императивного взаимодействия, но если подумать команды - это ничто иное как rpc api ('method': 'CreateTrain', params: {...}). Вывод: rest api красивый, но подходит для базовых крад-операций, а для более сложных rpc.

Смотрел в трансляции и тоже заметил подозрительное отношение к командам. При переходе от CRUD с Transaction Script к осмысленному доменному Task Based UI простой и славный REST с GET/POST/PUT/DELETE уже неприменим, а команды удобны.

да, так и есть. Поэтому в частности попытка написать rest api на встроенном в yii компоненте не приведет ни к чему хорошему. Вообще вопрос апи достаточно деликатный и тут не подходят какие-то коробочные решения - только самые общие парадигмы.

[samdark]

zelenin, ElisDN,

В ответе на конференции, походу, действительно была ошибка, но я лично его понял Сказано было CQRS, имелся ввиду Event Sourcing (их часто путают). То есть:

Каждая операция трактуется как event. Ему выделяется ресурс. Это может быть либо /event, либо что-то более конкретное. Например, /export.

Когда надо сделать операцию, делается PUT с данными, которые описывают, что надо сделать.

Если у нас обработка синхронная, в ответ нам прилетает объект "event" с результатом.

Если у нас обработка фоновая, в ответ прилетает ID. По ID мы GET-ом можем получить результат. Если ещё не готов, получаем соответствующий статус.

[zelenin]

zelenin, ElisDN,

В ответе на конференции, походу, действительно была ошибка, но я лично его понял Сказано было CQRS, имелся ввиду Event Sourcing (их часто путают). То есть:

Каждая операция трактуется как event. Ему выделяется ресурс. Это может быть либо /event, либо что-то более конкретное. Например, /export.

Когда надо сделать операцию, делается PUT с данными, которые описывают, что надо сделать.

Если у нас обработка синхронная, в ответ нам прилетает объект "event" с результатом.

Если у нас обработка фоновая, в ответ прилетает ID. По ID мы GET-ом можем получить результат. Если ещё не готов, получаем соответствующий статус.

ну вы сами как раз перепутали (либо вы про вопрос, который я не заметил).
вот вопрос https://youtu.be/woallvdqOLk?t=16569
тут про паттерн Команда, который используется в CQRS, но не является эксклюзивным для него. Event Sourcing это немного другая опера.

[ElisDN]

В ответе на конференции, походу, действительно была ошибка, но я лично его понял Сказано было CQRS, имелся ввиду Event Sourcing (их часто путают).

Без разницы, ES там или самопальная асинхронная очередь под капотом. Это вторично. Там как раз про наличие самого CQS в интерфейсе.

[samdark]

Ну да. Команда выделяется в отдельный endpoint, который строится по принципу Event Sourcing. Query остаётся в том же endpoint-е.