Size: a a a

Архитектура ИТ-решений

2021 July 12

KK

Kirill Keker in Архитектура ИТ-решений
+
источник

--

- - in Архитектура ИТ-решений
а вот выше которая, плавно перетекшая в обсуждение снапшотов БД и отката миграций.  :)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Так там ничего не было про микросервисы, обсуждали только возможность обеспечить HA и низкий простой для монолита.

Про плюсы и минусы микросервисов даже не начинали говорить )
источник

--

- - in Архитектура ИТ-решений
Mea culpa :)
было бы интересно почитать - впрочем, наверняка, здесь такие уже были. Приеду домой - поищу, в отпуске не очень удобно это делать.
источник

P

P in Архитектура ИТ-решений
а вот с темы про ORM как-то съехали - без заключительных выводов. Все ждал доберется кто-нить до 1С - ORM оно или не пойми что?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, 1С - это большой DSL, насколько я могу судить. Это уже другой инструмент )
источник

М

Мария in Архитектура ИТ-решений
Смотря какой уровень. Для начинающих можно попробовать. Начинался отлично, но через 2 модуля сбежал преподаватель. Сейчас лекционные видео ведут 2 человека, один -  нормально, второй - ужас. И да, начинался примерно с Нового Года, закончится в сентябре, пока ещё не все модули записаны
источник

p

pragus in Архитектура ИТ-решений
Ну я уже несколько раз говорил про размер failure domain, graceful degradation и возможность в следующей версии сервиса заменить субд.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, возможность замены СУБД никак не связана с микросервисом или монолитом, она точно такая же для отдельных модулей в монолите, как и для микросервиса.
источник

p

pragus in Архитектура ИТ-решений
Конечно не связана. Но в монолите это боль, потому что "зачем соблюдать контракты, если можно джойнить соседнюю табличку?". Ну и вопросы деплоя, да.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, при этом обычно сджойнить табличку - в несколько раз проще и эффективнее, нежели прикручивать любое другое решение.
Распределенные джойны и распределенные транзакции - основная боль микросервисной архитектуры (и именно поэтому микросервисы нужны обычно в тех сценариях, когда без них не обойтись).
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну и есть еще куча вариантов с цитаделью, модульным монолитом и прочими промежуточными сценариям )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А деплой, как мы выяснили, для монолита точно такой же, как и для одного сервиса. Ровно с теми же проблемами.
Т.е. если решаем задачу с десятком сервисов - то их деплой в 10 раз сложнее, нежели одного монолита )
источник

p

pragus in Архитектура ИТ-решений
Так ведь каждый такой джойн увеличивает техдолг. И что делать с бюджетированием каждой подсистемы по cpu/mem? Чтобы какой-нибудь рассыльщик почты не съел все ресурсы у более важных частей монолита?

Я видел людей, которые логгирование делали в ту же бд, где данные пользователей и история их заказов. Очевидно, что при росте активности пользователей наступает беда. Не обязательно причиной может быть логгирование, но как нам выставить бюджеты по iops/tps для каждой подсистемы, например?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но почему это техдолг? Оно техдолг только если мы хотим разделять на сервисы, так-то это нормальное решение для монолита или цитадели..
источник

p

pragus in Архитектура ИТ-решений
Потому что база может кончится(в плане ресурсов), например.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А для работы с бюджетом - есть просто perf testing, есть паттерн цитадели. Ну и для большей части проектов это просто не нужная вещь.
Даже для микросервисных проектов бюджетирование отдельных сервисов часто (обычно) не нужн )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, обычно если кончается база, то переход на микросервисы не сильно спасает, там нужно менять более глубокие вещи.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но не во всех проектах кончается база, это вообще нужно изрядно постараться, чтобы база закончилась )
источник

p

pragus in Архитектура ИТ-решений
А потом кто-то закоммитит O(n^2) и оно протечёт в прод. А перф-тесты не поймают, потому что тесткейсы не покрыли это.
источник