Как стать автором
Обновить

Архитектурный шаблон “Macro Shared Transactions for Microservices”

Время на прочтение 11 мин
Количество просмотров 6.5K
Всего голосов 17: ↑15 и ↓2 +13
Комментарии 11

Комментарии 11

Мне кажется, что если оставить первую половину статьи, вам бы наплюсовали больше...

Можно, но в чем смысл такой статьи? Хочется что-то интересное придумать и поделиться. Из возраста собирания плюсов я пожалуй уже вырос.
Ну один из случаев. Проблема то не на пустом месте.
Обзор в первой части понравился. Про вариант 5 (eventual consistency) из первой части статьи: А под капотом у БД происходит не примерно то же самое? С помощью очереди фактически эмулируется журнал на уровне приложения, как мне видится. У БД все это может происходить только на одном сервере, а здесь можно распределить. Получилась система, в конечном счете обладающая транзакционностью, пусть и с фактическим READ_UNCOMMITED.
Про вторую часть: а разве идея с перекидываем подключения что-то даст по стравнению с моноллитным приложением? узкое место фактически остается — это одна БД, пусть и с премудростями по перекидыванию транзакций.
>>А под капотом у БД происходит не примерно то же самое?
ну БД под капотом устроена все же несколько иначе. Я не уверен насколько тут уместно проводит параллели, разве что на очень-очень высоком уровне. БД все же скорее императивна.
>>а разве идея с перекидываем подключения что-то даст по стравнению с моноллитным приложением?
На самом деле преимущества есть и достаточно ощутимые. Это
1. разделение цикла разработки, релизов и т.д.
2. разделение кода на меньшие и значит более понятные куски
3. разделение абстракций моделирования см bounded models — не надо натягивать абстракцию на весь домен — можно ограничиться его частью.

Список не полон. Добавлю только, что разделение данных на разные БД это далеко не самое главное преимущество микросервисов.
5-й вариант, увы, вообще не решение. Помогает, только если сервис упал. А очередь мы считаем не падающей. А вот если сервис не модет выполнить действие инадо отменять, по возвращаемся к предыдущим пунктам.
Очередь как ни странно очень легко сделать не падающей. Кластер или вообще PubSub например.
Подождите, это что же получается: монолитное приложение разделили на 100500 микросервисов, а они, собаки, оказались вовсе даже не микросервисами? Ну, потому что какие же это микросервисы (которые по определению должны быть атомарны и независимы друг от друга), если возникают такого рода проблемы (которые, по факту, вытекают из того незамысловатого факта, что выделенные кусочки вовсе даже не независимы)?
По идее микросервис должен быть «сильным и независимым» (ну, почти). А если нужно обеспечить макро-транзакцию то это нужно делать с помощью отдельного сервиса обеспечения таких транзакций, внутри которого и должно быть сосредоточено всё знание о том, кто и как участвует в этой макро-транзакции, что делать при тех или иных видах отказов тех или иных участников и т.д. и т.п.
Я постарался описать эту проблему. В реальных архитектурах такая проблема есть. Есть ее решения. Но про это мало рассказывают евангелисты микросервисов. «В кишках» там бывает много разных, часть не очень красивых моментов.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий