На примере фактории - это не микросервисы. Не вижу здесь ничего схожего с микросервисами, так же можно сказать что это просто набор различных асинхронных процедур не связанных между собой и использующих общую базу данных (сырье и материалы - это записи данных в БД) Микросервис выполняется по КОНКРЕТНОМУ ОДНОМУ запросу, а не решает задачу в отрыве от запрошенного контекста. В примере на игра фактория - это показать невозможно, так как в игре нет такой специфики. Так как ролик обучающий принципам парадигмы - это нужно упомянуть, чтобы у приобщающегося адепта - было правильное понимание всей идеи.
Ага, создай микросервисы без необходимости и получи или распределенный монолит, или решай проблемы с eventual consistency. Совет тимлида раскрывает то, что он не может в архитектуру проекта и лепит лапшу.
@MrLotrus братан, ты не выкупил очевиднейшую шутку про худшее возможное поведение. Поздравляю, теперь ты очередной душнила, который душнит, чтобы душнить 😁
@@DeadRabbitCanDance а если создать отдельные небольшие заводы в игре (работающие со своими ресурсами), это будет удовлетворять вашим притензиям? (я не в теме особенностей самой игры и какие там ограничения)
Возражу по некоторым моментам: 1. Автор на протяжении всего видео говорит от том, что монолит обязательно неустойчив к ошибкам, что падение любого компонента обязательно валит всю систему, а вот микросервисы волшебным образом автоматически становятся устойчивы к ошибкам. Но на самом деле устойчивость системы к ошибкам зависит от системы обработки ошибок, а не от топологии (монолит/микросервисы). Микросервисное приложение всё также будет падать от любой ошибки в любом сервисе, если в нём не предусмотрена обработка ошибочных ответов от других сервисов, в то время как монолит, в котором присутствуют try-catch блоки, на любые проблемные ситуации будет стабильно и корректно реагировать. Так же как в Factorio, если какое-то производство встанет, следующие за ним тоже встанут, независимо от того, как они соединены, если только не предусмотрены буферы. 2. Микросервисы не являются единственным способом разделения сложного приложения на составные части, монолитные приложения тоже прекрасно с этим справляются, разделяя приложение на компоненты (dll, jar...), а компоненты на классы/модули. Такие компоненты и классы могут быть вполне логически независимыми, их легко независимо тестировать и изменять, в том числе заменить один из них на микросервис в случае высокой вычислительной нагрузки. В Factorio аналогом будет база с главной шиной и перпендикулярными к ней блоками производств. Каждый из таких блоков можно изменять независимо от других, а если нужно улучшить производительность, а выделенного места не хватает, заменить производство на ж/д станцию, на которую привозятся ресурсы со специализированной базы. 3. Не стоит забывать и про различия между Factorio и программированием. Например, современные компьютеры очень мощные, поэтому достичь производительного лимита в монолитном приложении непросто, для этого нужно либо огромное количество пользователей, либо крайне ресуроинтенсивные задачи, такие как нейросети, в Factorio же различные боттлнеки, где, к примеру, одного конвейера уже недостаточно для транспортировки какого-либо ресурса, весьма часто встречаются. Такие ситуации в Factorio, где главная шина становится настолько широкой из-за большого разнообразия ресурсов в каком-нибудь модпаке, что пользоваться ей становится непрактично, вообще никак не ложатся на программирование, где можно в DI контейнере зарегистрировать хоть тысячу различных сервисов, что никак не затруднит взаимодействие между ними. 4. Автор говорит, что микросервисы обязательно использовать в сложных приложениях с большим количеством функционала и необходимостью иметь возможность эффективно вносить изменения (вообще, такая возможность должна быть в ЛЮБОМ приложении, мы ведь пишем SOFTware). На самом деле всё это никак не обязывает к использованию микросервисов. Если эта какая-то система учёта чего-либо для внутреннего использования в какой-нибудь компании, микросервисная топология, как мне кажется, будет тут оверинженирингом.
да согласен, зачем систему писать одновременно на пайтоне и на го и Java. Просто потребуется больше разных специалистов и все. А разбиение на модули это тот же аналог микро сервисов. Микросервисы делают разбиение компонентов на уровне http, а такое не всегда надо. Любая ОС это не микро сервисы, а отдельные программы exe и библиотеки, так что микросвис это один из способов распределенной системы. Скорее микросис позволяет сделать распределенную систему работающую на разных серверах, но по сути это просто проксирование на уровне nginx. Поэтому микросервис это просто администрирование, и построение распределенной системы. Но чтоб построить распределенную систему нужны монолиты, которые в следствие могут быть объедены, поэтому если идти в глубь программирования можно изучать монолит, микросервисы это так поверхностное администрирование систем
@@-Postoronnij- Самое принципиальное отличие, что все модули что собираются в один "монолит", это те же самые микросервисы, просто теперь взаимодействуют через сетевой протокол. Принципиально ничего нового не изобретено.
@@-Postoronnij- Микросервисы - множество приложений, общающихся между собой по сети, каждое из которых можно запустить на отдельном компьютере. Монолит - единое приложение, всегда работающее на одном компьютере.
Все верно. Стабильность приложения не зависит от того - монолит это или же микросервисы. В микросервисной архитектуре хватает своих подводных камней. Если сервисы связаны, то при отказе одного из них остальные точно так же будут простаивать. В случае большого числа экземпляров микросервисов можно вывести систему вообще в непредсказуемое состояние, если, допустим, при обновлении половина экземпляров уже новая, а половина еще нет. И многие другие проблемы. Микросервисы сложнее выкатывать (их больше), в случае проблем часто тяжелее искать причину, т.к. бывает, что невидимая ошибка в одном сервисе приводит к неработоспособности другого сервиса и приходится разматывать длинный клубок. Большие нагрузки на сеть и много чего еще. Так что стабильность, отказоустойчивость и т.д. и т.п. зависит от сложности выстраиваемой системы и правильности построенной архитектуры.
Я столько опытных людей никогда не видел под видосами про программирование. А как на примере факторио, то сразу все эксперты мира сюда пришли. Такое ощущение что все уважающие себя технари после работы (иногда на заводе), идут играть на завод
Все мои друзья играли через супер монолит - а я решил как прогер попробовать поиграть в распределенную фабрику, было прикольно увидеть +- похожие плюсы и минусы подхода)
@@maxsolodiov5245 мои друзья тоже строили монолит , всё на куче и не понятно как , а я вот сделал всё через микросервисы , видел бы ты их реакцию когда их систему пришлось расширять)
@@maxsolodiov5245 я играл с друзьями , они строили супер монолит, чтобы ни одного пикселя свободного не осталось , а я играл в распределенную фабрику , как ты Было классно увидеть как они ломали голову , как бы увеличить и оптимизировать завод , а у меня он уже оптимизирован , а увеличить его можно за 2 минуты)
проблема микросервисов в том, что доменные сущности внутри них свои собственные. и поэтому обмен данными между микросервисами подразумевает такие шаги - замапил доменную сущность источника в транспортную - передал транспортную - размапил в доменную сущность приёмника таким образом у вас копится огромная туча копипасты доменных сущностей (которые с большой вероятностью будут очень друг на друга похожи, потому что по сути-то отражают одни и те же реальные объекты), но при этом скорее всего будут обрастать какими-то локальными частными особенностями, т.к. сервисы развиваются независимо (это ж постулируется как их преимущество). плюс помимо тонны копипаст "почти одинаковых но чуть-чуть отличающихся" сущностей, у вас ещё будет две тонны "почти одинаковых но чуть-чуть различающихся" мапперов "туда и обратно". и хорошо, если у каждого микросервиса будет своя команда поддержки, тогда можно сделать вид, что про другие сервисы они ничего не знают, так что "всё хорошо". но обычно поддерживать все эти сервисы приходится одним и тем же людям. вот тогда-то они и вкусят все прелести поддержки этой шляпы. вбрасывая время от времени робкое "а что нам мешало просто изолировать код в монолите, разложив по папкам. и не плодя тонны мапперов и разносервисных копий сущностей?" но это будут риторические вопросы, потому что инерция проекта и инерция команды уже не позволит ничего изменить.
Видимо потому, что в разработке чаще принимают стратегию monolyth-first, и только потом если видят, что система разрастается принимают решение о распилке (главное, принять это решение вовремя пока не разрослось в гигантский шар грязи). В факторио же изначально понятно, что проект в конечном итоге будет сложным. Так что сразу можно думать над "модулями". Но вот чем факторио сильно отличается от разработки, так это тем, что модули в ней физические. То есть логика жестко завязана на инфраструктуру - нет возможности потом смасштабировать каждый конкретный модуль, если заранее не заложить такую возможность😢
Если транспортный уровень доменной области выделять в отдельные подключаемые в зоопарк микросервисов (той же самой или другой доменной области) пакеты, то копипасты особо и нет. Тут скорее появляется небольшая проблема, связанная с версионностью - в пакетах крайне нежелательно делать брейкинченджи, нарушающие обратную совместимость. А именно - удалять или перемещать (remove, replace, rename) DTO, а так же удалять, переименовывать или менять тип данных у полей. Иначе после обновления пакета в сервисе - он вероятно перестанет компилироваться, если использует модели, в которых произошел брейкинчендж.
@@TimLaizaR228 Согласен с вами, работал на проекте, где как раз благодаря такому подходу доменные сущности были в целом одинаковы, правда там по сути не было "независимой" разработки. Команда всего-то из 10 разрабов была, всяких микросервисов штук 10, и пакетов к ним примерно столько вроде, при обновлении пакета, надо было пройти во все сервисы где он юзался и стянуть новый пакет, что и решало брейкинченджи по сути. Это было на заре карьеры, сейчас мне ваш вариант всё-таки кажется лучше, ведь когда реально нужны микросервисы, с большим их количеством, с большой командой разработки, проходится по всем микросервисам и обновлять пакеты путь в могилу для проекта. Как решение думаю внедрение версионности самой доменной сущности, будет условный пакет менеджер версий сущностей для этого, задача которого, в трансформации сущностей между их версиями, так что микросервис сможет принимать любую версию сущности, а наш менеджер трансформит её в версию сущности которая испольуется в конкретном микросервисе. Как по мне это решает данную проблему, но к сожалению пока не было возможности протестить такой подход на практике, так что думаю тут по любому есть какие-то подводные камни, надо как-нибудь протестить.
Объяснено прикольно, только вот применительно к Факторио есть один нюанс, самые производительные базы это здоровущий монолит особым образом спроектированный, а ситиблоки просаживают ФПС и распухает объём файла сохранения, не говоря уж про то, что половина сити-блоков обычно просто простаивает. Ничто не сравнится в эффективности с хорошо спроектированным интегрированным монолитом, просто его делать надо как положено, а не на коленке. А с микросервисной архитектурой есть нюанс и это подтверждается моим опытом, что если нет профессиональной команды и архитектора, то накладные расходы, на облачную инфраструктуру, на всякие гипервизоры и согласование работы модулей улетают просто в космос, если это легаси система, то отладка просто кошмар, если каждый микросервис в отдельном проекте висит то это всё, тушите свет, можно месяц искать причину, почему совокупное состояние системы глючит. Потому даже для матёрого энтерпрайза микросервисы не волшебная таблетка, а лучше всего работает гибрид и команда настоящих профессионалов, которые пилят проект.
Вот сразу видно, человек реально работал с микросервисами. Мы перешли от монолита к модным микросервисам и вроде всё было неплохо пока их было 10-15, но звоночки уже тогда стали поступать, а сейчас в несколько раз больше. А когда функционал всей системы всей системы всё растёт и растёт, то вспоминается старый добрый монолит, где достать до нужного модуля гораздо легче чем через цепочку микросервисов. В общем везде своих и плюсы и не менее ужасные минусы. Но иногда народ не понимает где нужно остановится и подумать верно ли выбрали итоговую архитектуру, и не гнаться за "трендом" только потому что все вокруг так делают
@@andry_smith для каждого масштаба проекта есть предельный "возраст". то есть не факт, что решение, работавшее на 10-15 сервисах готово к масштабированию на 80. без рефакторинга и корректировки стратегии ни монолит ни микросервисы не могут полноценно развиваться
Микросервисы - это попытка превратить IT в конвейер. Стандарты разработки + стандарты документирования + минимальный набор функциональности на сервис позволяют обращаться с командами как с винтиками машины - рабочими на заводе. Т.е. к персоналу в этом случае применимы те же преимущества, что и к сервисам: заменимость, управляемость, масштабируемость. И, в будущем, замена AI-агентами.
@@Ainvain не знаю с чем вы встречались, но вы видели монолит в котором без документации годами не могут разобраться? а микросервисы зачастую тоже не документированы и запутаны в итоге этот AI там может только соснуть, и то промажет
Ну многие плюсы доступны и при грамотном проектировании монолита. Изолированность и независимость, но в сравнение с микросервисами меньшая масштабируемость. Я бы сказал что плохой монолит - это спагетти фабрика, а хороший - это шина. Есть лимит масштабируемости, но при этом довольно удобный и независимый, если изначально правильно спроектирован.
Холиварная тема поднята. Кое-что упрощено( я понимаю автора, сложно ужать такой вопрос в 15 минутное видео ), и из-за этого где-то спорные суждения ( как ниже было отмечено обработка ошибок зависит от системы обработки ошибок и профессионализма команды). Я хочу добавить на мой взгляд самое главное, система строится от требований, а не для архитектуры. Т.е. если у вас сложный но сильно связанный проект( доменная модель общая для большинства задач) - 100 раз подумайте прежде, чем ввязаться в микросервисы. Микро-сервисы хороши там, где задачи обособленны и максимально не зависимы с чёткими API и относительно небольшой долей взаимодействия между( т.е. внутри сервисов должно быть на несколько порядоков больше логики и вычислений относительно коммуникаций). Или там где можно сделать систему в разы сложнее( и более трудной в поддержке) в угоду решения очень специфических задач ( например конвейерная обработка миллионов запросов в секунду). Если же у вас обычное приложение ( где одна сущность может потребоваться в 20 разных местах, и требуется её взаимодействие с другими схожими объектами для реализации той или иной бизнес логики), то обычные (не микро) сервисы или монолит будут гораздо более эффективно и проще реализовать и поддерживать. Главное помнить, что монолит(или крупный сервис) не означает спагетти код и архитектурную кашу. Можно выделять либы, модули, слои, классы и пр. и жить прекрасно. Итог, микро-сервисы это лишь инструмент в арсенале архитектора, и как любого инструмента у него есть своя область применения ( я бы сказал, достаточно узкая зато хорошо распиаренная). Всем добра!
Натягивание совы, т.е. игры на программирование. "Добавь несколько плавилен и переделывать ничего не нужно." А место под них есть? А ресурсов в шине для работы новых плавилен достаточно? В программировании таких вопросов не встает. "Остановился сервис - ничего страшного." То есть от его работы ничего не зависит? Тогда зачем он нужен? А если зависит, то остановится не только он, но и все остальные по цепочке. Весь ролик в таком духе.
Если сервис остановится то его можно отладить без серьезных последствий для системы, и это вовсе не означает что последствий при поломке сервиса не будет никаких. Банальный пример: можно рассмотреть некий коллектив рабочих, если один рабочий не придет на работу серьезных последствий для системы не будет, в отличии от системы в которой работает всего один человек. Думаю именно это и пытался донести автор.
@@mikhailm6997 В любом градостроителе с элементами автоматизации можно найти какие то паттерны проектирования на что это больше похоже каждый решает сам.
просто тут плохая аналогия, приведена просто потому что вот это "программирование" абстрактное, везде и всюду встречается. факторио, это больше про цифровую электронику (именно цифровую), чем непосредственно программирование. И вот с ней параллели прослеживаются очень хорошо. И шины и синхронизации, и выделение в модули, и общий абстрактный интерфейс.
По этому видео я увидел что концептуально разницы нет между микросервисом и монолитом. Разница лишь в масштабах. В микросервисе производится один рецепт, в монолите - несколько. Сеть микросервисов - тот же монолит, с той лишь разницей, что вместо одного обработчика - группа обработчиков, соответственно большая площадь. В обоих случаях нужно думать, с какой стороны и чем выгоднее/красивее подвести входящие потоки, как соединить обработчики/их группы вместе и куда выгоднее/красивее вывести целевые и побочные продукты.
Хотелось бы услышать мнение DevOps на эту тему. И статистику для сравнения отказоустойчивости монолитных и микросераисных систем. И про High Availability и geographic redundancy.
Чел, ты крут❤ Понятно, что есть упрощения, но так прикольно запоминать, когда ты объясняешь на примере игры, а не на бесконечных абстракциях, которые сложно представлять.
монолит хорошо использовать на больших проектах. вместо разделения не микросервисы нужно разделять на модули. есть задачи, для решения которых микросервисы вредны. если в монолитной системе есть модуль, который не завязан плотно на другие модули, то его можно вынести в микросервис. но если модуль сильно завязаный на другие модули вынести в микросервис, то он будет нагружать сеть постоянными запросами и увеличивать задержку отклика. если попытаться решить микросервисами задачу, которая к этому не подходит, то получится куча монолитов соединённых ботлнэками.
Золотые слова. Наивные архитекторы, начитавшись модных статей, забывают про связность и сцепленность, и надеются, что микросервисы - это серебрянная пуля, которая решит все беды. Но если попытаться разделить монолит на сервисы без снижения сцепленности, то получится распределённый монолит, который принесёт с собой сложности распределённых взаимодействий, но от проблем монолита не избавит.
Отличный и очень полезный видос! Однако меня немного смущают “беззаботные” сравнения Factorio с архитектурой софта. Позвольте вставить свои пару слов об этих прямых аналогиях. На мой взгляд, модули и “ситиблоки” в Factorio гораздо ближе к классической инженерии, чем к программированию. Да, в игре есть аналоги модулей и чертежи (blueprints), но ресурсы и рецепты в Factorio устроены довольно жёстко: мы не можем просто подставлять переменные “на лету”, как в функциях кода. Если блок принимает три вида ресурса и выдаёт один, то он всегда работает именно так. Поэтому классический микросервис с множеством входных и выходных данных тут не приживётся. Главный вызов Factorio - не построить саму “коробочку” (блок), а грамотно масштабировать производство, выстроить логику поставок и развести потоки ресурсов. Конечно, программистская терминология может упростить кому-то понимание структуры завода. Но в основе лежит именно инженерная задача: как эффективно соединить производственные цепочки и управлять ими на больших масштабах (проблема “мультиплексирования”). Чаще всего приходится думать не только о том, куда поставить блок, но и как подвести к нему конвейеры, или организовать перевозку дронами и поездами или ракетой. В мире микросервисов эти вопросы решаются через сети (TCP/UDP), а тут - через реальную логику перемещения материалов. И это, на мой взгляд, принципиально иная парадигма.
Супер идея и гайды. Благодарю. Единственное нужно добавить какой-нибудь словарь терминов для совсем нулёвых в теме. Осталось теперь к рассказам и практике на игре добавить перенос этих конструкций в код )) Тут уже целое обучение делать можно
К микросервисам, по мне, в основном приходят когда в монолите ресурсов уже не хватает (цп, память, диск), и нужный процесс выносят в микросервис. Так же, туда выносят элементы и бизнес процессы, которые не должны сбоить. Если монолит начнут ддосить, его сложно прикрыть без потери доступа к сервису, а вот микросервис можно оставить доступ только авторизованным пользователям (в монолите наверное тоже можно, но с учетом ширины функционала, может быть трудно ввести без внешних систем). Ну и legacy монолит удобно разбивать на микросеовисы, да, по тихоньку превращая его не в legacy, условно перенося код из php в python.
Всегда все зависит от бизнес требований. Если вы только начинаете работать, то создавая микросервисы вы должны понимать потяните ли его обслуживание и стоимость ведь это разные специалисты, зависимости, языки, опыт, серверная конфигурация. Готовы все это организовать грамотно? Если нет - сделайте монолит, потом постепенно переписывайте на сервисы. Код всегда можно переписать было бы желание и необходимость. В то же время если вы понимаете, что какая-то часть функционала полностью самостоятельна и при этом будет использована в каких-то других подпроектах то именно этот функционал можно вынести в сервис и общаться с ним с основным приложением. То есть делаете придожение так, чтобы оно выполняло задачи. Например: стоит ли делать сложный магазин как микросервис? Нет, скорее всего нет. Стоит ли делать сложный магазин у которого есть индивидуальная реклама с сложными алгаритмами расчета, аналитическая система прожаж и логистики, административная панель селлера, финансовые и рекламные инструменты и все это под единным аккаунтом? Да, вероятно стоит, как минимум сервис авторизации стоит вынести в сервис, а остальное по ситуации либо выносить позже, либо делать соазу сервисом если для выполнения задач оптимальне использовать другие языки.
За научпоп спасибо! Думаю тем кто еще не сеньор будет проще понять все, особенно типы взаимодействий в микросервисной архитектуре, тут с конвейерами дронами и поездами на мой взгляд просто супер! ) Ну и добавлю немного, на мой взгляд, по наблюдениям при прочих равных монолиты справляются обычно быстрее чем микросервисы. А по остальным спорным аспектам, то тут можно спорить и до цифры когда забыл поставить условие выхода из бесконечного цикла) Здесь допустим набежало довольно много программистов, а ведь по отказоустойчивости можно и пойти к девопсам, чтобы k8s накатили отказоустойчивый на каждый модуль и т.д. )
Как-то раз собрался дед готовить репу, Вокруг все собрались, смотрят на него свирепо. Мышка говорит: "Да ну, это ж монолит, Будешь так готовить - нам Жучка не простит". Жучка гавкает: "Давай разобьём на атомы, Там сделаем по красоте и будем пионерами. Я читала книжку тут по архитектуре, В Америке такие движки двигают в натуре". Бабка принесла из сарайчика ружьё, Деду говорит: "Отойди, ё-моё". Жахнула по репке, и разлетелась репка, Жахнула метко, не осталось даже щепки. Внучка говорит тут: "Эй матери мать, А как же нам теперь всё это собирать?" Глаза все опустили, не смотрят на деда, Пришло в русском стиле время обеда.
Случайно наткнулся на это видео, как раз планирую начать изучать Go. Несмотря на то, что ни когда не играл в Factorio, очень доходчиво рассказал о микросервисах, спасибо.
классное видео. спасибо за труд! подними тему монолит/микросервисы, тут же куча умников скажет тебе, что ты нихрена не шаришь. Классика) в комментах много "возражений", которые по сути повторяют те же тезисы, но с посылом, что автор ошибается внесу свою лепту)) аналогии взаимодействия МС перепутал: REST - дроны (синхрон, пока дрон не вернется он не понесет след. ресурс) MQ - конвеер (ассинхрон, кладешь ресурсы сколько сможешь, ограничение лишь в самом конвейре)
Спасибо за добрые слова и за вклад в обсуждение! Рад, что тема вызвала такой интерес, даже если мнения порой противоположные. Твоя аналогия с REST и дронами действительно логична, как и сравнение MQ с конвейером - отличный взгляд! Я выбрал другие сравнения, чтобы подчеркнуть разные аспекты взаимодействия, но твой подход тоже отлично объясняет эти концепции. Такие обсуждения только обогащают тему, так что спасибо за участие!
Судите сами, выражу специфическую мысль: лучший аналог в рамках сравнения - онлайн-игра, где каждый игрок строит свою собственную базу как пожелает и независимо (возможно, находясь вообще на разных планетах). Но вместе они - команда, где каждый заточен на своей специфике и том, что ему нравится больше всего. Они завязаны на общий ход событий, имеют договорённости (а-ля квесты). По типу: "с заданным периодом к такому то сроку передать туда-то и туда-то такие-то ресурсы". В итоге это всё может вылиться в такой себе набор блэк-боксов, где самое прозрачное - это стандартизированный метод коммуникации. Это в игре. А в реале всё с точностью до наоборот)))
Это печально. Так как понять бред это значит наполнить голову мусором. Не сказать что все что говорит не верно, но и правдой это ни как не является. Возможно стоило бы тут писать кучу текста в оправдание моих слов, но благо за меня это уже сделали ребата в комментариях. И почему автор решил строить свои объяснения на факторио при том что она оказалась не пришей кобыле хвост...
В Факторио ситиблоки очень неэфективная организация производства, производственные блоки простаивают более 50% времени, так как поезда не могут обеспечить непрерывность прозводства. Основная задача поездов, это обеспечение работоспособности удалённых производств, всё остальное это просто "костыли". Так что поезда можно сравнить с последовательной однопроводной шиной, как "one wire" и ей подобные. Ситиболки же похоже на попытку решить сложную вычеслительную задачу с помощью кластера ардуинок уно, что само посебе выглядет бредово, и это при наличи специализированных вычеслительных машин.
Ситиблоки это очень классная система когда ты не хочешь думать а идешь по пути копипаста. Тоесть твоя задача натыкать подобное на подобное и получить некий результат, а позже соединить все в одну систему. Ааа и еще ситиблоки круто смотрятся на видео роликах))
в смысле " поезда не могут обеспечить непрерывность производства" это как вы так строите ? что не могут. у меня ситиблоки и поезда загружают склады под крышечку. Если ваш сити блок вдруг съел все ресы из склада потому как их не успели подвести паровозы то будете добры поставьте 2-ую станцию или третью и так далее.
@@drjonn да, только это система на переизбытке добычи и недостатке переработки. Что по факту напраская трата ресурсов (на строительство). Если же у тебя обработка будет равна добыче или больше, то обработка будет простаивать в ожидании пока привезут новую партию... и бла бла ... фактически нынешнее программирование очень похоже на ситиблоки, когда расход ресурсов на систему куда больше чем нужно для выполнения задачи, ибо так проще так легче. В итоге куча неоптимизированого ПО которое жрет ресурсы нещадно... Ситиблоки это про эстетическую красоту и простоту, но с перерасходом ресурсов...
@@Fant0m95 ну соглашусь но только частично. Дело в том что я строю добычу как и расход строго на основании пропускной способности конвейера. (30 предметов в сек).( и просто масштабирую при более крутых конвейерах) И цепочка включающая в себя паровоз с парой вагонов у меня ее никогда не задерживала. А что касается программирования то да есть там такая тенденция с неоптимизированным кодом. Но тут виноваты слишком мощные компы (я ушел от программирования в инженерию на изломе века так что мои познания заканчиваются на бейсик, паскаль, ассемблер где частенько оптимизировать код весьма сложно. он уже достаточно плотный) там можно только оптимизировать целиком блок-схему.
@@drjonn А вот тут я точно не соглашусь. Проблема не в мощных копмпах, а в том что к ресурсам нынче относятся наплевательски. Где это видано чтобы выходила игра и самое мощное железо на рынке, 4090 уже не могла играючи его вытягивать ... И мы переходим в гонку когда браузер забивает 8ГБ оперативы кучкой говноОдностраничников с кучей анимаций и вылетающей дребедени, когда кто-то давнавато кричал 640КБ хватит всем )) и под это все штампуют железки чтобы хоть както выдерживать потоки говнокода и великие труды миллиона полигонов на песчинке))) накипелов)
как то в общем всё, хочется на конкретных задачах в факторке. А то по сути единственный выход - это ситиблоки ставить, которые уже надоели, все друг у друга копируют их и радуются
Общо всё, потому что тут задача объяснить была принципы микросервисов, а не подать идеи для факторио. Если честно, к факторио конкретно то что автор описывает в качестве различий между монолитом и микросервисами впринципе не очень применимо, ибо что при модульной проектировке от того, что навернётся один модуль у тебя могут встать все соседние, что в монолитном производстве встанет только то, что зависит от конкретного ресурса, а то что не зависит - продолжит работать(не рассматриваем электроэнергию, потому что она в любой архитектуре одинаковую роль играет). Ну и в факторио основной фактор выбора архитектуры это "пропускная способность" в широком смысле, т.е. ты оптимизурешь производство исходя из того, как наиболее эффективно ты сможешь ресурсы доставить, потому что у тебя всегда задача получить n ресурса за t времени. В разработке такие задачи конечно бывают, но всё же данные принципы немного о другом
А по поводу того, что сити-блоки надоели - просто не копирайте у других и думайте сами. Сити-блок это архитектурный принцип, что в Сити-блоке будет содержаться и как он будет организован/оформлен зависит только от вас. Ну и да, никто не мешает играть вообще без сити-блоков, стройте чисто на поездах обеспечение, стройте дрон-цеха. Если вам кажется , что всё перепробовали, поставьте себе какой-то сценарий или попробуйте модификации типа красорио или боб+анджел - поверьте, все устоявшиеся схемы придётся пересмотреть.
Хе. Я пока играл в Shapez 2 решил попробовать новый принцип: спагетти блоки. По сути это те же сити блоки, но они имеют самые разные формы и размеры, а внутри делаются несколько продуктов (или они используются как проходной двор для других сити блоков, стоящих вплотную). Также иногда я облеплял такими блоками один крупный вокзал, чтобы не делать каждому блоку зону погрузки и разгрузки. Получается интересно и эффективно, но спроектировать такое сложно, а работает всё очень запутанно и лучше лишний раз систему не трогать.
Допустим сделали ERP на микросервисах. Каждый микросервис имеет свою базу данных. Производство и одном микросервисе, Склад в другом, Поставщики в третьем и т.п. Получаем сто-пятсот изолированных баз данных по котором разбросаны части единой по сути информационной системы. И вот нужно составить запрос использующий и товары, и поставщиков, и продажи, и лояльность, и налоги, и еще что. В монолите это будет один SQL запрос к единой БД. А что будет в микросервисах?
По хорошему в микросервисах будет брокер сообщений с историей операций по добавлению и изменению этих сущностей. И будет отдельный микросервис для аналитики, агрегирующий эти данные у себя в базе в широкой таблице. В результате будет тоже один sql запрос, причем даже без джоинов. Один нюанс - это всё ппц какой оверхед по сравнению с монолитом. И вот такие видео вводят людей в заблуждение, что почти всегда надо выбирать микросервисы. Тогда как наоборот, почти всегда достаточно монолита и может ещё несколько отдельных вспомогательных сервисов.
А как вы подразумеваете получить все эти данные одним запросом к БД? Вроде же и нужно делать несколько запросов для каждой таблицы, иначе получается каша.
Лайк за тему Дизлайк за содержание. Плюсы монолита: - меньше точек отказа (главное) - меньше ресурсов затрачено - легче сопровождать (с точки зрения бизнес логики) - меньше абсолютное время сбоя. Плюсы микросервисов: - меньше влияние от сбоя (один сервис не тянет за собой все) - больше вариантов для беспростояного деплоя. - маленький объем самого сервиса позволяет легко его контейниризировать и управлять из под оркестратора. - следствие последнего легко масштабировать. Сказано только 3 основных тезиса в видео. )))
Спасибо за комментарий! Ты абсолютно прав насчет плюсов микросервисов и монолита. На примере с Factorio не удалось показать все аспекты - часть была намеренно упрощена, чтобы сделать объяснение понятным для людей, которые только начинают разбираться в теме.
С наступившим новым годом, классный ролик, Нужен совет, с чего начать разработку проекта, если первая попытка разработки планируется соло? Но однозначно на микросервисах
Одна из причин почему так тяжело понять принцип работы мозга. Вроде как есть микросервесы, но... Фифти фифти. Соеденены они методом спагетти и могут замещать функции другу друга
По автору: Красавчик) 2 архитектурных решения очень простым и понятным языком. Тут очевидно лайк👍 за знания и за очень понятный контент! Немного по микросервисам: Ты сказал что для разработки и поддержания микросервисов нужна комманда разработки. Но на самом деле всё зависит от аппетитов, может и хватить одного) Немного по монолиту: По сути это первое решение каждого разработчика в начале карьеры. Тут факторио и разработка сплились воедино) Так как в факторио никто не начинает с ситиблоков, до них нужно дорасти)
зачем нужен такой микросервис если от его остановки ничего не проходит и ничего от него не зависит? Отладку в монолите так же можно делать отдельно, разбей на библиотеки. В микросервисах накладные расходы на связь между сервисами иной раз совсем уже неприличные. Как и в факторио появляются задержки на поезда, загрузку/разгрузку. Итог - надо писать под задачу, не бывает универсального решения. Как и в факторе - если ошибся в планировании - начинаются проблемы с масштабированием и исправлением ошибок.
Да, разбивать монолит на библиотеки - это рабочая штука, особенно если всё грамотно организовано. Но микросервисы дают ещё один уровень изоляции - если один сервис падает, остальные продолжают работать. Накладные расходы на связь - согласен, это боль. Но когда всё настроено правильно, масштабируемость и независимость всё равно выигрывают. В любом случае, ты прав - планирование решает всё, и универсального подхода тут точно нет. Всё, как в Factorio: ошибся в планировании - потом разгребай!
Я лично строю что то между сервисом и монолитом. А вот с логистикой я пытаюсь расчитать логистический вес компонента (т.е например если нужны шестерни то выгоднее возить вагон шестерней чем плиты тк вес 1 шестерни это 2 плиты) фактически можно построить огромный молл и возить с него только нужные компоненты на ту же науку при этом расширить молл будет не сложно тк я сейчас занимаюсь разработкой универсального умного молла который будет сам выбирать себе рецепты в зависимости от задач на фабрике, правда вылезают артефакты с логическими сигналами но думаю оно того стоит например копирование сигналов после их отсечения на другие сборщики. (молл будет на дронах а базовые детали будут производится вне молла что бы снизить нагрузку на сам молл и дроны только потому что они позволяют ускорить производство через удобное размещение максимального колличества маяков на сборщик и имеют дичайшую пропускную способность на близких дистанциях)
В факторио лучше построить жд сеть в крупную клетку. Затем одну базу-строителя. Ее функция - молл для производства всех предметов без производства науки. Затем при накоплении ресурсов строить базы, производящие из первичных ресурсов только науку, причем лишь 1-5 каждой из банок в секунду. У и лаборатории для них. Смысла нет строить супер производства, например, синих схем, в одном месте. Будут постоянно пробки из поездов.
Я конечно не эксперт и в факторио даже не играл, но моя теория состоит в том, что пока вы думаете, что проэктируете микросервисы, в действительности вы просто строите монолит, в некоторой степени модульный, с собственными процедурами и функциями. Система располагается в "физическом" пространстве и её "микросервисы" и шины не могут в полной мере быть бесконечно масштабируемы. Проектируя систему вы НЕ можете полностью игнорировать вопрос взаимного расположения заводов и шин на игровой карте. Таким образом размывается единственное значимое различие в терминах микросервисы/монолит. О пародии на микросервисную архитектуру можно было бы рассуждать, если бы: карта была бесконечная, в любой точке карты возможна добыча абсолютно всех видов ресурсов в одинаковых и бесконечных количествах, здания заводов не ограничены по высоте (следовательно, могут расширяться бесконечно вверх), все связи осуществляются не по наземным шинам, а по средствам дронов. Не знаю, может так дело и обстоит, но мы никак не уйдём от: фактора взаимного расположения зданий заводов на карте, а следовательно, времени связи между сервисами и невозможности бесконечного расширения оснований заводов, рано или поздно соседние заводы при расширении коснутся друг друга, поэтому в начале разработки придётся рассчитывать приемлемое расстояние между заводов, что на мой взгляд противоречит концепции микросервиса, как единицы системы, а именно: независимая от других микросервисов возможность масштабирования.
Ну, в факторке я сначала делаю монолит до открытия поездов, убираю часть монолита, чтобы максимизировать производство поездов, а потом перехожу на сервисы
Если уж и брать факторио, то базу по шине нужно изначально расчитывать на н-ную производительность, и в рамках ее и происходит расширение, когда ты доходишь до рамок ты берешь и делаешь новое отдельное производство а не пытаешся глобально менять базу с шиной . А в итогемы имеем стартовую базу шине, а потом только ситиблоки (хотя базу на шине тоже можно ситиблоком сделать, но это извращение как по мне)
Модульность. Можно копировать блоки и ставить блоки если есть нехватка чего то. Что абсолютно не работает на Глебе. На Глебе придётся сначала сделать биокамеры в нормальном количестве и только потом приступать к строительству завода по науке и причём нельзя сделать поэтапно, придётся сразу делать одновременно.
Даже SOA - это кратное усложнение системы и дополнительные операционные расходы, которые должны быть чем-то оправданы. Про микросервисную архитектуру вообще молчу: 99% проектов и компаний в принципе никогда не дорастут до тех масштабов, когда это по-настоящему нужно. Проблема менеджмента в том, что они практически всегда недостаточно хорошо разбираются в проектировании и разработке и легко ведутся на такие эксперименты от не совсем компетентных архитекторов, которые не понимают, что делают.
Микросервисы удобны, но проблема в том, что с ними у тебя тратится значительно больше места, что увеличивает периметр обороны, что требует ещё больше ресурсов и их оперативной доставки. Плюс к тому главная шина становится прям неоправданно огромной. Тебе нужно, допустим, всего в одно место довести зелёные электросхемы, а ты ради этого продлеваешь четырёхполосную шину с этими электросхемами, да и все остальные продлеваешь. И получается что ты помимо самого микросервиса ещё потратил вдвое-втрое больше пространства, вместо того, чтобы построить этот "микросервис" где то поблизости от производства и провести адекватный конвейер.
Как по мне микросерсисы это прочвления принципа разделяй и властвуй. В любом проекте кодом данный концепт работает хорошо, человеческий мозг довольно ограничен в реурсах и возможность сделать цепочку действий позволяет ему лучше думать и понимать что происходит. Но это происходит и в хорошем монолите и в микросервисе. Вопрос наверное больше в связности и скорости выявления ошибок. Система микросервисов имеет огромное количество разных модулей которые (в идеале) не влияют друг на друга никак, кроме как вызов и обмен данными, те если баг возник в одном микросервисе то другой просто будет работать как есть и делать все как надо. Но черт возми от парадокса связности мы не избавимся. Как бы мы не раздвигали острова нашей абстракций по итогу все равно есть шанс что предыдущий сервис выдаст неверные данные а вся остальная цепочка обработа неверные данные... В целом это бесконечный легбез. Делай слишком мальенькое ты увязнешь в болоте. Делай большое и оно тебя задавит, а в реальности выигрывает балансные решерие. Когда несколько монолитов построили микросервисы (((;ꏿ_ꏿ;)))
1:34 Фз, всё время делаю +- 1 гигансткий. С поправкой на то, что переплавка металлов, никак не контачит с нефтянкой. 1:49 Опять же, фиг знает. Я всегда оставляю пространство, чтобы линию можно было продлить или расширить ещё на 2 - 3 потока. Нет, есть в начале игры, небольшие "местячковые" производства. Но они обычно живут, до момента открытия электропечей. А потом я делаю полосы производств, с отступами сверху/снизу/в сторону, чтобы было куда расширять и где прокинуть дополнительные конвейера. 1 конвейер, через всю базу - это проблема моего напарника, по игре. постоянно ему объясняю, что с таким подходом, его возможности - сильно ограничены. Но уже 3 игры подряд, он так делает и ему норм.. Хотя у меня тоже бывает длиннющий конвейер. Правда он идёт не через базу, а вокруг неё. Пока нет лазерных турелей или хотя бы огнемётных - пускаю один красный конвейер, чтобы снабжать пулемётные турели, вокруг всей базы😅🤷♂
Микросервисная архитектура никогда не предназначалась и не предназначается для решения технических проблем. Главная проблема, которую решают микросервисы - организация больших команд и разделение между ними ответственности. Например если у вас в монолите авторизация нагружает систему настолько, что её обслуживанием занимается несколько человек - имеет смысл выделить их в отдельную команду, авторизацию - в микросервис и полностью передать им ответственность за него. Цена, которую за это придётся заплатить - дополнительная сложность. А т.к. сложность всегда растёт экспоненциально - сложность монолита и этого же монолита, разбитого на микросервисы будет различаться в разы. Что потребует соответствующего бюджета на поддержку. Рассуждения автора о преимуществах микросервисной архитектуры не имеют никого смысла. Любые задачи можно решить обоими способами. Выбор между ними - вопрос организации команды. Если вам дали команду из 5 сеньоров - пишите монолит, что-то тяжелое всегда можно выделить в отдельный сервис. Если вам дали команду из 30 джунов - делите их на мелкие группы и выдавайте каждой по сервису. Т.к. монолит они все равно запроектировать не смогут, а так те косяки, что они наделают будут изолированы в их микросервисах.
Спасибо за такой развёрнутый комментарий! Согласен, микросервисы действительно часто выбирают для упрощения организации работы больших команд, и их внедрение действительно добавляет сложности. Но я бы не сказал, что технические аспекты совсем не играют роли. Микросервисы дают больше возможностей для масштабирования, изоляции ошибок и независимых обновлений - это может быть критично в высоконагруженных системах. Ты прав, что задачи можно решить обоими способами, и выбор архитектуры зависит от контекста. Я делал акцент на преимуществах микросервисов, чтобы показать их потенциал в подходящих ситуациях, но полностью согласен, что без грамотного подхода это может создать больше проблем, чем пользы. Спасибо за интересную точку зрения!
Чувствую себя гением, что сам до микросервисов добился играя в Сатисфактори, еще и шину огромную сделал до того как узнал рро неё, ещё и с буферами и складировкой
🤔 а если мне нужна большая програма для упрощения програмирования для себя? Просто локальная програма на с++. Типа продвинутий блокнот с автоматическими кнопками для кодинга и другое.
Все правильно но по аналогии сити блоки ну очень затратны по ресурсам. (примерно раза в 3-4) против монолита. С другой стороны если работников несколько то монолит строить не получается. даже в 2 хорошо понимающих друг друга игрока. Приходится строить микросервисы. как и программировании. если пишешь код в одиночку (ну до 5 человек) то однозначно выходит монолит. а если вас несколько ( больше 10) то только микро сервисы.
Ключевая фраза "если не планируется расширение/масштабирование". Всегда нужно закладываться на то что в процессе разработки/эксплуатации заказчика понесет и он захочет ещё много чего за что готов платить, а менеджмент будет кивать головой и говорить "да без бэ.."
Частично не согласен. Озвучены исключительно плюсы микросервисов и минусы монолита. Микросервисы точно так же подвержены каскадному отказу, как и монолит, но вот исправить проблемы бывает куда сложнее т.к. из-за "плюса" в том, что микросервис может быть написан на любом языке и любом инструментарии, исправить его может только тот, кто этот язык и инструментарий знает. Не получится попросить Java разработчика срочно исправить микросервис на Go. Даже если джавист имел ранее дело с Go, ему потребуется много времени чтобы разобраться в коде и найти ошибку т.к. когда падает микросервис, то ошибка скорее всего оносительно сложная. И после того как микросервис поднят обратно, то точно так же, как и для монолита, нужно запустить тестирования всего проекта, т.к. далеко не факт что исправление не порушило что-то где-то еще. Даже если все тесты сервиса проходят успешно (как минимум одну проблему уже не протестировали, значит тесты не покрывают все ситуации). На примере факторио - у вас отказал сервис производства угля. В итоге откажут сервисы производства стали и все остальные, которые зависят от угля и стали. Т.е. потенциально остановится вообще всё. Плюс в факторио в том, что язык и инструментарий унифицирован и достаточно просто это найти и исправить. В реальности же, если не унифицироан набор языка и инструментария для микросервисов, то проблема отказа куда сложнее и дольше решается чем в монолите. Далее - производительность микросервисной архитектуры не настолько высокая как заявляется. Из-за того что общение между сервисами производится по сети - возникают значительные задержки на выполнении задач, которые требуют взаимодействия между сервисами. На примере факторио это сложно показать т.к. тут принцип построения прямолинейный (произвел, отправил, забыл), а в приложениях он двунаправленный (получил запрос, обработал, отправил ответ обратно). Т.е. накладные расходы растут по мере увеличения количества микросервисов. В итоге как бы один микросервис не был хорошо оптимизирован, вся система не получит от этой оптимизации никакой выгоды из-за того что общение по сети намного менее эффективно чем в монолите. Ну и обслуживание зоопарка микросервисов - это тоже своего рода проблема. Причем достаточно затратная для бизнеса. Я к чему веду: микросервисы - далеко не идеальный принцип построения реального приложения. У него так же есть ощутимые минусы и далеко не всегда правильно построенный монолит проигрывает микросервисам хоть в чем-то. Про проблемы монолита. То, что вы строите в факторио в начале игры (если вы относительно новичок) - это не монолит, это х.як-х.як и в прод. По сути это минимально жизнеспособный продукт, задача которого проверить конецпцию и первоначально настроить проект и протестировать его. В реальности же монолит - это модульная система, где каждый модуль отвечает за свою задачу и обращается в другие модули, если это требуется. Ничего не напоминает? Модули при этом написаны на одном языке и инструментарии. Правильно построенный монолит достаточно устойчив к точечным отказам и не роняет всю систему из-за отказа в одном из модулей. Всё, что не зависит от отказавшего модуля будет продолжать работать. Сложно ли найти проблему? Нет, логирование ошибок настраивается на ранних этапах проекта и почти всегда можно найти ошибку по логам. А если ошибка связана с "поведением", а не просто "упало", то искать нужно в конкретном модуле или модулях, которые с ним связаны. При этом это может сделать любой разработчик, который работал на проектом т.к. язык и инструментарий для всех одинаков. Тестирование, да, нужно проводить полное, но это в большей мере решается автотестами и специальными сотрудниками (QA). Кстати, тестирование монолита проще организовать чем в микросервисах, особенно когда нужно тестировать весь проект. Да и вообще любой релиз должен проходить полное тестирование, даже в микросервисной архитектуре. Релизить с надеждой что при изменении одного микросервиса не посыпятся остальные - такое себе. А если пойти дальше, то найдется еще гибридный подход, где есть монолит и микросервисы одновременно, получая преимущества обоих подходов только там, где эти подходы наиболее эффективны. В общем - любой инструмент может привести к печальному результату, если его неправильно использовать. И цена ошибки при выборе архитектуры может быть очень высока для бизнеса. Слепо выбирать трендовую архитектуру, не понимая её плюсы и минусы - это как играть в рулетку. Может быть и повезет, а может и нет. Одного идеального решения нет. Под каждый проект нужно подбирать наиболее подходящее решение. И оценивать не только по архитектуре, но и по затратам на использование выбранной архитектуры т.к. проекты должны в первую очередь быть прибыльными, а не проедать деньги на неправильно выбранной архитектуре. Кроме материалов, которые восхваляют конкретную архитектуру/язык/инструментарий нужно так же искать материалы, которые жестко критикуют их. Так можно понять подходит ли оно к проекту или нет. И какие могут быть проблемы в процессе разработки и какие есть решения для этих проблем.
Спасибо за развёрнутый комментарий! Вы абсолютно правы, что микросервисы не идеальны, и я старался это показать, хотя мог не подчеркнуть все аспекты. Ваши замечания о каскадных отказах, сложности устранения ошибок и затратах на обслуживание полностью обоснованы. Микросервисы действительно могут усложнить поддержку, особенно если используется разнородный стек технологий. Однако стоит отметить, что компании, которые выбирают подход с микросервисами на разных языках и инструментах, обычно понимают все связанные риски. Такой выбор предполагает наличие сильной команды и процессов, которые минимизируют задержки в устранении проблем, включая грамотный CI/CD, логирование, мониторинг и тестирование. Это сложнее, чем унифицированный стек монолита, но те, кто идут этим путём, знают, на что подписываются. Я также освещал как плюсы, так и минусы обоих подходов. Монолит действительно может быть устойчивым и эффективным решением, особенно если он построен правильно. Тут важно понимать, что монолиты бывают разные. Например, использование DDD (Domain-Driven Design) позволяет организовать модули с чёткой изоляцией ответственности, что частично имитирует преимущества микросервисов: отдельные домены взаимодействуют через интерфейсы, минимизируя влияние отказов. Что касается производительности - абсолютно согласен. Накладные расходы на сетевые взаимодействия микросервисов могут быть значительными, особенно при сложных двунаправленных запросах. Это важный компромисс, который нужно учитывать при проектировании. Ваш пример с гибридным подходом - отличное дополнение. Такие архитектуры часто оказываются наиболее подходящими, объединяя стабильность монолита и гибкость микросервисов. Ключ в том, чтобы подбирать архитектуру не по моде, а по реальным задачам и ресурсам проекта. Спасибо за конструктивный анализ! Думаю, эта тема заслуживает отдельного видео, где я подробнее разберу и монолиты, и микросервисы, включая их гибридные варианты. Если у вас есть идеи, что ещё важно обсудить, дайте знать! 😊
@@Just-York На самом деле нужно на примерах показать где какой подход будет предпочтительнее и почему. В этом основная проблема тех, кто ищет ответ "как лучше сделать". Я в своей работе не смог пока обосновать применение микросервисов в чистом виде, даже если унифицировать стек для них. Гибрид - да, имеет применение и, как я понял, широко используется в проектах, которые изначально были монолитами, но столкнулись с проблемами масштабирования под нагрузку. Про переход с монолита на микросервисы ничего хорошего почти не слышал. Проблем становится только больше. Те же кто изначально на микросервисах всё делал, тоже не сильно удовлетворены результатами, особенно расходами на фонд оплаты труда и на поиск разработчиков под весь зоопарк технологий. У меня основной вопрос к микросервисам такой - насколько большим и какой структуры должен быть проект, чтобы микросервисы решали возникающие проблемы лучше модульного монолита или гибрида? Я пока вижу микросервисы больше как источник дополнительных проблем, чем их решение. Одно дело, если нужно какой-то супер высоконагруженный кусок проекта вынести в микросервис, написанный на том же Go, и совсем другое - использовать только микросервисы. На примере Windows, кстати, можно увидеть переход от монолита к гибриду. На сколько я знаю - они выделили ядро ОС от всего остального, получив более стабильную модульную структуру (по сути модули тут больше как сервисы организованы). Но ядро все-же осталось монолитом, пусть и похудело. Я сейчас даже не знаю как без вирусов можно убить 11ю винду чтобы она перестала работать. Я с ней уже творил всякую дичь, от которой 7я windows давно бы перестала запускаться, но 11я выживала без особых последствий (да и 10я тоже). Видно что ядру относительно не важно, когда сбоят отдельные сервисы. В принципе это можно назвать эволюционным подходом. Сначала делается базовый функционал монолитом, развивается. Случается проблема с производительностью - модуль выносится в микросервис на другом, более эффективном языке, или просто узкоспециализированным становится ради оптимизации. В итоге получаем удобство монолита и минимальные затраты на микросервисы. Если же монолит слишком сильно вырос, то можно выносить крупные более-менее обособленные группы модулей в отдельные сервисы (уже не микро, правда). Т.е. балансировать как-то осознанно между требованиями проекта. В общем - нужно объяснять не столько плюсы архитектуры, а какие конкретно проблемы с ее помощью можно решить, и какие не стоит. В каких случаях та или иная архитектура даст преимущества? И не забывать про то, что бизнесу как бы пофиг какая там архитектура, ему важно чтобы функционал дошел до пользователей максимально быстро и с минимальными затратами. А еще желательно чтобы всё стабильно работало. Вот так вот всё и сразу, ага. В общем - выбор архитектуры имеет не только технический смысл, но и бизнесовый. Именно поэтому монолиты до сих пор используются - они дешевле в моменте (а вот дороже ли они в долгую - это уже вопрос к модульности монолита) из-за того что на них быстрее разрабатывать и меньше нужно людей для этого. Если же проект успешен, то дальше уже нужно вовремя начать дробить его на микросервисы или гибрид. Опять же вопрос - как понять когда стоит начинать дробить монолит? Или как вовремя понять что микросервисы были плохим решением для проекта?
@@swayok Полностью согласен, что архитектура должна быть выбрана с учётом реальных потребностей, а не трендов. Из моего опыта, редко когда монолит распиливают полностью - чаще он остаётся, но становится меньше за счёт вынесения высоконагруженных или обособленных модулей в микросервисы. Я работал в компаниях с разными архитектурными решениями и сам строил микросервисную архитектуру с нуля. В нашем случае это оказалось оправданным: благодаря грамотному скалированию микросервисов мы добились отличного перформанса. Но вы правы, что бизнесу важен не подход, а результат. И часто архитектура требует времени на проектирование, которое не всегда легко согласовать с владельцами продукта, особенно когда им нужны фичи “вчера”.
Ни все можно разделить на множество отдельных блоков, и ни все нужно, ии ты никак не разделишь на сотню микроблоков , это будет как минимум бессмысленно, а вот сделать основной монолитный блок, к которому будут подключаться нужные функции могут реально улучшить ту самую гибкость.
@@МаксВоронін если это эффективно то пожалуйста, это тоже может быть микросервисом, например один микро сервис или модуль или ситиблок, как хотите, может полностью обработать нефтянку и выдать 4 ресурса в остальные модули
Микросервисы упрутся в свой потолок рано или поздно. На том же примере в фактории когда тебе надо не +2 фабрики по плавке метала добавить а сразу +1000 тогда у тебя не будет места и придется перестраивать остальные сервисы чтобы вместить первый. В конце концов играя в фактории уже более 1000 часов, я пришел к выводу что ситиблоки проигрывают одному большому заводу. Мощность конвеерной шины из 20+ конвейеров с 1980 предметов в секунду будет продуктивнее ситиблоков. Потому что такое количество предметов не смогут перевозить поезда и плюс это накладно. Топливо или электричество для поездов плюс размер завода с ситиблоками проигрывает одному большому
2:24 Ага, зависящие от этого другие сервисы тоже встанут. В факторке , например, если встал завод по проводам, встанет завод по микропроцессорам всех трёх тиров, заводы манипуляторов, модулей и прочее. "И никауие другие сервисы не пострадали" Монолит тоже будет так работать, если в нём нормально работает обработка ошибок.
@@serg_sel7526 а теперь представь что к тебя разные фабрики от разных источников ресурсов. Те же красные и синие схемы зачастую имеют собственное производство зеленых схем в своих блоках, поэтому если в сравнении с микросервисами каждый сити блок имеет свои собственные источники ресурсов, то проблем таких не возникнет
Ну я бы поспорил по транспорту. Как раз дроны больше похожи на API т.к. он доставляет материал (сообщение) от одного получателя к другому. Конвейер же (да и поезда) больше похожи на брокеры сообщений т.к. отправитель складываем на конвейер сообщения и на этом все, ему не важно что с ними будет, а дальше они едут по конвейеру и потребители кому надо - тот берет. Может даже никто не взять, тогда просто конвейер забьется (на топике вырастит лаг)
Спасибо за комментарий! Интересный взгляд на аналогию, и я согласен, что дроны действительно можно ассоциировать с API. В моем примере я намеренно разделил типы доставки: конвейеры сравнивал с RestAPI из-за их прямолинейного и последовательного подхода, дроны - с MessageQueue за счет их гибкости и адресной доставки, а поезда - с gRPC, где важна структурированная передача больших объемов данных. Это, конечно, упрощение, но, думаю, так легче донести основные принципы. Спасибо за интересный взгляд, он помогает углубить обсуждение!
Честно говоря я не совсем понял. В видео при рассказе о микросервисах показывают набор заводов, которые делают шестеренки, которые далее переходят в другой "микросервис", однако если завод с шестиренками перестанет функционировать, то шестерни не пойдут в другой блок, а соответственно процесс так же загнется далее по линии, если только нет дублирующего "микросервиса", но вся система в которую включен 1 этот завод получит сбой. О какой устойчивости речь? Я бы понял если бы каждая линия имела бы свою независимую подпитку ресурсов и производственную цепочку, но если они в итоге всё-равно перетекают друг в друга - значит и процесс взаимосвязан... МОжет я конешно не прав, не имею большого опыта в Факторию.
Неправда. Если вкратце, то что раньше в монолите было простым вызовом методов или функций заменяется на обращение к внешнему сервису многократно усложняя разработку, доработку, рефакторинг, поддержку. Если раньше, метод который вызываешь должен существовать, то сейчас другой сервис может быть не запущен, интерфейс не реализован или реализован по другому. В общем, если раньше у тебя в проекте многие моменты ложились на плечи компилятора, то с разнесением логики по отдельным сервисам эта способность теряется. И не стоит забывать про то, что в реальности микросервисы работают на разных хостах, а значит подвержены сетевым проблемам, функционал в них развивается по разному, а значит есть шанс поймать сетевые ошибки, поддерживать это все тяжелее, так как весь функционал разбросан по разным серверам… Микросервисной архитектурой легко убить стартап, потратив на это все кучу ресурсов, так и не начав зарабатывать деньги. Вместо того, что бы написав монолит уже быть в плюсе. Имхо, на микрсервисы можно переходить, когда у тебя уже есть работающий монолит и есть бабки на это, либо изначально большой бюджет…
5:29 согласен только с 4 пунктом. Остальные вообще не в тему. (3 с натяжкой) По ошибкам автор вообще тему не раскрыл. Абсолютно нормально, если приложение падает при ошибке. Ошибки в целом это всегда ожидаемое поведение. (Если нет, то нормально упасть) 6:55 1. Нет, конвейеры это не RestAPI. Это именно что вызов функции в рамках одного процесса. А длинный конвейер, это скорее RPC. (И то, RPC не то чтоб подходит, так как там нет контракта) 2. Дроны это скорее RPC, или тот же Rest. так как у нас конкретная передача до конкретного эндпоинта. 3. Поезда это как раз брокеры сообщений. Именно из-за работы с несколькими сервисами. Крч я думаю что базово и поверхностно это нормально, но всё равно вводит в заблуждение. Ибо начало и конец видео себе противоречат даже.
Микросервисы слабо подходят в случае, если нужна оптимизация по latency. Как-то раз мы боролись за медианную latency в 40 милисекунд и нам пришлось сливать 4 уровня сервисов в монолит. Плюс микросервисы дают оверхед в обслуживании - метрики, мониторинг, алёрты. Меньше движущихся частей, меньше проблем.
Вы путаете понятия. Монолитная система может иметь такие же выходы, как и микросервисная. То есть если вам вдруг понадобятся отдельные компоненты, то вы просто запустите соответствующий выпуск. Если вы делаете микросервис, то как бы вам не хотелось, вы уже сделали такой выход. В монолите об это нужно думать. К тому же, монолит не требует от вас ставить компоненты вплотную, не оставляя места под расширение. Ключевая разница заключается в методах доставки. Микросервисы используют неоптимальные методы, но их легко делать. В то же время монолитная система обеспечит наилучший выход, но вы будете делать ошибки, если не имеете достаточно опыта разработки. В общем это видео - это не сравнение, а просто рассказ о микросервисах. Вы даже не сказали, какие плюсы есть у монолитов в больших проектах. Опять же, вы ограничены, думая, что монолиты сложно расширять, просто оставляйте пространство и выходы
Наглядный пример илюзии выбора и держание зрителя за дурака, по факту монолит состоит из микросервисов, микросервис состоит из монолитов, а поддержке все равно разбираться потому что в конторе бардак не в тех реализации, а в управлении которое озадачено сравнением микросервисов и монолитов))
Всегда делал лапшу и буду делать! Самое оптимальное, видео что и где, а если сверху приправить лапшой из жд поездов так вообще чудо происходит, как оно работает? Да я вообще не знаю, оно работает и не лезь
"сбой одной шахты не остановит весь процесс" Так оно и в монолите не остановит. Такое ощущение что автор имеет ввиду не монолит, а некую абстрактную "базу новичка" в вакууме.
Единственная проблема монолита, что он не исполняет желания
Лучший 😊
КАК ТЫ СМЕЕШЬ ПОДВЕРГАТЬ СОМНЕНИЮ ВЕРУ В МОНОЛИТ!?!? ЗА МОНОЛИТ!
ахаха, в голосину
Ты просто не умеешь его гот.. то есть... настраивать персональную логистику
Как говорил мой первый техлид: "Если поддержка кода будет не на тебе, делай монолит и быстро тикай с проекта"
На примере фактории - это не микросервисы. Не вижу здесь ничего схожего с микросервисами, так же можно сказать что это просто набор различных асинхронных процедур не связанных между собой и использующих общую базу данных (сырье и материалы - это записи данных в БД)
Микросервис выполняется по КОНКРЕТНОМУ ОДНОМУ запросу, а не решает задачу в отрыве от запрошенного контекста. В примере на игра фактория - это показать невозможно, так как в игре нет такой специфики. Так как ролик обучающий принципам парадигмы - это нужно упомянуть, чтобы у приобщающегося адепта - было правильное понимание всей идеи.
Ага, создай микросервисы без необходимости и получи или распределенный монолит, или решай проблемы с eventual consistency. Совет тимлида раскрывает то, что он не может в архитектуру проекта и лепит лапшу.
@MrLotrus братан, ты не выкупил очевиднейшую шутку про худшее возможное поведение. Поздравляю, теперь ты очередной душнила, который душнит, чтобы душнить 😁
@@Lohmatiyshmel Для меня она нифига не очевидна, ну ладно.
@@DeadRabbitCanDance а если создать отдельные небольшие заводы в игре (работающие со своими ресурсами), это будет удовлетворять вашим притензиям? (я не в теме особенностей самой игры и какие там ограничения)
Возражу по некоторым моментам:
1. Автор на протяжении всего видео говорит от том, что монолит обязательно неустойчив к ошибкам, что падение любого компонента обязательно валит всю систему, а вот микросервисы волшебным образом автоматически становятся устойчивы к ошибкам. Но на самом деле устойчивость системы к ошибкам зависит от системы обработки ошибок, а не от топологии (монолит/микросервисы). Микросервисное приложение всё также будет падать от любой ошибки в любом сервисе, если в нём не предусмотрена обработка ошибочных ответов от других сервисов, в то время как монолит, в котором присутствуют try-catch блоки, на любые проблемные ситуации будет стабильно и корректно реагировать. Так же как в Factorio, если какое-то производство встанет, следующие за ним тоже встанут, независимо от того, как они соединены, если только не предусмотрены буферы.
2. Микросервисы не являются единственным способом разделения сложного приложения на составные части, монолитные приложения тоже прекрасно с этим справляются, разделяя приложение на компоненты (dll, jar...), а компоненты на классы/модули. Такие компоненты и классы могут быть вполне логически независимыми, их легко независимо тестировать и изменять, в том числе заменить один из них на микросервис в случае высокой вычислительной нагрузки. В Factorio аналогом будет база с главной шиной и перпендикулярными к ней блоками производств. Каждый из таких блоков можно изменять независимо от других, а если нужно улучшить производительность, а выделенного места не хватает, заменить производство на ж/д станцию, на которую привозятся ресурсы со специализированной базы.
3. Не стоит забывать и про различия между Factorio и программированием. Например, современные компьютеры очень мощные, поэтому достичь производительного лимита в монолитном приложении непросто, для этого нужно либо огромное количество пользователей, либо крайне ресуроинтенсивные задачи, такие как нейросети, в Factorio же различные боттлнеки, где, к примеру, одного конвейера уже недостаточно для транспортировки какого-либо ресурса, весьма часто встречаются. Такие ситуации в Factorio, где главная шина становится настолько широкой из-за большого разнообразия ресурсов в каком-нибудь модпаке, что пользоваться ей становится непрактично, вообще никак не ложатся на программирование, где можно в DI контейнере зарегистрировать хоть тысячу различных сервисов, что никак не затруднит взаимодействие между ними.
4. Автор говорит, что микросервисы обязательно использовать в сложных приложениях с большим количеством функционала и необходимостью иметь возможность эффективно вносить изменения (вообще, такая возможность должна быть в ЛЮБОМ приложении, мы ведь пишем SOFTware). На самом деле всё это никак не обязывает к использованию микросервисов. Если эта какая-то система учёта чего-либо для внутреннего использования в какой-нибудь компании, микросервисная топология, как мне кажется, будет тут оверинженирингом.
Я стал понимать от вашего коммента, что не до конца понимаю отличие монолита от микросервисов.
да согласен, зачем систему писать одновременно на пайтоне и на го и Java. Просто потребуется больше разных специалистов и все. А разбиение на модули это тот же аналог микро сервисов. Микросервисы делают разбиение компонентов на уровне http, а такое не всегда надо. Любая ОС это не микро сервисы, а отдельные программы exe и библиотеки, так что микросвис это один из способов распределенной системы.
Скорее микросис позволяет сделать распределенную систему работающую на разных серверах, но по сути это просто проксирование на уровне nginx. Поэтому микросервис это просто администрирование, и построение распределенной системы. Но чтоб построить распределенную систему нужны монолиты, которые в следствие могут быть объедены, поэтому если идти в глубь программирования можно изучать монолит, микросервисы это так поверхностное администрирование систем
@@-Postoronnij- Самое принципиальное отличие, что все модули что собираются в один "монолит", это те же самые микросервисы, просто теперь взаимодействуют через сетевой протокол. Принципиально ничего нового не изобретено.
@@-Postoronnij- Микросервисы - множество приложений, общающихся между собой по сети, каждое из которых можно запустить на отдельном компьютере. Монолит - единое приложение, всегда работающее на одном компьютере.
Все верно. Стабильность приложения не зависит от того - монолит это или же микросервисы. В микросервисной архитектуре хватает своих подводных камней.
Если сервисы связаны, то при отказе одного из них остальные точно так же будут простаивать. В случае большого числа экземпляров микросервисов можно вывести систему вообще в непредсказуемое состояние, если, допустим, при обновлении половина экземпляров уже новая, а половина еще нет. И многие другие проблемы. Микросервисы сложнее выкатывать (их больше), в случае проблем часто тяжелее искать причину, т.к. бывает, что невидимая ошибка в одном сервисе приводит к неработоспособности другого сервиса и приходится разматывать длинный клубок. Большие нагрузки на сеть и много чего еще. Так что стабильность, отказоустойчивость и т.д. и т.п. зависит от сложности выстраиваемой системы и правильности построенной архитектуры.
Я столько опытных людей никогда не видел под видосами про программирование. А как на примере факторио, то сразу все эксперты мира сюда пришли. Такое ощущение что все уважающие себя технари после работы (иногда на заводе), идут играть на завод
Все мои друзья играли через супер монолит - а я решил как прогер попробовать поиграть в распределенную фабрику, было прикольно увидеть +- похожие плюсы и минусы подхода)
@@maxsolodiov5245 мои друзья тоже строили монолит , всё на куче и не понятно как , а я вот сделал всё через микросервисы , видел бы ты их реакцию когда их систему пришлось расширять)
Все уважающие себя технари играют в завод, пока сидят на удаленке ;)
@@maxsolodiov5245 я играл с друзьями , они строили супер монолит, чтобы ни одного пикселя свободного не осталось , а я играл в распределенную фабрику , как ты
Было классно увидеть как они ломали голову , как бы увеличить и оптимизировать завод , а у меня он уже оптимизирован , а увеличить его можно за 2 минуты)
ВСЕГДА!!!
проблема микросервисов в том, что доменные сущности внутри них свои собственные. и поэтому обмен данными между микросервисами подразумевает такие шаги
- замапил доменную сущность источника в транспортную
- передал транспортную
- размапил в доменную сущность приёмника
таким образом у вас копится огромная туча копипасты доменных сущностей (которые с большой вероятностью будут очень друг на друга похожи, потому что по сути-то отражают одни и те же реальные объекты), но при этом скорее всего будут обрастать какими-то локальными частными особенностями, т.к. сервисы развиваются независимо (это ж постулируется как их преимущество). плюс помимо тонны копипаст "почти одинаковых но чуть-чуть отличающихся" сущностей, у вас ещё будет две тонны "почти одинаковых но чуть-чуть различающихся" мапперов "туда и обратно". и хорошо, если у каждого микросервиса будет своя команда поддержки, тогда можно сделать вид, что про другие сервисы они ничего не знают, так что "всё хорошо". но обычно поддерживать все эти сервисы приходится одним и тем же людям. вот тогда-то они и вкусят все прелести поддержки этой шляпы. вбрасывая время от времени робкое "а что нам мешало просто изолировать код в монолите, разложив по папкам. и не плодя тонны мапперов и разносервисных копий сущностей?" но это будут риторические вопросы, потому что инерция проекта и инерция команды уже не позволит ничего изменить.
В Факторио так же, с ростом ситиблока, его эфективность стремится к нулю.
копипаста - начит ошибка из первого в скором времени образуется везде и чистить её будет очень запарно
Видимо потому, что в разработке чаще принимают стратегию monolyth-first, и только потом если видят, что система разрастается принимают решение о распилке (главное, принять это решение вовремя пока не разрослось в гигантский шар грязи).
В факторио же изначально понятно, что проект в конечном итоге будет сложным. Так что сразу можно думать над "модулями". Но вот чем факторио сильно отличается от разработки, так это тем, что модули в ней физические. То есть логика жестко завязана на инфраструктуру - нет возможности потом смасштабировать каждый конкретный модуль, если заранее не заложить такую возможность😢
Если транспортный уровень доменной области выделять в отдельные подключаемые в зоопарк микросервисов (той же самой или другой доменной области) пакеты, то копипасты особо и нет. Тут скорее появляется небольшая проблема, связанная с версионностью - в пакетах крайне нежелательно делать брейкинченджи, нарушающие обратную совместимость. А именно - удалять или перемещать (remove, replace, rename) DTO, а так же удалять, переименовывать или менять тип данных у полей. Иначе после обновления пакета в сервисе - он вероятно перестанет компилироваться, если использует модели, в которых произошел брейкинчендж.
@@TimLaizaR228 Согласен с вами, работал на проекте, где как раз благодаря такому подходу доменные сущности были в целом одинаковы, правда там по сути не было "независимой" разработки. Команда всего-то из 10 разрабов была, всяких микросервисов штук 10, и пакетов к ним примерно столько вроде, при обновлении пакета, надо было пройти во все сервисы где он юзался и стянуть новый пакет, что и решало брейкинченджи по сути. Это было на заре карьеры, сейчас мне ваш вариант всё-таки кажется лучше, ведь когда реально нужны микросервисы, с большим их количеством, с большой командой разработки, проходится по всем микросервисам и обновлять пакеты путь в могилу для проекта. Как решение думаю внедрение версионности самой доменной сущности, будет условный пакет менеджер версий сущностей для этого, задача которого, в трансформации сущностей между их версиями, так что микросервис сможет принимать любую версию сущности, а наш менеджер трансформит её в версию сущности которая испольуется в конкретном микросервисе. Как по мне это решает данную проблему, но к сожалению пока не было возможности протестить такой подход на практике, так что думаю тут по любому есть какие-то подводные камни, надо как-нибудь протестить.
Объяснено прикольно, только вот применительно к Факторио есть один нюанс, самые производительные базы это здоровущий монолит особым образом спроектированный, а ситиблоки просаживают ФПС и распухает объём файла сохранения, не говоря уж про то, что половина сити-блоков обычно просто простаивает. Ничто не сравнится в эффективности с хорошо спроектированным интегрированным монолитом, просто его делать надо как положено, а не на коленке. А с микросервисной архитектурой есть нюанс и это подтверждается моим опытом, что если нет профессиональной команды и архитектора, то накладные расходы, на облачную инфраструктуру, на всякие гипервизоры и согласование работы модулей улетают просто в космос, если это легаси система, то отладка просто кошмар, если каждый микросервис в отдельном проекте висит то это всё, тушите свет, можно месяц искать причину, почему совокупное состояние системы глючит. Потому даже для матёрого энтерпрайза микросервисы не волшебная таблетка, а лучше всего работает гибрид и команда настоящих профессионалов, которые пилят проект.
Вот сразу видно, человек реально работал с микросервисами. Мы перешли от монолита к модным микросервисам и вроде всё было неплохо пока их было 10-15, но звоночки уже тогда стали поступать, а сейчас в несколько раз больше. А когда функционал всей системы всей системы всё растёт и растёт, то вспоминается старый добрый монолит, где достать до нужного модуля гораздо легче чем через цепочку микросервисов. В общем везде своих и плюсы и не менее ужасные минусы. Но иногда народ не понимает где нужно остановится и подумать верно ли выбрали итоговую архитектуру, и не гнаться за "трендом" только потому что все вокруг так делают
Но черт, как его потом тяжело перестроить)
@@andry_smith для каждого масштаба проекта есть предельный "возраст". то есть не факт, что решение, работавшее на 10-15 сервисах готово к масштабированию на 80. без рефакторинга и корректировки стратегии ни монолит ни микросервисы не могут полноценно развиваться
Микросервисы - это попытка превратить IT в конвейер. Стандарты разработки + стандарты документирования + минимальный набор функциональности на сервис позволяют обращаться с командами как с винтиками машины - рабочими на заводе. Т.е. к персоналу в этом случае применимы те же преимущества, что и к сервисам: заменимость, управляемость, масштабируемость. И, в будущем, замена AI-агентами.
@@Ainvain не знаю с чем вы встречались, но вы видели монолит в котором без документации годами не могут разобраться? а микросервисы зачастую тоже не документированы и запутаны в итоге этот AI там может только соснуть, и то промажет
Пришёл на Гайд по факторио.
Получил хороший гайд по программированию.
Спасибо.
Это хреновый гайд. чел не разбирается в вопросе, а просто насрал
Ну многие плюсы доступны и при грамотном проектировании монолита. Изолированность и независимость, но в сравнение с микросервисами меньшая масштабируемость. Я бы сказал что плохой монолит - это спагетти фабрика, а хороший - это шина. Есть лимит масштабируемости, но при этом довольно удобный и независимый, если изначально правильно спроектирован.
Холиварная тема поднята. Кое-что упрощено( я понимаю автора, сложно ужать такой вопрос в 15 минутное видео ), и из-за этого где-то спорные суждения ( как ниже было отмечено обработка ошибок зависит от системы обработки ошибок и профессионализма команды).
Я хочу добавить на мой взгляд самое главное, система строится от требований, а не для архитектуры.
Т.е. если у вас сложный но сильно связанный проект( доменная модель общая для большинства задач) - 100 раз подумайте прежде, чем ввязаться в микросервисы.
Микро-сервисы хороши там, где задачи обособленны и максимально не зависимы с чёткими API и относительно небольшой долей взаимодействия между( т.е. внутри сервисов должно быть на несколько порядоков больше логики и вычислений относительно коммуникаций). Или там где можно сделать систему в разы сложнее( и более трудной в поддержке) в угоду решения очень специфических задач ( например конвейерная обработка миллионов запросов в секунду).
Если же у вас обычное приложение ( где одна сущность может потребоваться в 20 разных местах, и требуется её взаимодействие с другими схожими объектами для реализации той или иной бизнес логики), то обычные (не микро) сервисы или монолит будут гораздо более эффективно и проще реализовать и поддерживать. Главное помнить, что монолит(или крупный сервис) не означает спагетти код и архитектурную кашу. Можно выделять либы, модули, слои, классы и пр. и жить прекрасно.
Итог, микро-сервисы это лишь инструмент в арсенале архитектора, и как любого инструмента у него есть своя область применения ( я бы сказал, достаточно узкая зато хорошо распиаренная).
Всем добра!
Хорошо все описал, спасибо!
Недооценённый комм
Натягивание совы, т.е. игры на программирование. "Добавь несколько плавилен и переделывать ничего не нужно." А место под них есть? А ресурсов в шине для работы новых плавилен достаточно? В программировании таких вопросов не встает. "Остановился сервис - ничего страшного." То есть от его работы ничего не зависит? Тогда зачем он нужен? А если зависит, то остановится не только он, но и все остальные по цепочке. Весь ролик в таком духе.
Если сервис остановится то его можно отладить без серьезных последствий для системы, и это вовсе не означает что последствий при поломке сервиса не будет никаких. Банальный пример: можно рассмотреть некий коллектив рабочих, если один рабочий не придет на работу серьезных последствий для системы не будет, в отличии от системы в которой работает всего один человек. Думаю именно это и пытался донести автор.
Потому что это больше похоже на схемотехнику, но автор упорно пытается убедить всех, что это программирование
@@mikhailm6997 В любом градостроителе с элементами автоматизации можно найти какие то паттерны проектирования на что это больше похоже каждый решает сам.
@@wastral5916 Если это инженер по тб который выдает допуск то все встанет
просто тут плохая аналогия, приведена просто потому что вот это "программирование" абстрактное, везде и всюду встречается. факторио, это больше про цифровую электронику (именно цифровую), чем непосредственно программирование. И вот с ней параллели прослеживаются очень хорошо. И шины и синхронизации, и выделение в модули, и общий абстрактный интерфейс.
Стартовать лучше с модульного монолита, потом при необходимости модуль из монолита можно будет вынести в отельный сервис.
Отель? Trivago
А какую версию чата GPT использовал для генерации основного текста? Чувствуются сильно его речевые конструкции)
По этому видео я увидел что концептуально разницы нет между микросервисом и монолитом. Разница лишь в масштабах.
В микросервисе производится один рецепт, в монолите - несколько. Сеть микросервисов - тот же монолит, с той лишь разницей, что вместо одного обработчика - группа обработчиков, соответственно большая площадь. В обоих случаях нужно думать, с какой стороны и чем выгоднее/красивее подвести входящие потоки, как соединить обработчики/их группы вместе и куда выгоднее/красивее вывести целевые и побочные продукты.
Плюс один недостаток: если у выпускаемых ресурсов будет ещё и версия, то будут проблемы совместимости при передаче ресурсов между "микро-заводами".
Зашел посмотреть какой лучше завод строить, а тут оказывается объясняют программирование на примере факторио. Расстроен, но полезно!
Хотелось бы услышать мнение DevOps на эту тему. И статистику для сравнения отказоустойчивости монолитных и микросераисных систем. И про High Availability и geographic redundancy.
Чел, ты крут❤
Понятно, что есть упрощения, но так прикольно запоминать, когда ты объясняешь на примере игры, а не на бесконечных абстракциях, которые сложно представлять.
монолит хорошо использовать на больших проектах. вместо разделения не микросервисы нужно разделять на модули. есть задачи, для решения которых микросервисы вредны. если в монолитной системе есть модуль, который не завязан плотно на другие модули, то его можно вынести в микросервис. но если модуль сильно завязаный на другие модули вынести в микросервис, то он будет нагружать сеть постоянными запросами и увеличивать задержку отклика. если попытаться решить микросервисами задачу, которая к этому не подходит, то получится куча монолитов соединённых ботлнэками.
Для этого используется DDD в монолитах
Золотые слова. Наивные архитекторы, начитавшись модных статей, забывают про связность и сцепленность, и надеются, что микросервисы - это серебрянная пуля, которая решит все беды. Но если попытаться разделить монолит на сервисы без снижения сцепленности, то получится распределённый монолит, который принесёт с собой сложности распределённых взаимодействий, но от проблем монолита не избавит.
И для исполнения желаний
Отличный и очень полезный видос! Однако меня немного смущают “беззаботные” сравнения Factorio с архитектурой софта. Позвольте вставить свои пару слов об этих прямых аналогиях.
На мой взгляд, модули и “ситиблоки” в Factorio гораздо ближе к классической инженерии, чем к программированию. Да, в игре есть аналоги модулей и чертежи (blueprints), но ресурсы и рецепты в Factorio устроены довольно жёстко: мы не можем просто подставлять переменные “на лету”, как в функциях кода. Если блок принимает три вида ресурса и выдаёт один, то он всегда работает именно так. Поэтому классический микросервис с множеством входных и выходных данных тут не приживётся.
Главный вызов Factorio - не построить саму “коробочку” (блок), а грамотно масштабировать производство, выстроить логику поставок и развести потоки ресурсов. Конечно, программистская терминология может упростить кому-то понимание структуры завода. Но в основе лежит именно инженерная задача: как эффективно соединить производственные цепочки и управлять ими на больших масштабах (проблема “мультиплексирования”). Чаще всего приходится думать не только о том, куда поставить блок, но и как подвести к нему конвейеры, или организовать перевозку дронами и поездами или ракетой. В мире микросервисов эти вопросы решаются через сети (TCP/UDP), а тут - через реальную логику перемещения материалов. И это, на мой взгляд, принципиально иная парадигма.
Выражаю автору огромную благодарность! Мои вопросы актуальные закрыты, а я всего лишь 2 месяца в программировании.
Супер идея и гайды. Благодарю.
Единственное нужно добавить какой-нибудь словарь терминов для совсем нулёвых в теме.
Осталось теперь к рассказам и практике на игре добавить перенос этих конструкций в код )) Тут уже целое обучение делать можно
Спасибо за комментарий, добавлю под видео словарь терминов.
а можно все механизмы так объяснить, на примере фактории?) Про брокеры, про протоколы, про архитектурные паттерны всякие.
К микросервисам, по мне, в основном приходят когда в монолите ресурсов уже не хватает (цп, память, диск), и нужный процесс выносят в микросервис. Так же, туда выносят элементы и бизнес процессы, которые не должны сбоить. Если монолит начнут ддосить, его сложно прикрыть без потери доступа к сервису, а вот микросервис можно оставить доступ только авторизованным пользователям (в монолите наверное тоже можно, но с учетом ширины функционала, может быть трудно ввести без внешних систем).
Ну и legacy монолит удобно разбивать на микросеовисы, да, по тихоньку превращая его не в legacy, условно перенося код из php в python.
Всегда все зависит от бизнес требований. Если вы только начинаете работать, то создавая микросервисы вы должны понимать потяните ли его обслуживание и стоимость ведь это разные специалисты, зависимости, языки, опыт, серверная конфигурация. Готовы все это организовать грамотно? Если нет - сделайте монолит, потом постепенно переписывайте на сервисы.
Код всегда можно переписать было бы желание и необходимость.
В то же время если вы понимаете, что какая-то часть функционала полностью самостоятельна и при этом будет использована в каких-то других подпроектах то именно этот функционал можно вынести в сервис и общаться с ним с основным приложением. То есть делаете придожение так, чтобы оно выполняло задачи.
Например: стоит ли делать сложный магазин как микросервис? Нет, скорее всего нет.
Стоит ли делать сложный магазин у которого есть индивидуальная реклама с сложными алгаритмами расчета, аналитическая система прожаж и логистики, административная панель селлера, финансовые и рекламные инструменты и все это под единным аккаунтом? Да, вероятно стоит, как минимум сервис авторизации стоит вынести в сервис, а остальное по ситуации либо выносить позже, либо делать соазу сервисом если для выполнения задач оптимальне использовать другие языки.
За научпоп спасибо! Думаю тем кто еще не сеньор будет проще понять все, особенно типы взаимодействий в микросервисной архитектуре, тут с конвейерами дронами и поездами на мой взгляд просто супер! )
Ну и добавлю немного, на мой взгляд, по наблюдениям при прочих равных монолиты справляются обычно быстрее чем микросервисы. А по остальным спорным аспектам, то тут можно спорить и до цифры когда забыл поставить условие выхода из бесконечного цикла) Здесь допустим набежало довольно много программистов, а ведь по отказоустойчивости можно и пойти к девопсам, чтобы k8s накатили отказоустойчивый на каждый модуль и т.д. )
Как-то раз собрался дед готовить репу,
Вокруг все собрались, смотрят на него свирепо.
Мышка говорит: "Да ну, это ж монолит,
Будешь так готовить - нам Жучка не простит".
Жучка гавкает: "Давай разобьём на атомы,
Там сделаем по красоте и будем пионерами.
Я читала книжку тут по архитектуре,
В Америке такие движки двигают в натуре".
Бабка принесла из сарайчика ружьё,
Деду говорит: "Отойди, ё-моё".
Жахнула по репке, и разлетелась репка,
Жахнула метко, не осталось даже щепки.
Внучка говорит тут: "Эй матери мать,
А как же нам теперь всё это собирать?"
Глаза все опустили, не смотрят на деда,
Пришло в русском стиле время обеда.
Случайно наткнулся на это видео, как раз планирую начать изучать Go. Несмотря на то, что ни когда не играл в Factorio, очень доходчиво рассказал о микросервисах, спасибо.
На самом деле очень плохо рассказал, тут сплошником подмена понятий и искажение фактов.
Забудь все что услышал тут. Иначе тебя ждет куча проблем. Лучше почитай комментарии, там уже давно расписали что есть что
Прикольно ты придумал рассказывать. И понятно и интереснее, чем просто монолог слушать
классное видео. спасибо за труд!
подними тему монолит/микросервисы, тут же куча умников скажет тебе, что ты нихрена не шаришь. Классика)
в комментах много "возражений", которые по сути повторяют те же тезисы, но с посылом, что автор ошибается
внесу свою лепту))
аналогии взаимодействия МС перепутал:
REST - дроны (синхрон, пока дрон не вернется он не понесет след. ресурс)
MQ - конвеер (ассинхрон, кладешь ресурсы сколько сможешь, ограничение лишь в самом конвейре)
Спасибо за добрые слова и за вклад в обсуждение! Рад, что тема вызвала такой интерес, даже если мнения порой противоположные. Твоя аналогия с REST и дронами действительно логична, как и сравнение MQ с конвейером - отличный взгляд! Я выбрал другие сравнения, чтобы подчеркнуть разные аспекты взаимодействия, но твой подход тоже отлично объясняет эти концепции. Такие обсуждения только обогащают тему, так что спасибо за участие!
Вот это интересно, интересно)
Спасибо за видео )
Chat-gpt попросил описать плюсы и минусы архитектур на примере игры. Молодец
Судите сами, выражу специфическую мысль: лучший аналог в рамках сравнения - онлайн-игра, где каждый игрок строит свою собственную базу как пожелает и независимо (возможно, находясь вообще на разных планетах). Но вместе они - команда, где каждый заточен на своей специфике и том, что ему нравится больше всего. Они завязаны на общий ход событий, имеют договорённости (а-ля квесты). По типу: "с заданным периодом к такому то сроку передать туда-то и туда-то такие-то ресурсы".
В итоге это всё может вылиться в такой себе набор блэк-боксов, где самое прозрачное - это стандартизированный метод коммуникации. Это в игре. А в реале всё с точностью до наоборот)))
Пока не дочитал название до Factorio думал что видео про микроэлектронику🤣
Во время обьяснения вспомнил когда играл в Mindastry и както накосячил с поставка креогеной жидкости на импульсный реактор
Ну просто гениальная подача материала, лайк, подписка, честь и хвала.
Я не умею программировать, но мне все стало понятно)
Автор, спасибо)
Это печально. Так как понять бред это значит наполнить голову мусором. Не сказать что все что говорит не верно, но и правдой это ни как не является. Возможно стоило бы тут писать кучу текста в оправдание моих слов, но благо за меня это уже сделали ребата в комментариях. И почему автор решил строить свои объяснения на факторио при том что она оказалась не пришей кобыле хвост...
В программировании, если ты думаешь, что понял, то обычно это означает, что ты нихера не понял, либо тебе объяснили оч поверхностно
В Факторио ситиблоки очень неэфективная организация производства, производственные блоки простаивают более 50% времени, так как поезда не могут обеспечить непрерывность прозводства. Основная задача поездов, это обеспечение работоспособности удалённых производств, всё остальное это просто "костыли". Так что поезда можно сравнить с последовательной однопроводной шиной, как "one wire" и ей подобные. Ситиболки же похоже на попытку решить сложную вычеслительную задачу с помощью кластера ардуинок уно, что само посебе выглядет бредово, и это при наличи специализированных вычеслительных машин.
Ситиблоки это очень классная система когда ты не хочешь думать а идешь по пути копипаста. Тоесть твоя задача натыкать подобное на подобное и получить некий результат, а позже соединить все в одну систему. Ааа и еще ситиблоки круто смотрятся на видео роликах))
в смысле " поезда не могут обеспечить непрерывность производства" это как вы так строите ? что не могут. у меня ситиблоки и поезда загружают склады под крышечку. Если ваш сити блок вдруг съел все ресы из склада потому как их не успели подвести паровозы то будете добры поставьте 2-ую станцию или третью и так далее.
@@drjonn да, только это система на переизбытке добычи и недостатке переработки. Что по факту напраская трата ресурсов (на строительство). Если же у тебя обработка будет равна добыче или больше, то обработка будет простаивать в ожидании пока привезут новую партию... и бла бла ... фактически нынешнее программирование очень похоже на ситиблоки, когда расход ресурсов на систему куда больше чем нужно для выполнения задачи, ибо так проще так легче. В итоге куча неоптимизированого ПО которое жрет ресурсы нещадно... Ситиблоки это про эстетическую красоту и простоту, но с перерасходом ресурсов...
@@Fant0m95 ну соглашусь но только частично. Дело в том что я строю добычу как и расход строго на основании пропускной способности конвейера. (30 предметов в сек).( и просто масштабирую при более крутых конвейерах) И цепочка включающая в себя паровоз с парой вагонов у меня ее никогда не задерживала.
А что касается программирования то да есть там такая тенденция с неоптимизированным кодом. Но тут виноваты слишком мощные компы (я ушел от программирования в инженерию на изломе века так что мои познания заканчиваются на бейсик, паскаль, ассемблер где частенько оптимизировать код весьма сложно. он уже достаточно плотный) там можно только оптимизировать целиком блок-схему.
@@drjonn А вот тут я точно не соглашусь. Проблема не в мощных копмпах, а в том что к ресурсам нынче относятся наплевательски. Где это видано чтобы выходила игра и самое мощное железо на рынке, 4090 уже не могла играючи его вытягивать ... И мы переходим в гонку когда браузер забивает 8ГБ оперативы кучкой говноОдностраничников с кучей анимаций и вылетающей дребедени, когда кто-то давнавато кричал 640КБ хватит всем )) и под это все штампуют железки чтобы хоть както выдерживать потоки говнокода и великие труды миллиона полигонов на песчинке))) накипелов)
как то в общем всё, хочется на конкретных задачах в факторке. А то по сути единственный выход - это ситиблоки ставить, которые уже надоели, все друг у друга копируют их и радуются
Ну не сказал бы, есть же ведь ещё суши белт. Но сити блоки действительно удобны достаточно как ни крути, особенно с появлением дронов
@maks201490 да, но творчества ноль. Все одинаковые и не думают головой
Общо всё, потому что тут задача объяснить была принципы микросервисов, а не подать идеи для факторио. Если честно, к факторио конкретно то что автор описывает в качестве различий между монолитом и микросервисами впринципе не очень применимо, ибо что при модульной проектировке от того, что навернётся один модуль у тебя могут встать все соседние, что в монолитном производстве встанет только то, что зависит от конкретного ресурса, а то что не зависит - продолжит работать(не рассматриваем электроэнергию, потому что она в любой архитектуре одинаковую роль играет). Ну и в факторио основной фактор выбора архитектуры это "пропускная способность" в широком смысле, т.е. ты оптимизурешь производство исходя из того, как наиболее эффективно ты сможешь ресурсы доставить, потому что у тебя всегда задача получить n ресурса за t времени. В разработке такие задачи конечно бывают, но всё же данные принципы немного о другом
А по поводу того, что сити-блоки надоели - просто не копирайте у других и думайте сами. Сити-блок это архитектурный принцип, что в Сити-блоке будет содержаться и как он будет организован/оформлен зависит только от вас. Ну и да, никто не мешает играть вообще без сити-блоков, стройте чисто на поездах обеспечение, стройте дрон-цеха. Если вам кажется , что всё перепробовали, поставьте себе какой-то сценарий или попробуйте модификации типа красорио или боб+анджел - поверьте, все устоявшиеся схемы придётся пересмотреть.
Хе. Я пока играл в Shapez 2 решил попробовать новый принцип: спагетти блоки.
По сути это те же сити блоки, но они имеют самые разные формы и размеры, а внутри делаются несколько продуктов (или они используются как проходной двор для других сити блоков, стоящих вплотную). Также иногда я облеплял такими блоками один крупный вокзал, чтобы не делать каждому блоку зону погрузки и разгрузки. Получается интересно и эффективно, но спроектировать такое сложно, а работает всё очень запутанно и лучше лишний раз систему не трогать.
Допустим сделали ERP на микросервисах. Каждый микросервис имеет свою базу данных. Производство и одном микросервисе, Склад в другом, Поставщики в третьем и т.п. Получаем сто-пятсот изолированных баз данных по котором разбросаны части единой по сути информационной системы. И вот нужно составить запрос использующий и товары, и поставщиков, и продажи, и лояльность, и налоги, и еще что. В монолите это будет один SQL запрос к единой БД. А что будет в микросервисах?
По хорошему в микросервисах будет брокер сообщений с историей операций по добавлению и изменению этих сущностей. И будет отдельный микросервис для аналитики, агрегирующий эти данные у себя в базе в широкой таблице. В результате будет тоже один sql запрос, причем даже без джоинов. Один нюанс - это всё ппц какой оверхед по сравнению с монолитом. И вот такие видео вводят людей в заблуждение, что почти всегда надо выбирать микросервисы. Тогда как наоборот, почти всегда достаточно монолита и может ещё несколько отдельных вспомогательных сервисов.
А как вы подразумеваете получить все эти данные одним запросом к БД? Вроде же и нужно делать несколько запросов для каждой таблицы, иначе получается каша.
Кстати использовать NestJS и drizzle вроде гарантирует выполнение только одного запроса.
@@я-думаю-наверное джоинить данные из этих таблиц.
@@я-думаю-наверное Какая именно orm или её отсутствие неважно. Всё в конечном счёте будет сформировано в SQL запрос.
Лайк за тему Дизлайк за содержание. Плюсы монолита:
- меньше точек отказа (главное)
- меньше ресурсов затрачено
- легче сопровождать (с точки зрения бизнес логики)
- меньше абсолютное время сбоя.
Плюсы микросервисов:
- меньше влияние от сбоя (один сервис не тянет за собой все)
- больше вариантов для беспростояного деплоя.
- маленький объем самого сервиса позволяет легко его контейниризировать и управлять из под оркестратора.
- следствие последнего легко масштабировать.
Сказано только 3 основных тезиса в видео. )))
Спасибо за комментарий! Ты абсолютно прав насчет плюсов микросервисов и монолита. На примере с Factorio не удалось показать все аспекты - часть была намеренно упрощена, чтобы сделать объяснение понятным для людей, которые только начинают разбираться в теме.
С наступившим новым годом, классный ролик,
Нужен совет, с чего начать разработку проекта, если первая попытка разработки планируется соло? Но однозначно на микросервисах
Спасибо! Если соло, то точно монолит.
крутой видос, спасибо, хорошо объяснил)
Можешь сделать про паттерн синглтрн на примере фактории)?😊
Все круто 😎 вопрос, есть чертежи в общем доступе?
часть брал из factorio.school часть сам делал
Одна из причин почему так тяжело понять принцип работы мозга. Вроде как есть микросервесы, но... Фифти фифти. Соеденены они методом спагетти и могут замещать функции другу друга
Так это эволюционная фича в мозге многие вещи дублированы многократно
По автору: Красавчик) 2 архитектурных решения очень простым и понятным языком. Тут очевидно лайк👍 за знания и за очень понятный контент!
Немного по микросервисам:
Ты сказал что для разработки и поддержания микросервисов нужна комманда разработки. Но на самом деле всё зависит от аппетитов, может и хватить одного)
Немного по монолиту:
По сути это первое решение каждого разработчика в начале карьеры. Тут факторио и разработка сплились воедино)
Так как в факторио никто не начинает с ситиблоков, до них нужно дорасти)
зачем нужен такой микросервис если от его остановки ничего не проходит и ничего от него не зависит?
Отладку в монолите так же можно делать отдельно, разбей на библиотеки.
В микросервисах накладные расходы на связь между сервисами иной раз совсем уже неприличные. Как и в факторио появляются задержки на поезда, загрузку/разгрузку.
Итог - надо писать под задачу, не бывает универсального решения. Как и в факторе - если ошибся в планировании - начинаются проблемы с масштабированием и исправлением ошибок.
Да, разбивать монолит на библиотеки - это рабочая штука, особенно если всё грамотно организовано. Но микросервисы дают ещё один уровень изоляции - если один сервис падает, остальные продолжают работать. Накладные расходы на связь - согласен, это боль. Но когда всё настроено правильно, масштабируемость и независимость всё равно выигрывают. В любом случае, ты прав - планирование решает всё, и универсального подхода тут точно нет. Всё, как в Factorio: ошибся в планировании - потом разгребай!
Здарова, запилишь ролик про патерны проектирования? думаю будут очень полезны
Я лично строю что то между сервисом и монолитом. А вот с логистикой я пытаюсь расчитать логистический вес компонента (т.е например если нужны шестерни то выгоднее возить вагон шестерней чем плиты тк вес 1 шестерни это 2 плиты) фактически можно построить огромный молл и возить с него только нужные компоненты на ту же науку при этом расширить молл будет не сложно тк я сейчас занимаюсь разработкой универсального умного молла который будет сам выбирать себе рецепты в зависимости от задач на фабрике, правда вылезают артефакты с логическими сигналами но думаю оно того стоит например копирование сигналов после их отсечения на другие сборщики. (молл будет на дронах а базовые детали будут производится вне молла что бы снизить нагрузку на сам молл и дроны только потому что они позволяют ускорить производство через удобное размещение максимального колличества маяков на сборщик и имеют дичайшую пропускную способность на близких дистанциях)
@@The_Rifach уже видел в библиотеках чертежей такие молы, выглядят забавно
В факторио лучше построить жд сеть в крупную клетку. Затем одну базу-строителя. Ее функция - молл для производства всех предметов без производства науки. Затем при накоплении ресурсов строить базы, производящие из первичных ресурсов только науку, причем лишь 1-5 каждой из банок в секунду. У и лаборатории для них.
Смысла нет строить супер производства, например, синих схем, в одном месте. Будут постоянно пробки из поездов.
Я конечно не эксперт и в факторио даже не играл, но моя теория состоит в том, что пока вы думаете, что проэктируете микросервисы, в действительности вы просто строите монолит, в некоторой степени модульный, с собственными процедурами и функциями.
Система располагается в "физическом" пространстве и её "микросервисы" и шины не могут в полной мере быть бесконечно масштабируемы. Проектируя систему вы НЕ можете полностью игнорировать вопрос взаимного расположения заводов и шин на игровой карте. Таким образом размывается единственное значимое различие в терминах микросервисы/монолит.
О пародии на микросервисную архитектуру можно было бы рассуждать, если бы: карта была бесконечная, в любой точке карты возможна добыча абсолютно всех видов ресурсов в одинаковых и бесконечных количествах, здания заводов не ограничены по высоте (следовательно, могут расширяться бесконечно вверх), все связи осуществляются не по наземным шинам, а по средствам дронов.
Не знаю, может так дело и обстоит, но мы никак не уйдём от: фактора взаимного расположения зданий заводов на карте, а следовательно, времени связи между сервисами и невозможности бесконечного расширения оснований заводов, рано или поздно соседние заводы при расширении коснутся друг друга, поэтому в начале разработки придётся рассчитывать приемлемое расстояние между заводов, что на мой взгляд противоречит концепции микросервиса, как единицы системы, а именно: независимая от других микросервисов возможность масштабирования.
Ооо отлично, раньше не знал как эффективней, ты объяснил, спасибо
Ну, в факторке я сначала делаю монолит до открытия поездов, убираю часть монолита, чтобы максимизировать производство поездов, а потом перехожу на сервисы
У меня 3.5 года опыта в Backend разработке и 0 опыта в Factorio. Было очень интересно и забавно смотреть видео гайд по factorio через разработку, кек
Очень круто, спасибо!
Про вебсокеты есть видеопримеры?
@@mr.medrano2833 пока нет
Если уж и брать факторио, то базу по шине нужно изначально расчитывать на н-ную производительность, и в рамках ее и происходит расширение, когда ты доходишь до рамок ты берешь и делаешь новое отдельное производство а не пытаешся глобально менять базу с шиной . А в итогемы имеем стартовую базу шине, а потом только ситиблоки (хотя базу на шине тоже можно ситиблоком сделать, но это извращение как по мне)
Вполне хорошее видео теперь я всем это видео покажу
Модульность. Можно копировать блоки и ставить блоки если есть нехватка чего то. Что абсолютно не работает на Глебе. На Глебе придётся сначала сделать биокамеры в нормальном количестве и только потом приступать к строительству завода по науке и причём нельзя сделать поэтапно, придётся сразу делать одновременно.
Даже SOA - это кратное усложнение системы и дополнительные операционные расходы, которые должны быть чем-то оправданы. Про микросервисную архитектуру вообще молчу: 99% проектов и компаний в принципе никогда не дорастут до тех масштабов, когда это по-настоящему нужно. Проблема менеджмента в том, что они практически всегда недостаточно хорошо разбираются в проектировании и разработке и легко ведутся на такие эксперименты от не совсем компетентных архитекторов, которые не понимают, что делают.
Микросервисы удобны, но проблема в том, что с ними у тебя тратится значительно больше места, что увеличивает периметр обороны, что требует ещё больше ресурсов и их оперативной доставки. Плюс к тому главная шина становится прям неоправданно огромной. Тебе нужно, допустим, всего в одно место довести зелёные электросхемы, а ты ради этого продлеваешь четырёхполосную шину с этими электросхемами, да и все остальные продлеваешь. И получается что ты помимо самого микросервиса ещё потратил вдвое-втрое больше пространства, вместо того, чтобы построить этот "микросервис" где то поблизости от производства и провести адекватный конвейер.
Как по мне микросерсисы это прочвления принципа разделяй и властвуй. В любом проекте кодом данный концепт работает хорошо, человеческий мозг довольно ограничен в реурсах и возможность сделать цепочку действий позволяет ему лучше думать и понимать что происходит.
Но это происходит и в хорошем монолите и в микросервисе.
Вопрос наверное больше в связности и скорости выявления ошибок. Система микросервисов имеет огромное количество разных модулей которые (в идеале) не влияют друг на друга никак, кроме как вызов и обмен данными, те если баг возник в одном микросервисе то другой просто будет работать как есть и делать все как надо.
Но черт возми от парадокса связности мы не избавимся. Как бы мы не раздвигали острова нашей абстракций по итогу все равно есть шанс что предыдущий сервис выдаст неверные данные а вся остальная цепочка обработа неверные данные...
В целом это бесконечный легбез. Делай слишком мальенькое ты увязнешь в болоте. Делай большое и оно тебя задавит, а в реальности выигрывает балансные решерие. Когда несколько монолитов построили микросервисы (((;ꏿ_ꏿ;)))
Ну понятно, теперь каждая планета это монолит но вместе они микросервисы в масштабах всей игры...
1:34 Фз, всё время делаю +- 1 гигансткий. С поправкой на то, что переплавка металлов, никак не контачит с нефтянкой.
1:49 Опять же, фиг знает. Я всегда оставляю пространство, чтобы линию можно было продлить или расширить ещё на 2 - 3 потока.
Нет, есть в начале игры, небольшие "местячковые" производства. Но они обычно живут, до момента открытия электропечей. А потом я делаю полосы производств, с отступами сверху/снизу/в сторону, чтобы было куда расширять и где прокинуть дополнительные конвейера.
1 конвейер, через всю базу - это проблема моего напарника, по игре. постоянно ему объясняю, что с таким подходом, его возможности - сильно ограничены. Но уже 3 игры подряд, он так делает и ему норм.. Хотя у меня тоже бывает длиннющий конвейер. Правда он идёт не через базу, а вокруг неё. Пока нет лазерных турелей или хотя бы огнемётных - пускаю один красный конвейер, чтобы снабжать пулемётные турели, вокруг всей базы😅🤷♂
Микросервисная архитектура никогда не предназначалась и не предназначается для решения технических проблем.
Главная проблема, которую решают микросервисы - организация больших команд и разделение между ними ответственности. Например если у вас в монолите авторизация нагружает систему настолько, что её обслуживанием занимается несколько человек - имеет смысл выделить их в отдельную команду, авторизацию - в микросервис и полностью передать им ответственность за него.
Цена, которую за это придётся заплатить - дополнительная сложность. А т.к. сложность всегда растёт экспоненциально - сложность монолита и этого же монолита, разбитого на микросервисы будет различаться в разы. Что потребует соответствующего бюджета на поддержку.
Рассуждения автора о преимуществах микросервисной архитектуры не имеют никого смысла. Любые задачи можно решить обоими способами. Выбор между ними - вопрос организации команды. Если вам дали команду из 5 сеньоров - пишите монолит, что-то тяжелое всегда можно выделить в отдельный сервис. Если вам дали команду из 30 джунов - делите их на мелкие группы и выдавайте каждой по сервису. Т.к. монолит они все равно запроектировать не смогут, а так те косяки, что они наделают будут изолированы в их микросервисах.
Спасибо за такой развёрнутый комментарий! Согласен, микросервисы действительно часто выбирают для упрощения организации работы больших команд, и их внедрение действительно добавляет сложности. Но я бы не сказал, что технические аспекты совсем не играют роли. Микросервисы дают больше возможностей для масштабирования, изоляции ошибок и независимых обновлений - это может быть критично в высоконагруженных системах.
Ты прав, что задачи можно решить обоими способами, и выбор архитектуры зависит от контекста. Я делал акцент на преимуществах микросервисов, чтобы показать их потенциал в подходящих ситуациях, но полностью согласен, что без грамотного подхода это может создать больше проблем, чем пользы. Спасибо за интересную точку зрения!
очень наглядно и понятно, отличный выбор аналогии
Чувствую себя гением, что сам до микросервисов добился играя в Сатисфактори, еще и шину огромную сделал до того как узнал рро неё, ещё и с буферами и складировкой
Толково для меня, нуба в программировании, изложено, респект.
🤔 а если мне нужна большая програма для упрощения програмирования для себя?
Просто локальная програма на с++.
Типа продвинутий блокнот с автоматическими кнопками для кодинга и другое.
Зачем c++? Это долго. Возьми nodejs и tauri например, сэкономишь кучу времени, ты ведь не драйвера пишешь
Все правильно но по аналогии сити блоки ну очень затратны по ресурсам. (примерно раза в 3-4) против монолита.
С другой стороны если работников несколько то монолит строить не получается. даже в 2 хорошо понимающих друг друга игрока. Приходится строить микросервисы.
как и программировании. если пишешь код в одиночку (ну до 5 человек) то однозначно выходит монолит. а если вас несколько ( больше 10) то только микро сервисы.
ЗА МОНОЛИТ!
короче если у нас бесконечная память и большой временной допуск - выбираем микросервисы. если нужна скорость и занимаемое место - монолит
Ключевая фраза "если не планируется расширение/масштабирование". Всегда нужно закладываться на то что в процессе разработки/эксплуатации заказчика понесет и он захочет ещё много чего за что готов платить, а менеджмент будет кивать головой и говорить "да без бэ.."
Что сказать? За Монолит, братья!
Можно ли делать системы из огромного количества монолитов?
Да
Да, мой проект такой
Частично не согласен. Озвучены исключительно плюсы микросервисов и минусы монолита. Микросервисы точно так же подвержены каскадному отказу, как и монолит, но вот исправить проблемы бывает куда сложнее т.к. из-за "плюса" в том, что микросервис может быть написан на любом языке и любом инструментарии, исправить его может только тот, кто этот язык и инструментарий знает. Не получится попросить Java разработчика срочно исправить микросервис на Go. Даже если джавист имел ранее дело с Go, ему потребуется много времени чтобы разобраться в коде и найти ошибку т.к. когда падает микросервис, то ошибка скорее всего оносительно сложная. И после того как микросервис поднят обратно, то точно так же, как и для монолита, нужно запустить тестирования всего проекта, т.к. далеко не факт что исправление не порушило что-то где-то еще. Даже если все тесты сервиса проходят успешно (как минимум одну проблему уже не протестировали, значит тесты не покрывают все ситуации). На примере факторио - у вас отказал сервис производства угля. В итоге откажут сервисы производства стали и все остальные, которые зависят от угля и стали. Т.е. потенциально остановится вообще всё. Плюс в факторио в том, что язык и инструментарий унифицирован и достаточно просто это найти и исправить.
В реальности же, если не унифицироан набор языка и инструментария для микросервисов, то проблема отказа куда сложнее и дольше решается чем в монолите.
Далее - производительность микросервисной архитектуры не настолько высокая как заявляется. Из-за того что общение между сервисами производится по сети - возникают значительные задержки на выполнении задач, которые требуют взаимодействия между сервисами. На примере факторио это сложно показать т.к. тут принцип построения прямолинейный (произвел, отправил, забыл), а в приложениях он двунаправленный (получил запрос, обработал, отправил ответ обратно). Т.е. накладные расходы растут по мере увеличения количества микросервисов. В итоге как бы один микросервис не был хорошо оптимизирован, вся система не получит от этой оптимизации никакой выгоды из-за того что общение по сети намного менее эффективно чем в монолите.
Ну и обслуживание зоопарка микросервисов - это тоже своего рода проблема. Причем достаточно затратная для бизнеса.
Я к чему веду: микросервисы - далеко не идеальный принцип построения реального приложения. У него так же есть ощутимые минусы и далеко не всегда правильно построенный монолит проигрывает микросервисам хоть в чем-то.
Про проблемы монолита. То, что вы строите в факторио в начале игры (если вы относительно новичок) - это не монолит, это х.як-х.як и в прод. По сути это минимально жизнеспособный продукт, задача которого проверить конецпцию и первоначально настроить проект и протестировать его. В реальности же монолит - это модульная система, где каждый модуль отвечает за свою задачу и обращается в другие модули, если это требуется. Ничего не напоминает? Модули при этом написаны на одном языке и инструментарии. Правильно построенный монолит достаточно устойчив к точечным отказам и не роняет всю систему из-за отказа в одном из модулей. Всё, что не зависит от отказавшего модуля будет продолжать работать. Сложно ли найти проблему? Нет, логирование ошибок настраивается на ранних этапах проекта и почти всегда можно найти ошибку по логам. А если ошибка связана с "поведением", а не просто "упало", то искать нужно в конкретном модуле или модулях, которые с ним связаны. При этом это может сделать любой разработчик, который работал на проектом т.к. язык и инструментарий для всех одинаков. Тестирование, да, нужно проводить полное, но это в большей мере решается автотестами и специальными сотрудниками (QA). Кстати, тестирование монолита проще организовать чем в микросервисах, особенно когда нужно тестировать весь проект. Да и вообще любой релиз должен проходить полное тестирование, даже в микросервисной архитектуре. Релизить с надеждой что при изменении одного микросервиса не посыпятся остальные - такое себе.
А если пойти дальше, то найдется еще гибридный подход, где есть монолит и микросервисы одновременно, получая преимущества обоих подходов только там, где эти подходы наиболее эффективны.
В общем - любой инструмент может привести к печальному результату, если его неправильно использовать. И цена ошибки при выборе архитектуры может быть очень высока для бизнеса. Слепо выбирать трендовую архитектуру, не понимая её плюсы и минусы - это как играть в рулетку. Может быть и повезет, а может и нет.
Одного идеального решения нет. Под каждый проект нужно подбирать наиболее подходящее решение. И оценивать не только по архитектуре, но и по затратам на использование выбранной архитектуры т.к. проекты должны в первую очередь быть прибыльными, а не проедать деньги на неправильно выбранной архитектуре.
Кроме материалов, которые восхваляют конкретную архитектуру/язык/инструментарий нужно так же искать материалы, которые жестко критикуют их. Так можно понять подходит ли оно к проекту или нет. И какие могут быть проблемы в процессе разработки и какие есть решения для этих проблем.
Спасибо за развёрнутый комментарий! Вы абсолютно правы, что микросервисы не идеальны, и я старался это показать, хотя мог не подчеркнуть все аспекты. Ваши замечания о каскадных отказах, сложности устранения ошибок и затратах на обслуживание полностью обоснованы. Микросервисы действительно могут усложнить поддержку, особенно если используется разнородный стек технологий.
Однако стоит отметить, что компании, которые выбирают подход с микросервисами на разных языках и инструментах, обычно понимают все связанные риски. Такой выбор предполагает наличие сильной команды и процессов, которые минимизируют задержки в устранении проблем, включая грамотный CI/CD, логирование, мониторинг и тестирование. Это сложнее, чем унифицированный стек монолита, но те, кто идут этим путём, знают, на что подписываются.
Я также освещал как плюсы, так и минусы обоих подходов. Монолит действительно может быть устойчивым и эффективным решением, особенно если он построен правильно. Тут важно понимать, что монолиты бывают разные. Например, использование DDD (Domain-Driven Design) позволяет организовать модули с чёткой изоляцией ответственности, что частично имитирует преимущества микросервисов: отдельные домены взаимодействуют через интерфейсы, минимизируя влияние отказов.
Что касается производительности - абсолютно согласен. Накладные расходы на сетевые взаимодействия микросервисов могут быть значительными, особенно при сложных двунаправленных запросах. Это важный компромисс, который нужно учитывать при проектировании.
Ваш пример с гибридным подходом - отличное дополнение. Такие архитектуры часто оказываются наиболее подходящими, объединяя стабильность монолита и гибкость микросервисов. Ключ в том, чтобы подбирать архитектуру не по моде, а по реальным задачам и ресурсам проекта.
Спасибо за конструктивный анализ! Думаю, эта тема заслуживает отдельного видео, где я подробнее разберу и монолиты, и микросервисы, включая их гибридные варианты. Если у вас есть идеи, что ещё важно обсудить, дайте знать! 😊
@@Just-York На самом деле нужно на примерах показать где какой подход будет предпочтительнее и почему. В этом основная проблема тех, кто ищет ответ "как лучше сделать". Я в своей работе не смог пока обосновать применение микросервисов в чистом виде, даже если унифицировать стек для них. Гибрид - да, имеет применение и, как я понял, широко используется в проектах, которые изначально были монолитами, но столкнулись с проблемами масштабирования под нагрузку. Про переход с монолита на микросервисы ничего хорошего почти не слышал. Проблем становится только больше. Те же кто изначально на микросервисах всё делал, тоже не сильно удовлетворены результатами, особенно расходами на фонд оплаты труда и на поиск разработчиков под весь зоопарк технологий. У меня основной вопрос к микросервисам такой - насколько большим и какой структуры должен быть проект, чтобы микросервисы решали возникающие проблемы лучше модульного монолита или гибрида? Я пока вижу микросервисы больше как источник дополнительных проблем, чем их решение. Одно дело, если нужно какой-то супер высоконагруженный кусок проекта вынести в микросервис, написанный на том же Go, и совсем другое - использовать только микросервисы.
На примере Windows, кстати, можно увидеть переход от монолита к гибриду. На сколько я знаю - они выделили ядро ОС от всего остального, получив более стабильную модульную структуру (по сути модули тут больше как сервисы организованы). Но ядро все-же осталось монолитом, пусть и похудело. Я сейчас даже не знаю как без вирусов можно убить 11ю винду чтобы она перестала работать. Я с ней уже творил всякую дичь, от которой 7я windows давно бы перестала запускаться, но 11я выживала без особых последствий (да и 10я тоже). Видно что ядру относительно не важно, когда сбоят отдельные сервисы.
В принципе это можно назвать эволюционным подходом. Сначала делается базовый функционал монолитом, развивается. Случается проблема с производительностью - модуль выносится в микросервис на другом, более эффективном языке, или просто узкоспециализированным становится ради оптимизации. В итоге получаем удобство монолита и минимальные затраты на микросервисы. Если же монолит слишком сильно вырос, то можно выносить крупные более-менее обособленные группы модулей в отдельные сервисы (уже не микро, правда). Т.е. балансировать как-то осознанно между требованиями проекта.
В общем - нужно объяснять не столько плюсы архитектуры, а какие конкретно проблемы с ее помощью можно решить, и какие не стоит. В каких случаях та или иная архитектура даст преимущества? И не забывать про то, что бизнесу как бы пофиг какая там архитектура, ему важно чтобы функционал дошел до пользователей максимально быстро и с минимальными затратами. А еще желательно чтобы всё стабильно работало. Вот так вот всё и сразу, ага. В общем - выбор архитектуры имеет не только технический смысл, но и бизнесовый. Именно поэтому монолиты до сих пор используются - они дешевле в моменте (а вот дороже ли они в долгую - это уже вопрос к модульности монолита) из-за того что на них быстрее разрабатывать и меньше нужно людей для этого. Если же проект успешен, то дальше уже нужно вовремя начать дробить его на микросервисы или гибрид. Опять же вопрос - как понять когда стоит начинать дробить монолит? Или как вовремя понять что микросервисы были плохим решением для проекта?
@@swayok Полностью согласен, что архитектура должна быть выбрана с учётом реальных потребностей, а не трендов. Из моего опыта, редко когда монолит распиливают полностью - чаще он остаётся, но становится меньше за счёт вынесения высоконагруженных или обособленных модулей в микросервисы.
Я работал в компаниях с разными архитектурными решениями и сам строил микросервисную архитектуру с нуля. В нашем случае это оказалось оправданным: благодаря грамотному скалированию микросервисов мы добились отличного перформанса. Но вы правы, что бизнесу важен не подход, а результат. И часто архитектура требует времени на проектирование, которое не всегда легко согласовать с владельцами продукта, особенно когда им нужны фичи “вчера”.
Что за музыка в видео?
Help Me, OP-1 - Dyalla
@Just-York спасибо!
Ни все можно разделить на множество отдельных блоков, и ни все нужно, ии ты никак не разделишь на сотню микроблоков , это будет как минимум бессмысленно, а вот сделать основной монолитный блок, к которому будут подключаться нужные функции могут реально улучшить ту самую гибкость.
А если у меня в факторио принцип модулей . То есть куча монолитов связанных между собой. Ибо некоторые производства лучше вшивать в друг друга
@@МаксВоронін если это эффективно то пожалуйста, это тоже может быть микросервисом, например один микро сервис или модуль или ситиблок, как хотите, может полностью обработать нефтянку и выдать 4 ресурса в остальные модули
Познаю Factorio по аналогиям с монолитами и микросервисами.
Микросервисы упрутся в свой потолок рано или поздно. На том же примере в фактории когда тебе надо не +2 фабрики по плавке метала добавить а сразу +1000 тогда у тебя не будет места и придется перестраивать остальные сервисы чтобы вместить первый. В конце концов играя в фактории уже более 1000 часов, я пришел к выводу что ситиблоки проигрывают одному большому заводу. Мощность конвеерной шины из 20+ конвейеров с 1980 предметов в секунду будет продуктивнее ситиблоков. Потому что такое количество предметов не смогут перевозить поезда и плюс это накладно. Топливо или электричество для поездов плюс размер завода с ситиблоками проигрывает одному большому
Как будто не ролик снимаешь по игре, а собеседование проходишь
Где тебя можно поддержать монетой? Посмотрел описание, не нашёл.
Только сделал)
boosty.to/york-prog
2:24 Ага, зависящие от этого другие сервисы тоже встанут. В факторке , например, если встал завод по проводам, встанет завод по микропроцессорам всех трёх тиров, заводы манипуляторов, модулей и прочее. "И никауие другие сервисы не пострадали"
Монолит тоже будет так работать, если в нём нормально работает обработка ошибок.
@@serg_sel7526 а теперь представь что к тебя разные фабрики от разных источников ресурсов. Те же красные и синие схемы зачастую имеют собственное производство зеленых схем в своих блоках, поэтому если в сравнении с микросервисами каждый сити блок имеет свои собственные источники ресурсов, то проблем таких не возникнет
Ну я бы поспорил по транспорту. Как раз дроны больше похожи на API т.к. он доставляет материал (сообщение) от одного получателя к другому. Конвейер же (да и поезда) больше похожи на брокеры сообщений т.к. отправитель складываем на конвейер сообщения и на этом все, ему не важно что с ними будет, а дальше они едут по конвейеру и потребители кому надо - тот берет. Может даже никто не взять, тогда просто конвейер забьется (на топике вырастит лаг)
Ну и поезд в такой схеме будет чем-то вроде transactional outbox
Спасибо за комментарий! Интересный взгляд на аналогию, и я согласен, что дроны действительно можно ассоциировать с API. В моем примере я намеренно разделил типы доставки: конвейеры сравнивал с RestAPI из-за их прямолинейного и последовательного подхода, дроны - с MessageQueue за счет их гибкости и адресной доставки, а поезда - с gRPC, где важна структурированная передача больших объемов данных. Это, конечно, упрощение, но, думаю, так легче донести основные принципы. Спасибо за интересный взгляд, он помогает углубить обсуждение!
Честно говоря я не совсем понял. В видео при рассказе о микросервисах показывают набор заводов, которые делают шестеренки, которые далее переходят в другой "микросервис", однако если завод с шестиренками перестанет функционировать, то шестерни не пойдут в другой блок, а соответственно процесс так же загнется далее по линии, если только нет дублирующего "микросервиса", но вся система в которую включен 1 этот завод получит сбой. О какой устойчивости речь?
Я бы понял если бы каждая линия имела бы свою независимую подпитку ресурсов и производственную цепочку, но если они в итоге всё-равно перетекают друг в друга - значит и процесс взаимосвязан...
МОжет я конешно не прав, не имею большого опыта в Факторию.
Неправда. Если вкратце, то что раньше в монолите было простым вызовом методов или функций заменяется на обращение к внешнему сервису многократно усложняя разработку, доработку, рефакторинг, поддержку. Если раньше, метод который вызываешь должен существовать, то сейчас другой сервис может быть не запущен, интерфейс не реализован или реализован по другому. В общем, если раньше у тебя в проекте многие моменты ложились на плечи компилятора, то с разнесением логики по отдельным сервисам эта способность теряется. И не стоит забывать про то, что в реальности микросервисы работают на разных хостах, а значит подвержены сетевым проблемам, функционал в них развивается по разному, а значит есть шанс поймать сетевые ошибки, поддерживать это все тяжелее, так как весь функционал разбросан по разным серверам… Микросервисной архитектурой легко убить стартап, потратив на это все кучу ресурсов, так и не начав зарабатывать деньги. Вместо того, что бы написав монолит уже быть в плюсе. Имхо, на микрсервисы можно переходить, когда у тебя уже есть работающий монолит и есть бабки на это, либо изначально большой бюджет…
СПАГЕТТИ ЭТО МОЩЬ
5:29 согласен только с 4 пунктом. Остальные вообще не в тему. (3 с натяжкой)
По ошибкам автор вообще тему не раскрыл. Абсолютно нормально, если приложение падает при ошибке. Ошибки в целом это всегда ожидаемое поведение. (Если нет, то нормально упасть)
6:55
1. Нет, конвейеры это не RestAPI. Это именно что вызов функции в рамках одного процесса. А длинный конвейер, это скорее RPC. (И то, RPC не то чтоб подходит, так как там нет контракта)
2. Дроны это скорее RPC, или тот же Rest. так как у нас конкретная передача до конкретного эндпоинта.
3. Поезда это как раз брокеры сообщений. Именно из-за работы с несколькими сервисами.
Крч я думаю что базово и поверхностно это нормально, но всё равно вводит в заблуждение. Ибо начало и конец видео себе противоречат даже.
В начале игры я строил сначала монолитный завод, потом пришел к микросервисам
Вот бы было что-то по римворлду такое.
очернь понятно, просто, удобно !
Чёт все руки не доходят в неё поиграть, чувствую залипну плотно 😂
Переделываю всю базу в factorio.. Спасибо
Микросервисы слабо подходят в случае, если нужна оптимизация по latency. Как-то раз мы боролись за медианную latency в 40 милисекунд и нам пришлось сливать 4 уровня сервисов в монолит. Плюс микросервисы дают оверхед в обслуживании - метрики, мониторинг, алёрты. Меньше движущихся частей, меньше проблем.
В конкретно факторке надо строить червячков🪱 чтобы потом перестраивать 10 часов
Вы путаете понятия. Монолитная система может иметь такие же выходы, как и микросервисная. То есть если вам вдруг понадобятся отдельные компоненты, то вы просто запустите соответствующий выпуск. Если вы делаете микросервис, то как бы вам не хотелось, вы уже сделали такой выход. В монолите об это нужно думать. К тому же, монолит не требует от вас ставить компоненты вплотную, не оставляя места под расширение. Ключевая разница заключается в методах доставки. Микросервисы используют неоптимальные методы, но их легко делать. В то же время монолитная система обеспечит наилучший выход, но вы будете делать ошибки, если не имеете достаточно опыта разработки. В общем это видео - это не сравнение, а просто рассказ о микросервисах. Вы даже не сказали, какие плюсы есть у монолитов в больших проектах. Опять же, вы ограничены, думая, что монолиты сложно расширять, просто оставляйте пространство и выходы
Наглядный пример илюзии выбора и держание зрителя за дурака, по факту монолит состоит из микросервисов, микросервис состоит из монолитов, а поддержке все равно разбираться потому что в конторе бардак не в тех реализации, а в управлении которое озадачено сравнением микросервисов и монолитов))
Всегда делал лапшу и буду делать!
Самое оптимальное, видео что и где, а если сверху приправить лапшой из жд поездов так вообще чудо происходит, как оно работает?
Да я вообще не знаю, оно работает и не лезь
"сбой одной шахты не остановит весь процесс"
Так оно и в монолите не остановит. Такое ощущение что автор имеет ввиду не монолит, а некую абстрактную "базу новичка" в вакууме.