Сообщение Re: Микросервисы - в чем дебилизм от 12.11.2018 21:04
Изменено 12.11.2018 21:05 Nikita Lyapin
Re: Микросервисы - в чем дебилизм
Здравствуйте, Shmj, Вы писали:
Проблема в том, что то что вы называете microservices это антипаттерн. На который наступают периодически. Антипаттерн называется Entity Service. Подробнее, например, здесь:
Проблема в том, что если вы делаете компонент как микросервис (order service, account service) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Обычно в случае с микросервисным подходом нужно стремится к eventiual consistency. Таким образом чтобы каждый из микросервисов был независимой подсистемой. В этом очень помогает понятие bounded context из DDD. Для начала попробуйте определить агрегаты в вашей системе, многое станет понятным.
Проблема в том, что то что вы называете microservices это антипаттерн. На который наступают периодически. Антипаттерн называется Entity Service. Подробнее, например, здесь:
Проблема в том, что если вы делаете компонент как микросервис (order service, account service) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Обычно в случае с микросервисным подходом нужно стремится к eventiual consistency. Таким образом чтобы каждый из микросервисов был независимой подсистемой. В этом очень помогает понятие bounded context из DDD. Для начала попробуйте определить агрегаты в вашей системе, многое станет понятным.
Re: Микросервисы - в чем дебилизм
Здравствуйте, Shmj, Вы писали:
Проблема в том, что то, что вы называете microservices — это антипаттерн. На который наступают периодически. Антипаттерн называется Entity Service. Подробнее, например, здесь:
Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Обычно в случае с микросервисным подходом нужно стремится к eventiual consistency. Таким образом чтобы каждый из микросервисов был независимой подсистемой. В этом очень помогает понятие bounded context из DDD. Для начала попробуйте определить агрегаты в вашей системе, многое станет понятным.
Проблема в том, что то, что вы называете microservices — это антипаттерн. На который наступают периодически. Антипаттерн называется Entity Service. Подробнее, например, здесь:
Если вы делаете компонент как микросервис (order service, account service и т.п.) у вас возникают проблемы с транзакционностью, у вас возникают проблемы с отказоустойчивостью. По факту система по прежнему монолит, только добавились дополнительные издержки.
Обычно в случае с микросервисным подходом нужно стремится к eventiual consistency. Таким образом чтобы каждый из микросервисов был независимой подсистемой. В этом очень помогает понятие bounded context из DDD. Для начала попробуйте определить агрегаты в вашей системе, многое станет понятным.