Комментарии 11
Мне кажется, что если оставить первую половину статьи, вам бы наплюсовали больше...
Это не ваш ли случай: stackoverflow.com/q/43612866?
Тонко
Обзор в первой части понравился. Про вариант 5 (eventual consistency) из первой части статьи: А под капотом у БД происходит не примерно то же самое? С помощью очереди фактически эмулируется журнал на уровне приложения, как мне видится. У БД все это может происходить только на одном сервере, а здесь можно распределить. Получилась система, в конечном счете обладающая транзакционностью, пусть и с фактическим READ_UNCOMMITED.
Про вторую часть: а разве идея с перекидываем подключения что-то даст по стравнению с моноллитным приложением? узкое место фактически остается — это одна БД, пусть и с премудростями по перекидыванию транзакций.
Про вторую часть: а разве идея с перекидываем подключения что-то даст по стравнению с моноллитным приложением? узкое место фактически остается — это одна БД, пусть и с премудростями по перекидыванию транзакций.
>>А под капотом у БД происходит не примерно то же самое?
ну БД под капотом устроена все же несколько иначе. Я не уверен насколько тут уместно проводит параллели, разве что на очень-очень высоком уровне. БД все же скорее императивна.
>>а разве идея с перекидываем подключения что-то даст по стравнению с моноллитным приложением?
На самом деле преимущества есть и достаточно ощутимые. Это
1. разделение цикла разработки, релизов и т.д.
2. разделение кода на меньшие и значит более понятные куски
3. разделение абстракций моделирования см bounded models — не надо натягивать абстракцию на весь домен — можно ограничиться его частью.
Список не полон. Добавлю только, что разделение данных на разные БД это далеко не самое главное преимущество микросервисов.
ну БД под капотом устроена все же несколько иначе. Я не уверен насколько тут уместно проводит параллели, разве что на очень-очень высоком уровне. БД все же скорее императивна.
>>а разве идея с перекидываем подключения что-то даст по стравнению с моноллитным приложением?
На самом деле преимущества есть и достаточно ощутимые. Это
1. разделение цикла разработки, релизов и т.д.
2. разделение кода на меньшие и значит более понятные куски
3. разделение абстракций моделирования см bounded models — не надо натягивать абстракцию на весь домен — можно ограничиться его частью.
Список не полон. Добавлю только, что разделение данных на разные БД это далеко не самое главное преимущество микросервисов.
5-й вариант, увы, вообще не решение. Помогает, только если сервис упал. А очередь мы считаем не падающей. А вот если сервис не модет выполнить действие инадо отменять, по возвращаемся к предыдущим пунктам.
Подождите, это что же получается: монолитное приложение разделили на 100500 микросервисов, а они, собаки, оказались вовсе даже не микросервисами? Ну, потому что какие же это микросервисы (которые по определению должны быть атомарны и независимы друг от друга), если возникают такого рода проблемы (которые, по факту, вытекают из того незамысловатого факта, что выделенные кусочки вовсе даже не независимы)?
По идее микросервис должен быть «сильным и независимым» (ну, почти). А если нужно обеспечить макро-транзакцию то это нужно делать с помощью отдельного сервиса обеспечения таких транзакций, внутри которого и должно быть сосредоточено всё знание о том, кто и как участвует в этой макро-транзакции, что делать при тех или иных видах отказов тех или иных участников и т.д. и т.п.
По идее микросервис должен быть «сильным и независимым» (ну, почти). А если нужно обеспечить макро-транзакцию то это нужно делать с помощью отдельного сервиса обеспечения таких транзакций, внутри которого и должно быть сосредоточено всё знание о том, кто и как участвует в этой макро-транзакции, что делать при тех или иных видах отказов тех или иных участников и т.д. и т.п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектурный шаблон “Macro Shared Transactions for Microservices”