Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
так как это положит почти всю систему. А это уже свойство монолита
Давайте так - это свойство Вашего монолита
так как одним из преимуществ микросервисной архитектуры заявляется бОльшая, чем у монолита, устойчивость, которой здесь и не пахнет
Нет у микросервисной архитектуры никакой устойчивости, если вы её сами не реализуете)
Вы сейчас переизобрели event-driven "конвеер" типа ETL.
Свойство монолита (любого, не только моего) - если падает, то падает всё. Неотъемлемое свойство монолита. Речь была про это, возможно, выражено не полностью ясно.
Однако для монолита проще реализовать отказоустойчивость, чем для каждого микросервиса в отдельности и всех возможных связей между ними.
Согласен с коллегой выше, тут дело не такое простое.
Микросервисы используются не потому, что они проще, тут не о чем спорить, микросервисы намного сложнее. Это очевидно. Они используются для изоляции, горизонтального масштабирования, устойчивости к частичным отказам (и вообще - к существованию такого явления) и т.д. и т.п.
В любом случае, статья не про микросервисы vs монолит, мы обсуждаем незначительную деталь. Есть ли смысл?
Есть смысл! Потому что вы произносите, мягко скажем, сомнительные тезисы и чаще всего этими тезисами аргументируете переход на микросервисные/распределённые архитектуры, что удорожает разработку в разы!
Вам сразу зачем то понадобилась изоляция, почему-то монолиты перестали масштабироваться, а отказы у микросервисов вообще пропали как явление)
Если у вас в монолите, по какой-то причине, падает поток/корутина, то это не значит, что у вас должно упасть всё! Это значит, что поток не был покрыт try ... except (python) и не были обработаны все критические участки кода на ошибки.
По такой же причине у вас может упасть любой микро/макро/наносервис!
Так что не надо переваливать ответственность с кривых рук на архитектуру)
UPD Более того, вы все так же можете перезапустить этот поток/корутину, если у вас это продумано и над изоляциями предусмотрены обёртки, которые, в случае падения критически важного потока/корутины, перезапускают её и восстанавливают стейт.
Свойство монолита (любого, не только моего) - если падает, то падает всё. Неотъемлемое свойство монолита
Нет. Ничего не мешает создать сервис в монолите и супервайзер для него. Падать всё может только через oom или какие-то общие системные ресурсы, но это скажем так зависит от технологического стека и много чего. Часто это влияет на устойчивость довольно мало и такие монолиты живут кварталами аптайма, опыт есть.
Тут ещё, по большому счёту, вопрос терминологии, являются ли сервисы в монолите микросервисами или монолитом.
В ИТ вообще нет четких определений нигде, это не математика.
Но если сослаться на признанных авторов книги «Фундаментальный подход к программной архитектуре» авторов Марка Ричардса и Нила Форда, то микросервис это логическое И, одновременно несколько факторов:
Распределённая архитектура, то есть независимый деплой
По одной бд на микросервис (если нет, то это не микросервис, а service based architecture)
Вероятно что-то ещё, не важно сейчас
В нашем случае оба признака не выполнены.
Многие соображения очень справедливы, однако надо иметь в виду, что основная проблема микросервисной архитектуры в её традиционной реализации проистекает непосредственно из принципов OOP/OOD, а именно речь идёт о дублировании исполняемого кода в результате наследования. Разные микросервисы будут реализовывать одинаковые алгоритмы обработки разным исполняемым кодом (в лучшем случае отнаследованным от общего прототипа, а в худшем – реализованным независимо, как вы приводите в пример). Потом даже в этой общенаследной реализации в большом проекте неизбежно разойдутся версии фреймвока в разных микросервисах, и через несколько лет уже будет не разобраться, что там откуда берётся и как это всё вместе работает. В пределе это приводит к тому, что разные микросервисы даже скомпилировать в одном окружении уже не получается.
Для решения этой проблемы микросервис должен представлять собой не реализацию, а только интерфейс, обрабатываемый одним универсальным ядром. Как, например, программ на Питоне много, а интерпретатор у них один (тут некоторые, правда, тоже скептически улыбнутся и вспомнят про env). В более практичном случае этот подход приводит к DSL. В общем, это переход от "тяжёлого" разделения функций программных компонентов к "легковесному".
По моему, статья странно построена:
Есть какие-то ограничения, которые сразу принимаются как аксиомы - Что у нас (обоснованно) выбрана микросервисная архитектура - Что мы должны соблюдать принципы локальности/владения. И из таких предпосылок уже следует куча сложностей, которые мы героически решаем.
Обычно интересно как раз понять изначальную проблему откуда вытекают ограничения. Чтобы понимать потом, что эти сложности оправданы.
Иначе, вне контекста, хочется предложить выбрать (оправданно) монолитную архитектуру. И избежать кучи проблем =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Владение и локальность