Комментарии 7
Бесконечный холивар. Проблема не в микросервисах, а в том что люди хотят серебряную пулю для всех решений. Микросервисы, монолит, модульный монолит эти архитектуры не на каждый случай. Каждый подход используется там, где его преимущества раскрываются. Если монолит - боль и страдания, то может не стоило его использовать?
Транзакционность сестра консистентности. А у консистентности есть границы. Когда у вас одна база вы можете можете сдвигать границы консистентности, например, обновляя несколько агрегатов в одной транзакции используя оптимистичную конкурентность. Но даже имея такую гибкость, не получится забыть об ограничениях - если при обновлении множества агрегатов (что может быть не быстро) кто-то между делом обновил один из них - происходит ошибка транзакции... Или не происходит, если данный юзкейс приемлет lost update.
Поэтому важно понимать какой у вас в принципе есть набор инструментов, компромиссов и понимание, как изменение одно виртуального ползунка влияет на другие. Это справка для любой инженерной профессии. Просто где-то возможно эти модели буквально пощупать руками, как например в строительстве (материалы, инструменты), а где-то они существуют только в виде ментальной модели и окошек в компьютере, как например в АйТи.
Мне кажется человечество ещё только учится жить в информационном мире, у которого нет физической оболочки. Лишь у малого количества людей интуиция и восприятие развиты настолько, чтобы чувствовать эту виртуальную материю.
Отсюда и ощущение, что архитекторы занимаются шаманством: много решений принимается без полного понимая, что и на что влияет. Вы думаете, что не можете понять суть решения архитектора, потому что недостаточно компетентны и опытны, но на самом деле даже сам архитектор не способен понять суть своего же решения, просто "по опыту так должно сработать" 🙂 Такое случается не только в АйТи, но в АйТи очень ярко выражено.
А такой вариант как одна бд и много микросервисов не вариант?) Щас как раз делаем под эту модель. Есть основной микросервис обновляющий схему бд и он еще для авторизации. Остальные просто разделены по модулям и все. Это удобно и каждый модуль обновляется и изменяется независимо. Через маршрутизацию выходит как единая точка апи. Еще можно подключить aspire) .net 8, postgresql. Бакенд очень удобный получился и легко изменяемый. Кому интересно могу статьей описать) просто не надо бегать за серебрянными пулями в голове)
Прочность цепи определяется прочностью ее самого слабого звена. В вашем случае это БД. Если у вас 90% запросов в API попадают в БД, то какого-то особого смысла кроме как использование разных ЯП разбиение на микросервисы не имеет. По факту это распределенный монолит. В конечном итоге реальную работу выполняет БД, а API служит как адаптер.
Но если у вас какая-то обработка видео или больших файлов и compute выполняется на микросервисах, а в БД запросы идут относительно редко для получения / обновления метаданных, может сработать.
высокая сцепленность кода происходит из за излишней перегруженностями слоев и паттернов в архитектуре. Когда их больше 3х то все скоро проект уйдёт в красную зону)
Микросервисы на C#. Часть 3