Комментарии 10
Согласно схеме и в Customer Service и в Order Service есть DeliveryInfo и PaymentInfo. Хотелось бы узнать побольше про этот нюанс. Это разные инфо или одни и теже?
Посылать евенты по каждому чиху плохая идея. Со временем этот подход превращает жизнь в ад. Надо хорошо подумать прежде так делать. Если создание заказа требует проверки финансов, вызовите этот финансовый сервис сразу же. Поставьте таймаут в 300 мс и не партесь. Если сервис не ответил или запишите в базу и попробуйте позже или пошлите эвент. А лутше обеспечте высокую доступность этого финансового сервиса, если уж он так критичен. Как другой вариант можно запилить WorkflowService который будет все это делать в рамках одного бизнес процесса.
Посылать евенты по каждому чиху плохая идея. Со временем этот подход превращает жизнь в ад. Надо хорошо подумать прежде так делать. Если создание заказа требует проверки финансов, вызовите этот финансовый сервис сразу же. Поставьте таймаут в 300 мс и не партесь. Если сервис не ответил или запишите в базу и попробуйте позже или пошлите эвент. А лутше обеспечте высокую доступность этого финансового сервиса, если уж он так критичен. Как другой вариант можно запилить WorkflowService который будет все это делать в рамках одного бизнес процесса.
НЛО прилетело и опубликовало эту надпись здесь
Микросервисная архитектура оправдывает себя на более высоком уровне, пример:
— сервис авторизации OAuth2
— биллинг
— процессинг
— СХД
— шина
как правило над подобными системами трудятся > 10 разработчиков.
— сервис авторизации OAuth2
— биллинг
— процессинг
— СХД
— шина
как правило над подобными системами трудятся > 10 разработчиков.
В своем решении отказался от аггрегатов, вместо этого реализовал т.н. тактики (велосипед). Тактика — это набор бизнес действий формирующих план по которому будет выполнено изменение модели.
Тактики реагируют на внешние события, например, сервис интеграции с 1С говорит что сотрудник уволен, это вызывает исполнение определенной тактики, в которой отмечается что сотрудник уволен, и выполнение которой вызывает ряд следующих тактик, в которых пересчитываются отпуска, и все прочие связанные с сотрудником вещи. На выходе получаю список операций в виде — добавить в базу, обновить в базе, удалить из базы и т.п.
Затем список оптимизируется, из него выкидываются взаимоисключающие операции и операции не приводящие к изменению модели.
И в конце концов список исполняется в едином transaction scope, при этом каждая операция может относится к разным базам, в том числе nosql. В случае сбоя выполняется откат в каждой из них. Для тех баз которые не поддерживают транзакции был написан декоратор добавляющий их.
Такой подход позволяет не создавать новые сущности и разносить логику на любой масштаб (по тактикам). Правда он же подразумевает что есть сервис который имеет доступ ко всем базам, как и было в моем случае.
Тактики реагируют на внешние события, например, сервис интеграции с 1С говорит что сотрудник уволен, это вызывает исполнение определенной тактики, в которой отмечается что сотрудник уволен, и выполнение которой вызывает ряд следующих тактик, в которых пересчитываются отпуска, и все прочие связанные с сотрудником вещи. На выходе получаю список операций в виде — добавить в базу, обновить в базе, удалить из базы и т.п.
Затем список оптимизируется, из него выкидываются взаимоисключающие операции и операции не приводящие к изменению модели.
И в конце концов список исполняется в едином transaction scope, при этом каждая операция может относится к разным базам, в том числе nosql. В случае сбоя выполняется откат в каждой из них. Для тех баз которые не поддерживают транзакции был написан декоратор добавляющий их.
Такой подход позволяет не создавать новые сущности и разносить логику на любой масштаб (по тактикам). Правда он же подразумевает что есть сервис который имеет доступ ко всем базам, как и было в моем случае.
Агрегат представляет собой кластер объектов предметной области, которые можно рассматривать как единое целое
Одна транзакция создает или обновляет один агрегат
В общем, как уже говорилось в десятках других статей: самое сложное в микросервисной архитектуре — правильно разбить задачу на отдельные сервисы. Будут ли они при этом "агрегатами" или нет — дело десятое.
Интересная архитектура. Жаль экспериментировать с ней дорого.
Подскажите какой-нибудь open source проект, использующий такой подход, или статью с описанием такого подхода в живом проекте. Главное чтобы не фреймворк (такое-то не очень сложно сделать), а реальный конечный продукт.
Подскажите какой-нибудь open source проект, использующий такой подход, или статью с описанием такого подхода в живом проекте. Главное чтобы не фреймворк (такое-то не очень сложно сделать), а реальный конечный продукт.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS (Часть 1)