Комментарии 10
В упомянутом списке фреймворков почему-то не упомянут Enduro/X (или незаслуженно забыт).
не пишите свой оркестратор или workflow менеджер.
Да как же без этого жить :))) Два месяца когда то убил на написание своего workflow engine когда перед этим после моего робкого предложения использовать для этого MassTransit (которого, к слову сказать, я сам далеко не фанат) меня в навозе вываляли. Упаси боже - это ведь целую чужую *.dll надо в проект включать в качестве зависимости.
Если серьёзно, насчет статьи, то я бы еще прошелся по шаблону "Compensating Transaction".
На самом деле без нее сага не имеет смысла, если нельзя все вернуть взад - то какая это транзакция :) https://microservices.io/patterns/data/saga.html
На самом деле вовсе не обязательно "возвращать всё взад". В случае ES (Event Sourcing) можно, например, ко всем событиям аггрегата добавлять уникальный ID транзакции к которой оно относится, а подтверждение транзакции записывать отдельным специальным событием.
Я бы сказал, что ES хотя и родственный шаблон, все же не тоже самое что и сага, так что взад все же придется возвращать, в особенности если вы работаете с внешним API, который о ващих ES/SAGA и т.д. знать не знает
У нас "внешний АПИ" вообще никак в транзакции не участвует. В том смысле, что он только отправляет в брокер одну команду, а тот или иной оркестратор уже гарантирует её транзактивное выполнение - т.е. одна команда от внешнего АПИ - одна транзакция. Есть конечно еще разные случаи workflow, когда процесс состоит из пошагового взаимодействия, но такие вещи уже лежат за границами каких-то технических решений и больше относятся к бизнесу. Как, например, типичная проблема двух покупателей и продавца - можно отложить товар для первого пока он сходит за деньгами, отказать второму, а первый потом возьми да вообще не приди, а можно продать его второму, а потом краснеть перед первым когда он с деньгами за ним вернется - чисто техническими решениями эту дилемму решить невозможно.
Для простой статьи совсем непонятный переход от микросервисов и двухфазного комита к CAP теореме, которая относится к распределённым системам. Вы случайно не путаете микросервисную архитектуру и распределённые системы (https://microservices.io/articles/scalecube.html) ?
Спасибо что подсветили, в статье действительно переход резкий.
Применение микросервисной архитектуры порождает распределённые системы.
На самом деле монолит на бэке + БД, доступная по сети - это уже штука с признаками распределённой системы. Просто на таком масштабе удобней их игнорировать.
Когда у вас хотя бы 2 микросервиса - пользователи и заказы, то тут и встают вопросы - а будут ли данные консистентны между ними (C - consistency)? Как оба сервиса отреагируют на недоступность другого и как себя поведут, когда доступность снова восстановится (P - partition tolerance)? Насколько доступной будет вся система в целом, а не каждый микросервис в отдельности (A - availability)?
CAP-теорема начинает нам быть интересной в микросервисной архитектуре в самом практическом смысле.
Не надо SAGA заглавными, это просто слово "сага ". Она же Long-running Action (LRA).
Распределенные транзакции для самых маленьких