Комментарии 74
Миллион связей внутри, миллион связей наружи.. хрен редьки не слаще..
Проектироварие это грязная проблема, проектирование это эвристика, а не алгоритм. Вот здесь то собака и зарыта. Проще говоря - заставь дурака молиться, он и лоб расшибет (нашлепает бездумно микросервисы, монолиты, композиты и все что хочешь)
У вас в голове миллиарды синапсов образуют связи и тем не менее вы можете легко получить доступ к тому что знаете, а вот в больших организациях где знания распределены по головам тысяч или даже всего лишь сотен человек собор знаний требует больших усилий и уж точно не быстрый, как орг структуру не проектируй и какие процессы не внедряй.
Может, потому что "бизнес" просто забивает на это? Может, в других оргструктурах с этим получше?
Кто сказал, что я могу легко получить доступ к знаниям? Что такое легко?
При чем здесь мой комент и статья?
Вы извините, я возможно не верно вашу мысль понял про "Миллион связей внутри, миллион связей наружу.. хрен редьки не слаще". Мне кажется что разница есть и она принципиальная, если смотреть с точки зрения системы принятия решений.
Когда у вас монолит (как человеческий мозг), то доступ к данным и принятие решений происходят очень просто - ваш мозг просто берет и обрабатывает всю информацию что есть в памяти. Вы не управляете этим специально, у мозга просто есть прямой доступ ко всем знаниям, поэтому решения принимаются быстро - либо моментально, либо за несколько минут подумав.
Да, иногда можно биться над решением часами или днями, но это обычно когда не хватает какой-то информации. А вот если вся информация есть - монолитный мозг думает быстро.
А теперь посмотрите как работает большая корпорация с микросервисной архитектурой - там быстрых решений вообще не бывает. Работает целая система сбора и подготовки данных: сначала отделы строят отчеты и шлют их в департаменты, там эти отчеты собирают и обрабатывают, потом отправляют наверх. Там на основе этого строят стратегии, передают их в менеджмент борд, и только там принимаются решения. При этом часто даже делаются обратные запросы, которые запускают весь этот процесс по новой.
Вот это второе - и есть типичный пример микросервисной архитектуры, где каждый шаг принятия решения требует кучи согласований и передачи данных между сервисами.
Так что, позволю себе не согласиться с тем, что внутренние и внешние связи - это "хрен редьки не слаще". Внутренние связи обеспечивают мгновенный доступ к данным и эффективное принятие решений, в то время как внешние связи неизбежно создают существенные накладные расходы на коммуникацию и координацию. Это особенно критично для систем с искусственным интеллектом, где скорость доступа к данным напрямую влияет на эффективность принятия решений.
И вы абсолютно правы насчет того, что проектирование - это грязная эвристическая проблема, а не алгоритм. Именно поэтому так важно понимать фундаментальные принципы и ограничения разных архитектурных подходов, а не просто следовать модным трендам. Потому что иначе действительно получится как в поговорке про молитву и лоб - можно и микросервисов наделать где не надо, и монолит раздуть до невменяемого состояния. Архитектура должна следовать за реальными потребностями системы, а не за абстрактными принципами.
PS. Я автор той статьи которую мы комментируем, если что.
Когда у вас монолит (как человеческий мозг), то доступ к данным и принятие решений происходят очень просто - ваш мозг просто берет и обрабатывает всю информацию что есть в памяти. Вы не управляете этим специально, у мозга просто есть прямой доступ ко всем знаниям, поэтому решения принимаются быстро - либо моментально, либо за несколько минут подумав
Вы очень ошибаетесь и преукрашаете возможности человеческого мозга. Быстрый доступ к данным возможен только по накатанной нейронной колее - например, с чем-то часто работаешь, поэтому быстро можешь на что-то ответить или сделать.
Попробуйте-ка воспользоваться знаниям, которые давно не использовались? вытащить их.
Да, иногда можно биться над решением часами или днями, но это обычно когда не хватает какой-то информации. А вот если вся информация есть - монолитный мозг думает быстро.
Быстрые данные - полученные интуитивно - очень часто ошибочны. Много исследований на эту тему. Например, можно прочитать труды Канемана. Интуиция и распознание шаблонов - это вообще мимо интеллекта.
Про долгосрочную память можно ознакомиться в трудах Эббингауза.
Сравнение с мозгом некорректно в данном ключе. Либо надо более удачную метафору придумать.
Я работаю в организации, где 6к микросервисов и огромные монолиты под десятки ТБ реляционных данных. Нужно определиться "что такое монолит". У нас монолит - это журнючая БД (или набор БД) работающая под управлением одного экземпляра СУБД, с 10К+ хранимых процедур. Т.е. это ни что иное, как глобальные данные и куча процедурной обработки вокруг, с миллионами связей. Чувствуете пахнет 60мы годами 20ого века? Это стрельба дробью. Порушил связь - беда. И я вам скажу, что в такой монолит очень сложно вносить изменения. Любое мелкое изменение - необходимость менять логику, единомоментно, согласованно в куче мест только внутри БД. Обычно монолит характеризуется еще и внешними зависимостями (поискать связи по репе не такая и проблема, а вот за пределами - сущий ад). И поэтому внесение изменений в монолит это очень большой геморой, с вовлечением большого количества отделов и понятно дело согласований, техкомов, кроссдоменных проектов.
Микросервисная архитектура, при правильном использовании, как раз таки должна решить проблему глобальных данных. Если ты грамотно разделяешь ответственность, если ты умело скрываешь внутрянку, то будет тебе счастье. Но увы. Разработчики очень редко учатся разрабатывать/проектировать. Обычно они больше внимания уделяют инструментам - языкам программирования, базам данных, кафкам и т.д. А проектирование, по большей части, сводится к подражанию. "Мы так всегда делали". "Соседний отдел так делает".
Монолиты к сожалению не масштабируемые - ни по железу, ни по кодовой базе. Со временем, как раз из-за глобальных данных и числа связей, становятся неповоротливым "аппаратным" обеспечением. Но и неправильное применение микросервисных паттернов тоже приводит к такому же.
p.s.: опять же, подчеркну, нужно дать определение монолиту.
Я с вами во многом согласен, но давайте все-таки разберемся с аналогией мозга. Я ее использовал не для того чтобы сказать что мозг идеален, а чтобы показать разницу между прямым доступом к данным и доступом через внешние вызовы.
Да, вы абсолютно правы про то что быстрый доступ работает только по накатанным нейронным путям, и что интуитивные решения часто ошибочны - но суть в том, что сам механизм доступа к данным прямой. Даже когда мозг долго думает или ошибается - он все равно работает напрямую со своей памятью, а не делает распределенные запросы через API.
По поводу монолитов - вот тут вы очень точно описали проблему. Когда я говорю про монолит, я не имею в виду огромную БД с кучей хранимых процедур - это действительно антипаттерн из 60-х. Современный монолит это скорее единая кодовая база с четкой внутренней модульностью, где модули общаются через понятные интерфейсы, но при этом имеют прямой доступ к общим данным когда он нужен.
А вот по поводу микросервисов - интересно что вы работаете в организации с 6000 микросервисов. Можете поделиться, как у вас решается проблема сложности управления таким количеством сервисов? Я просто видел несколько крупных проектов где микросервисная архитектура в итоге развалилась под собственной сложностью, и интересно как вы с этим справляетесь.
Также, полностью согласен про то что разработчики часто не уделяют достаточно внимания проектированию. Сначала наделают кучу микросервисов по модному паттерну, а потом удивляются почему все так сложно поддерживать.
Хотя суть проблемы намного глубже чем просто выбор между микросервисами и монолитами. По моим наблюдениям, а я видел много компаний, дело часто обстоит так, бизнес постоянно требует быстрых решений, команды наскоро пилят функционал и перебегают на следующий проект. Старый код превращается в легаси - он вроде как работает, но как именно - уже никто не помнит.
И вот эта куча легаси растет как снежный ком. Команды разработки ушли, документации толком нет, новые люди приходят и не могут разобраться что там внутри происходит. В итоге чтобы просто поддерживать это всё в рабочем состоянии нужно в несколько раз больше людей чем могло бы быть при нормальном подходе.
А самое интересное начинается когда условные топ-менеджеры приносят красивую ИТ-стратегию с модными словами про искусственный интеллект и инновации. А на земле - месиво из легаси-кода, в котором никакой ИИ работать просто не сможет.
Получается замкнутый круг - чтобы поддерживать легаси нужно все больше людей, а чтобы внедрять что-то новое - нужно еще больше. И дело тут не в том что микросервисы плохи или монолит хорош. Просто когда технические решения принимаются не техническими специалистами, а бизнесом который торопится и не думает о последствиях - любая архитектура превратится в большой ком проблем, который будет только расти.
Я с вами во многом согласен, но давайте все-таки разберемся с аналогией мозга. Я ее использовал не для того чтобы сказать что мозг идеален, а чтобы показать разницу между прямым доступом к данным и доступом через внешние вызовы.
давайте. Самому думать и разбираться долго (хоть и полезно), а во всем разбираться и вовсе не получится, поэтому обращаюсь к эксперту. Вот мы только что создали 2 микросервиса. Я эксперт в одном - делаю только свое и делаю это хорошо, а он - свое.
Про доступ к данным я понимаю. Внутрипроцессный доступ он легче и проще, чем межпроцессный, а уж тем более через асинхронные сети. Но число связей то это не уменьшает. Микросервисы это компромисс невозможности масштабирования монолита. И да, за это придется заплатить. Но из двух зол выбирают меньшее, а серебряной пули не бывает.
Современный монолит это скорее единая кодовая база с четкой внутренней модульностью, где модули общаются через понятные интерфейсы, но при этом имеют прямой доступ к общим данным когда он нужен.
Ну как у вас могут быть глобальные данные и модульность одновременно? Это противоречие. Не может быть ООП, но с глобальными данными. Его придумали как раз чтобы их скрыть и получили буст в размерах и сложности ПО.
Если какие-то функции могут выполняться в рамках одного процесса, то зачем их дробить на микросервисы и устраивать геморой с общением по сети? Такие вопросы должны задавать себе проектировщики
А вот по поводу микросервисов - интересно что вы работаете в организации с 6000 микросервисов. Можете поделиться, как у вас решается проблема сложности управления таким количеством сервисов?
Есть микросервис специально обученный управлять другими микросервисами. Короче разделение функций. Один отвечает за сеть, другой за ресурсы, третий за пайплайны и т.д. Всех проблем я вам не скажу. Я - микросервис отвечающий за некоторый набор продуктовых функций (надеюсь делаю это хорошо :)).
Вот мы только что создали 2 микросервиса
Понимаю вашу точку зрения, но тут есть интересный нюанс. Когда вы делаете микросервис изолированно как эксперт в своей области - это хорошо для самого сервиса, но плохо для системы в целом.
Когда эксперты работают по отдельности, каждый супер-круто делает свою часть, но общая картина часто получается так себе. Это как если бы вы делали машину и у вас отдельно крутой эксперт по двигателям сделал мощный двигатель, отдельно эксперт по аэродинамике нарисовал обтекаемый кузов, а эксперт по комфорту спроектировал роскошный салон. И вроде каждый сделал идеально свою часть, но собрать это вместе так чтобы работало - та еще задачка.
Человек имеет ограничения, объем мозга и скорость его работы ограничены. Человек должен есть спать и другие дела делать, человек не может постоянно изучать информацию. По этому люди - супер эксперты довольно редки и дороги. А вот ИИ хоть пока и не догоняет до уровня человека по умению создавать новое, но у него нет ограничений по скорости работы и умению обучаться
А теперь представьте что у вас есть ИИ который может одновременно быть экспертом во всех этих областях и видеть общую картину. Он может не просто сложить отдельные экспертизы, а найти оптимальное решение учитывая все факторы сразу. Это как если бы у вас был один супер-эксперт который одновременно разбирается и в двигателях, и в аэродинамике, и в эргономике, и еще в куче смежных тем.
Именно поэтому ИИ дает такое преимущество крупным компаниям - он может преодолеть эту проблему узкой экспертизы и найти действительно системные решения. В то время как группа даже самых крутых экспертов часто застревает в спорах и не может прийти к общему знаменателю.
Ну как у вас могут быть глобальные данные и модульность одновременно?
Вот вам конкретный пример из реальной жизни чтобы было понятнее про монолит с модулями.
Возьмем приложение для онлайн-магазина. У нас есть модуль заказов, модуль товаров, модуль пользователей. Каждый модуль инкапсулирует свою логику и данные. Но когда нужно оформить заказ - модуль заказов может напрямую получить все нужные данные о товаре и пользователе через методы этих модулей, без сетевых вызовов.
А теперь представьте что мы разнесли это на микросервисы. Чтобы создать заказ нам надо:
Сделать HTTP запрос в сервис товаров
Дождаться ответа
Сделать еще запрос в сервис пользователей
Снова ждать
И только потом создавать заказ
И везде на этом пути могут быть проблемы - сеть лагает, сервис не отвечает, версии API не совпадают.
В монолите же все модули работают в одном процессе, и хотя данные так же инкапсулированы в модулях - доступ к ним происходит напрямую через вызовы методов. Это и быстрее и надежнее.
Да, и самое интересное что если брать современные ORM - они как раз и реализуют этот принцип. Возьмите например Entity Framework или Hibernate - вы описываете модели данных, связи между ними, и ORM позволяет вам работать с ними как с объектами в памяти.
При этом когда вы делаете Include в Entity Framework - вы явно указываете какие связанные данные вам нужны, то есть инкапсуляция сохраняется. Но сами данные загружаются напрямую из базы в память процесса, без всяких HTTP запросов и сериализации.
То есть современный монолит с ORM - это по сути и есть та самая модульность с прямым доступом к данным, о которой я говорю. Вы получаете и чистоту ООП подхода, и производительность прямого доступа к данным в рамках одного процесса.
Есть микросервис специально обученный управлять другими микросервисами.
Да, я понимаю о чем вы говорите, это похоже на BRE (Business Rules Engine) паттерн, где отдельные сервисы управляют бизнес-правилами. У меня был опыт разработки похожей архитектуры.
Основная проблема которую я там увидел - это именно сильная фрагментация данных. Смотрите что получается: у вас есть специальный микросервис для управления другими сервисами, отдельный для сети, отдельный для ресурсов, для пайплайнов и так далее. И вроде это круто с точки зрения разделения ответственности, каждый занимается своим делом.
Но когда вам нужно собрать общую картину - например, для анализа проблем или оптимизации работы системы - приходится собирать данные из всех этих сервисов в одном месте. И на это уходит просто огромное количество усилий, потому что данные могут быть в разных форматах, могут быть рассинхронизированы по времени, некоторые сервисы могут быть недоступны, а связи между данными из разных сервисов неочевидны.
В своей архитектуре я для этого разрабатывал специальные сервисы для сбора данных, но все равно это сложная задача, сервисы учитывали разные моменты и задержки, в итоге собирали данные в одном месте но все это было не мгновенно. И собираемые данные использовались в основном для мониторинга, а вот для анализа использовался отдельный поток который требовал до суток на то чтобы собрать данные на день.
В итоге получается что простая с виду задача "посмотреть что происходит в системе" превращается в сложный проект по сбору и согласованию данных из десятков сервисов. И это одна из главных причин почему такие большие микросервисные системы так сложно поддерживать.
Я это делал 5 лет назад, тогда не было генеративного ИИ и задач по доступу в реальном времени, и это не было проблемой, сейчас же уже ситуация поменялась и требования другие. Наверное я бы уже так не делал. Хотя соглашусь, архитектура - это компромисс. Бросаться и все переделывать в угоду ИИ, который сейчас хоть и сделал мощный рывок вперед но не дает таких уж огромных преимуществ (пока), тоже не следует. Но как мне кажется, дрейф в сторону композитной архитектуры с модульными монолитами уже наметился.
А теперь представьте что у вас есть ИИ который может одновременно быть экспертом во всех этих областях и видеть общую картину. Он может не просто сложить отдельные экспертизы, а найти оптимальное решение учитывая все факторы сразу. Это как если бы у вас был один супер-эксперт который одновременно разбирается и в двигателях, и в аэродинамике, и в эргономике, и еще в куче смежных тем.
Именно поэтому ИИ дает такое преимущество крупным компаниям - он может преодолеть эту проблему узкой экспертизы и найти действительно системные решения. В то время как группа даже самых крутых экспертов часто застревает в спорах и не может прийти к общему знаменателю.
Да сказки это маркетинговые. ИИ в наше время не реальный ИИ, а просто нейронка, натренированная на массиве данных. И в этом массиве в основном не экспертные решения, но даже если это массив из специализированной области, никаких "системных" обобщений она вывести не сможет - выводилки нет.
В качестве примера, ни один ИИ не поможет мне спроектировать альтернативные протоколы Интернета или файловую систему с заданными параметрами - так что кожаный мешок в лице меня занимается этим по старинке, много читая.
если нужно спроектировать альтернативный протокол или файловую систему, то для этого не нужно ИИ подключать к данным предприятия. Там задачи другие стоят, например найти неоптимальные процессы или спрогнозировать продажи на следующий период. Вот как раз с таким ИИ справляется на ура. Даже сейчас. Но на вход нужна качественная информация. Хотя конечно именно для этих задач не нужно чтобы данные были в режиме реального времени. Для реального времени другие задачи, поиск по запросу нужных операций, составление отчетов в реальном времени (например для выявления аномалий). Всякие там разные чатботы для помощи как сотрудникам так и клиентам. Много чего можно напридумывать.
Вообще активное развитие генеративного ИИ началось не так давно, соответственно еще не так уж много действительно полезных внедрений, но тенденция уже наметилась, кто сможет обеспечить хороший доступ ИИ к данным тот будет иметь огромное преимущество, процесс уже этот запущен...
видимо мы вообще друг друга не понимаем. Я говорю вам про микросервисы, как способ обойти невозможность масшабирования монолита, а когда такой проблемы нет, то и обходить нечего (стало быть и микросервисы не нужны). Вы мне приводите пример отсутствия проблемы масштабирования (...все нужные данные о товаре и пользователе через методы этих модулей, без сетевых вызовов...).
Мы с вами про разные монолиты говорим. То что вы описываете это монолитный экземпляр, но внутри он устроен весьма грамотно - идеально (обычно на практике все гораздо хуже) - изолированные модули, грамотное разделение ответственности.
Но и здесь вы сами себя обманываете. От того, что вы в один исполнимый файл (кодовую базу) запихаете кучу логики, даже если она будет очень хорошо модулиризирована, проблема интеграции никуда не девается. Кол-во связей компонентов внутри (этих самых методов и типов) не уменьшается. Необходимость иметь узкоспециализированных разрабов модулей никуда не уходит. По большей части разница в транспорте.
Попробуйте-ка поскейлить такой экземпляр монолитный в огромнейшей системе на обработку хотя бы 100К rps (rps rps'у рознь, но кто знает, тот поймет о чем я). Это будет дикая неэффективность, если вообще возможно.
А знаете, этот пример отлично показывает почему сейчас все движется именно к композитной архитектуре, особенно с развитием ИИ.
Смотрите - когда у вас нагрузка в несколько тысяч RPS, монолитная архитектура с хорошей модульностью отлично справляется. А вот когда доходит до 100К RPS - тут уже без микросервисов никак, потому что нужно масштабировать разные части системы независимо.
И вот тут как раз композитная архитектура дает идеальный баланс. Части системы с умеренной нагрузкой остаются в монолите - там где нам важнее скорость доступа к данным и простота разработки. А высоконагруженные части выносятся в отдельные микросервисы - там где реально нужно независимое масштабирование.
С приходом ИИ это становится еще актуальнее. Потому что ИИ требует быстрого доступа к большим объемам данных для принятия решений. В микросервисной архитектуре получить такой доступ очень сложно - пока соберешь данные из разных сервисов, пока их согласуешь... А в монолите ИИ может работать напрямую с данными.
Поэтому логичный путь такой - держать ИИ и связанные с ним компоненты в монолитной части для быстрой работы с данными, а то что требует реального масштабирования выносить в микросервисы. Собственно, это и есть композитная архитектура, которая сейчас становится все популярнее.
Я это на своем опыте увидел - 5 лет назад делал чистую микросервисную архитектуру, а сейчас бы уже так не стал. Слишком сложно интегрировать туда ИИ и работать с данными в реальном времени.
С приходом ИИ это становится еще актуальнее. Потому что ИИ требует быстрого доступа к большим объемам данных для принятия решений. В микросервисной архитектуре получить такой доступ очень сложно - пока соберешь данные из разных сервисов, пока их согласуешь... А в монолите ИИ может работать напрямую с данными.
вы искренне верите, что обученные модельки для принятия решения (и наверное обучения) будут использовать оперативные данные? Или вы в монолит еще и аналитические модели запихаете? Или оперативная обработка будет страдать от избыточности и денормализованности?
Части системы с умеренной нагрузкой остаются в монолите - там где нам важнее скорость доступа к данным и простота разработки.
Что такое простота разработки? Как будете решать проблемы масштабирования разработки? Представьте, что у вас монолит, с кучей подсистем, каждая подсистема (или подмножество) - выделенная команда. Как фичи деплоить? выстраиваться в очередь? Или накидываем фичи в кучу и раз в месяц, методом "большого взрыва" пытаемся заинтегрировать эти фичи и выкатиться в продакшн?
Вы просто скажите - у меня маленькие приложения, с ограниченными числом функций, поэтому у меня монолит. Или "у меня десктопное приложение" - но тут и понятно, что микросервисы как пятое колесо (хотя и здесь есть нюансы).
Ну как у вас могут быть глобальные данные и модульность одновременно? Это противоречие. Не может быть ООП, но с глобальными данными. Его придумали как раз чтобы их скрыть и получили буст в размерах и сложности ПО.
Да очень просто могут. Потому что ООП придумано не "за этим", а как обмен сообщениями. И концептуально глобальные данные можно рассматривать как "объект", с которым не надо отдельный протокол иметь, а можно просто брать эти данные напрямую.
Модульность - она ведь не про сокрытие данных, а про управление кодом, прежде всего. То есть что разные модули можно поручить разным людям или даже командам. И это не помешает им ходить для какой-то части в общую таблицу в БД, структура которой известна всему проекту.
Модульность - она ведь не про сокрытие данных, а про управление кодом, прежде всего.
как раз таки про сокрытие. Скрываешь внутрянку, даешь абстракции, значит можешь менять отдельные модули (или абстракции) без влияния на все остальное. Раскрываешь внутрянку - велком искать все зависимости и аккуратно, единомоментно, правильно меняешь их в каждом месте. Или получаешь breaking changes.
И да, ООП это про обмен абстракциями (событиями). Сами глобальные данные скрываются.
Я наконец то понял что такое микросервисы
Я мало работал с микросервисами и точно не видел когда их нужно сотни и тысячи.
Я представляю себе процесс их появления в таком количестве так:
бизнес постоянно требует быстрых решений, команды наскоро пилят функционал и перебегают на следующий проект. Старый код превращается в легаси - он вроде как работает, но как именно - уже никто не помнит. Причём, силы на документирование тоже тратить никто не хочет потому что это в 95% сервис который будет не нужен через месяц. Например, 100500й ad-hoc отчёт, выгрузка, источник данных. Собственно, это огромная куча мусора. Поэтому минимум попыток выйти из стадии говна и палок, максимум изоляции кода, изоляции команд разработчиков, аналитиков, требований, документации. Вот этот почти не используемый хлам, который страшно выкинуть и называют легаси. Микросервисы это куча хлама, который раскидали по отдельным шкафам.
Вопросы масштабирования тут далеко не на первом месте.
С другой стороны, ИТ это способ для бизнеса познать себя и мир, способ для экспериментов, тренажерный зал.
Бизнес придумал что-то, что устареет через пару месяцев, ad-hoc функционал. Требования сформулированы плохо, реализовано на скорую руку, как сопровождать неясно, ведь требования неясны а бизнес контекст уже ушёл. Но сервис ещё может понадобиться и поэтому его не гасят. Если посмотреть долю чистого, долго живущего, часто используемого функционала то доля мала.
Финтех и аналитика
Контекст: Бизнесу нужны отчёты, дашборды и интеграции с новыми источниками данных. Часто это разовые задачи, но данные продолжают течь, отчёты могут понадобиться.
Пример: Ad-hoc сервис для выгрузки транзакций для налоговой или анализа поведения клиентов, который потом забывают выключить.
Почему микросервисы?: Удобно для изоляции источников данных, но без документации и тестов это превращается в чёрный ящик.
E-commerce и ритейл
Контекст: Постоянные кампании, скидки, интеграции с новыми партнёрами. Всё нужно «вчера», а требования меняются на ходу.
Пример: Выгрузка данных для очередной акции «Чёрная пятница» или интеграция с новым поставщиком, который через три месяца уходит.
Почему микросервисы?: Позволяют быстро пилить временные решения, но никто не чистит за собой, и система обрастает легаси
6к микросервисов
Зачем?
Откуда их взялось столько?
Ясен пень, как только кризис начинается, сразу из головы дурь про микросервисы выбивает. Квадратичный рост - фактически то же самое, что закон Брукса, только уже на командах.
Ну и забавно, как гордость не позволяет сказать "микросервисы были ошибкой, давайте вернемся к монолиту". Нет, надо обозвать повычурней, теперь "композитная архитектура"! Хотя ничего нового в вынесении некоторых отдельных компонентов в сервисы нет, десятилетиями применяется.
Не совсем корректно смешивать классический монолит и модульный(композитный) монолит. В первом обычно из любого места проекта видно весь остальной проект, программисты активно этим пользуются и чем дольше, тем хуже клубок зависимостей получается, код становится неподдерживаемым. Модульный монолит фактически организован как микросервисы и вы не можете в любом месте использовать весь проект, только некоторую часть, которая доступна для этого места. Но при этом за счет композиции модулей в один бинарник, в котором разные модули общаются через память, вам не нужно тратить значительные ресурсы на организацию работы, версионирование и взаимодействие, что обычно происходит в случае микросервисов. Тем не менее, что важно - в грамотно организованном модульном монолите при желании вы легко можете собрать из модулей и несколько сервисов, просто заменив реализации контрактов их взаимодействия и не переписывая половину проекта.
Ну ок, модули... А как эти модули взаимодействовать то будут? Если опять через сеть, (или пайпы, что не сильно отличается) - то будут всë те же проблемы, что и с микросервисами. Отсутствие единой транзакции... Если через базу - ну так это классический монолит. Разве что внутри можно немного поделить модель, но практически это мало что даст. За монолитом сложнее следить, что бы он не превратился в большой коричневый ком. Думается, тут баланс нужен. И да, это работа архитектора, определить какие границы у сервисов. И правильно @nuclight написал - это старо как сам софт. Отделяли части приложения в отдельные слои/модули/сервисы, но называли иначе. От перемен названий проблемы сами не уйдут.
Модульный монолит не про транзакции, он решает другую проблему - устраняет необходимость поддерживать медиаторы типа сервис меша, очередей, инфраструктуры для всего этого, поддерживать и мучаться с разными версиями сервисов, их разными жизненными циклами и так далее. Когда взаимодействие идёт просто через память без посредников, то о посредниках не надо думать, и это экономит много времени. Для небольших и средних компаний это бывает важно. Что касается транзакций, то если вы хотите делать транзакции между модулями, то возможно стоит перепроектировать.
Модульный монолит не про транзакции
Я правильно понимаю, что вы предлагаете, имея монолит, делать в нем многошаговые транзакции ? (К примеру, если пользователь совершает покупку, то корзину вы очищаете в одной транзакции, а покупку и списание со склада будете оформлять отдельными транзакциями... ?) На разных базах или на одной ? Можете конечно, но по мне основное достоинство монолита не в том, что теперь мне не надо через сеть взаимодействовать. (Даже наоборот - это недостаток. При смерти сервера, монолит весть упадет. ) А то что теперь я могу делать все изменения в персистентных данных в одной транзакции без всяких CAP-"теорем" и прочих приседаний, c гарантией корректного отката, если что-то пошло не так. Я как то извращенно это понимаю ? (или всё же мир стал извращенным ?)
По-разному можно. В только что упомянутом биллинге о двух тыщах бинарей в основном это единая оракловая база (на самом деле четыре, но там разделение вида "здесь живёт мониторинг"), но многие взаимодействуют через файлы, некоторые через shared memory, и еще большой кусок через RPC от Tuxedo, но это для условных клиентов.
Да кто вам сказал, что бинарник должен быть один, и что видимость определяется не волевым решением? У нас вон в биллинге опсоса под две тысячи бинарников, и при этом это вполне себе монолит "без конкретного уточняющего прилагательного", потому что об этом прилагательном никто не задумывался за отсутствием нужды - нет хайпа про микросервисы (ему более 30 лет, там код на Коболе есть), нет и нужды названия выдумывать.
И как эти бинари взаимодействуют?
В таком случае я бы не стал называть приложение, состоящее из разрозненных бинарных файлов, потенциально имеющих разные версии, написанных на разных языках разными командами и по-разному взаимодействующих друг с другом монолитом. Для меня основным признаком монолита является то, что он работает через общую память и собирается как единое целое одной системой сборки, у чего есть понятные плюсы и минусы. Как только у вас появляются дополнительные части, пусть и лежащие на той же машине и работающие не через сеть, рассуждение об этом как о монолите может привести к неправильным выводам
Нет, версия разумеется общая (у некоторых билдинг-блоков может быть своя, но это скорее для потенциальной возможности миграции меж заказчиками) - релиз единый идёт. Потому что не только репа общая (ну, оставляя в стороне вопрос RCS), но и система сборки общая - например, добавление одного домена (типы данных местные) приведет к соответствующей кодогенерации и соответственно изменениях через инклуды во всём проекте. Ну и база данных общая, конечно же.
Монолит - это прежде всего способ организации команд(ы) и работы с кодом, конкретные методы взаимодействия программных частей меж собой в рантайме не столь важны. К неправильным выводам может привести разве что рассуждение об этом в контексте микросервисов, которым, чтобы "продать", надо было обозвать как-то отличающееся, и побольше недостатков засунуть в свое определение, конечно. Это сродни тому как agile придумал нам "водопад" - не было ведь никакого водопада до того, на самом деле, ибо никто его так не называл. Просто надо было выдумать жупел, показать, чем мы отличаемся. Так же и с монолитами вышло.
Вариаций реализации монолитов/микросервисов много. Ругать или хвалить стоит конкретные решения, но зачастую это будут субъективные плюсы и минусы для определенного проекта/задачи.
А вообще делайте как хотите и что хотите. Ведь неважно хороший или плохой вы сапожник, всё равно вы сделаете сапог и получите опыт. Теория тоже важна, но опыт сложнее получить.
PS. Я не говорю что не нужно учиться, Я за то, чтобы набивались шишки, а когда не будет хватать теории (будут конкретные проблемы), то её можно будет гораздо легче получить, нежели находиться в фрустрации и искать идеальное решение.
В целом с автором согласен - "диктатура микросервисов" второй половины 10х годов - это штука ужасная и скольким командам она принесла больше вреда, чем пользы не перечесть, так что популяризация модульного монолита - это на мой взгляд действительно благо для индустрии. Что касается части про AI я не очень согласен, на своей практике даже если команда работала в рамках модульного монолита, AI/ML модули обычно выносили в отдельные сервисы со своим рантаймом по разным причинам, например потому что язык был другой или не хотелось тянуть очень тяжелые зависимости в основной бинарник и т.д.
Архтектура - это искусство выбора компромисных решений для закрытия требований к продукту. Наивно думать, что если была причина перехода на микросервисы, то в один прекрасный день, можно взять и переписать всё в монолит.
Причиной было то, что крупным компаниям, где сотни и тысячи разработчиков работают над одной экосистемой без микросервисов никак и они стали популяризовать этот подход, чтобы сразу с рынка брать знакомых с ним людей. Компаниям со значительно меньшими отделами разработки это было далеко не так необходимо, но повинуясь моде и давлению крупных компаний (все конференции были только про микросервисы в те времена), во многих мелких компаниях начинали без разбора переходить на микросервисы. Из самых плачевных результатов, которые я встречал: люди занимаются прослойками - чинят очереди, ковыряют кубер, сравнивают версии микросервисов и ищут в них нестыковки, а бизнес фичи стоят по несколько спринтов.
Просто хайп как и блокчейн, AI, и тд)
Это говорит о чем? О том, что умение программировать на java еще не означает умение думать головой и анализировать. Это был фееричный исторический пример crapification, где тысячи "инженеров" обгадились.
А причем тут конкретно Java? Хотя, конечно, с ней миллионы гадятся с 90-х...
Java вообще не при чем. Первый микросервайс хел, который я увидел, был на ноде. Что касается инженеров и думать головой - нужен архитектор, кто придумает, как оно всё вместе будет работать вместе. К инженерам, которые пишут непосредственно код на любом языке, это не имеет отношения.
причём тут команды? микросервисы это же не про разделение задач в разработке. И монолит можно писать десятком команд. И оно даже часто так и пишется. А как вы монолит масштабировать будете? Целиком в сотне инстансов? Даже если масштабировать нужно буквально одну функцию?
Ну вообще, для менеджмента - это в основном как раз про разделение на команды.
А масштабирование "монолита" проблемы не составляет (да, берем и масштабируем инстансы, даже если на инстансе сконфигурена всего одна функция), кроме вырожденных случаев, когда там статический бинарь за 4 гига и т.п.
Микросервисы - это в первую очередь про управление командами и определенную интерпретацию принципа разделяй и властвуй для больших компаний. Когда компания и отдел разработки маленькие всё это теряет смысл и прослойки начинают съедать больше ресурсов, чем полезная нагрузка.
Масштабировать монолит по rps в сотне инстансов не проблема.
Когда над монолитом работает сотня команд - это проблема
Когда на 100 микросервисов одна команда из 10 человек - это тоже проблема
А я всегда говорил фанатам микросервисной архитектуры: "Ребята, вы хоть один пример из реального мира (желательно природы) микросервисной архитектуры можете привести? Не можете! Так как эволюцией и временем доказано что микросервисная архитектура не жизнеспособна сама по себе и проигрывает монолитам." Есть примеры в природе взаимодействия монолитов, но микросервисов нет!
А как бы оно вообще могло выглядеть в природе, где нет никаких API, хоть даже с теми же монолитами ? Рой пчёл/муравьев сойдет?
Рой пчел/муравьев это как раз пример взаимодействия монолитов, стая волков тоже еще один пример. Вы должны назвать рой, где нет одинаковых особей и где все выполняют разные функции. Таких примеров нет. Насчет API, в природе роль API выполняет язык на котором происходит общение.
На самом деле рой пчел больше похож на микросервисы, пчелы делятся по функциям, они не одинаковые, есть пчелы разведчики, есть пчелы которые нектар собирают, есть солдаты, есть те кто соты строит и так далее там у них сложная конструкция. И АПИ есть, пчелы могут передавать информацию через феромоны и через танец, например разведчики танцем показыают рабочим пчелам куда лететь за нектаром.
Но в данном случае пчелы - это скорее исключение которое подтверждает правило. Пчелы со своей микросервисной архитектурой очень уязвимы и не захватили мир, а захватил мир монолитный человек благодаря ИИ в мозгу
Вы назвали всего четыре функции разных пчел, но в рое пчел сотни тысяч, тогда и функций должно бцть сотни тысяч, либо мы имеем "дублирование програмного кода" в данном примере.
Мне кажется, что группа пчел одного типа (разведчики, собиратели и т.п.) похожа на скейлинг (scale) в микросервисной парадигме. Можно поднять от 1 до 1000 инстансов одного микросервиса, если того требует нагрузка. Код в данном случае не дублируется, а масштабируется производительность отдельного функционала системы. Причем горизонтально масштабируется, решая попутно проблему резервирования и отказоустойчивости.
Т.е. в итоге мы имеем 4 сервиса и 1000 инстансов каждого из них. А почему тысячу? Не маловато будет? Ведь в рое сотни тысяч пчел! Должно быть 25 000 инстансов!
Проблема большинства людей в том, что они не умеют считать. Достаточно взять в руки калькулятор, как абсурдность многих предположений и идей сразу становится очевидна. Как бы вы не пытались натянуть сову на глобус, но мат.расчеты не позаолят вам это сделать. Пчелы - это не микросервисы.
Все зависит от задачи и размеров проекта.
Давайте представим, что нам нужно создать бекенд платформу для чат-приложения (такого как whatsapp/telegram). В этой платформе нам нужен тип микроссервиса который будет отвечать за websocket соединения от клиентских приложений. Этот серис должен принимать сообщения от клиентских приложений, доставлять адресованные сообщения. Предположим, что с учетом ограничений по железу, один сервис способен обсуживать, например, 10К онлайн клиентов. (ремака по железу: обычно много маленьких серверов дешевле, чем они супер мощный).
Представим, что в первое время аудитория нашего чат-приложения будет 100К пользователей. Для них нам нужно поднять 10 инстансов сервиса.
Далее возникает вопрос масштабированиея системы с ростом полулярности - нам нуужно большк инстансов.
Вот у Телеграм 950 млн пользователей. Для обслуживания такой аудитории 25К инстансов может быть мало.
Как забавно наблюдать "не умеют считать" на примере этого же самого сообщения. Нет в рое "сотен тысяч" пчёл. Не поместятся в улей.
На самом деле, там все интереснее. В улье действительно больше специализаций пчел - есть уборщицы которые чистят ячейки, кормилицы для личинок, пчелы-регулировщики которые вентилируют улей и поддерживают температуру, пчелы-водоносы, пчелы-приемщицы которые забирают нектар у сборщиц и сгущают его в мед, пчелы-строители, пчелы-разведчики, пчелы-охранники на входе, пчелы-санитары которые выносят умерших, есть даже специальные пчелы которые запечатывают соты воском. Кроме рабочих пчел есть еще матка, которая отвечает за воспроизводство всей системы, и трутни, у которых своя специализированная роль
А по поводу дублирования - тут как раз работает правильный скейлинг, как в микросервисах. Если нужно больше меда - улей увеличивает количество пчел-сборщиц. Если идет активное строительство сот - больше строителей. То есть "инстансов" каждого типа пчел ровно столько, сколько нужно под текущую задачу.
И насчет количества - в улье обычно 20-60 тысяч пчел, а не сотни тысяч. Это как раз нормальное количество микросервисов для крупной системы, где каждый тип сервиса масштабируется отдельно под нагрузку.
Так что аналогия с микросервисами очень точная - специализированные юниты, свои протоколы общения, автомасштабирование под нагрузку. Другое дело что такая система реально сложная в поддержке, стоит матке заболеть - и всё, привет. И наверное поэтому пчелы так и не захватили мир - один монолитный медведь может запросто уничтожить несколько десятков распределенных микросервисных ульев. А уж когда появились модульно организованные люди, которые научились создавать крупные монолитные структуры вроде сельского хозяйства - пчелы вообще оказались на грани выживания как вид. Потому что против огромной согласованной системы вроде промышленного земледелия с пестицидами даже идеально организованная микросервисная архитектура улья оказалась бессильна.
в природе роль API выполняет язык на котором происходит общение.
Я тонко намекал о некорректности аналогии, придется уже толсто. Не выполняет. *Язык* есть только у человека, у остальных лишь сигнальная система. И API оно тоже не является, более корректным является понятие протокол (впрочем, это сокращение вообще в нынешнем Вебе обычно применяется неверно).
А из некорректной аналогии следуют дальнейшие логические ошибки. Например:
Вы должны назвать рой, где нет одинаковых особей и где все выполняют разные функции.
С чего такое требование взялось вдруг? Более того, микросервисы нередко продают под соусом как раз масштабирования одинаковых инстансов одной функции (вона, половина хайпа всяких, простите за выражение, кубернетесов именно об этом).
Если пофилософствовать абстракциями, то исходное объектно-ориентированное программирование - передача сообщений - было забыто (нет, Java и C++ не оно), потом переродилось в виде акторов и дальше в идею микросервисов. Аналогия роя - из максимально простых объектов - как раз очень даже подходит тут.
Фанатам микросервисов надо было показывать ту гифку, что на днях в телеге ходила, где рой муравьев очень долго протаскивает двутавр через лабиринт - вот, посмотрите, какое оно неффэективное по сравению с монолитной обезьяной. Вы же рассуждениями пошли в какую-то совсем неверную сторону.
А вот насчет распределенных систем интересное замечание. Смотри - у тех же пчел и муравьев распределенная система возникла не от хорошей жизни, а потому что один маленький муравей или одна маленькая пчела физически не могут решить большую задачу. У них просто нет выбора, они обязаны кооперироваться.
А у человека есть мощный процессор в голове, который позволяет решать сложные задачи монолитно. И когда мы делаем микросервисы - мы как бы добровольно отказываемся от этого преимущества, разбивая простую задачу на много маленьких. Это как если бы человек вместо того чтобы просто взять и поднять бревно, начал бы бегать вокруг него кучей маленьких человечков.
Поэтому сравнение с роем не очень корректное - рой это вынужденное решение из-за ограничений отдельной особи. А микросервисы это когда мы сами себе создаем сложности, разбивая монолит на кучу мелких сервисов, а потом героически эти сложности преодолеваем.
И кстати, муравьи с двутавром это отличный пример - они конечно затащат его куда надо, но это будет стоить огромных усилий по координации. А один человек с нормальным мозгом просто возьмет и перенесет его, потому что может просчитать траекторию и все сделать эффективно.
Покажите мне природную систему которую возможно поддерживать и направленно изменять, или хотя бы тестами покрыть.
"Ребята, вы хоть один пример из реального мира (желательно природы) микросервисной архитектуры можете привести?
Человеческий организм. Органы - сервисы, каждый выполняет свою функцию и делает только ее и делает хорошо.
Сложно найти пример монолита, где есть одна большая однородная структура, без иерархии, с дублированием функций. Скорее что-то неэффективное.
Но ведь вы нашли. Человеческий организм - это пример монолита. А вот человек на операционном столе, ограны которого извлечены и размещены по баночкам с растворами, которые поддерживают их жизнь, это пример микросервисов. Человек при этом находится в безсознательнои состоянии (коме) и подключен к аппарату искуственного дыхания. Аналогично и любая микросервисная айти система всегда находится в коме и требует постоянного колдовства бригады "врачей" над ней.
и почему это пример монолита, а не системы, состоящей из микросервисов?
Аналогично и любая микросервисная айти система всегда находится в коме и требует постоянного колдовства бригады "врачей" над ней
да, а монолит автономен и не требует постоянно поддержки.
Как правильно написали выше - в одной репе проще найти ВСЕ затронутые части, изменить зависимости, чем в раскиданной по микросервисам и отделам системе, да еще когда открыть репу соседнего проекта - это отдельный запрос доступа.
Т.е. тебе нужно изменить, бизнесу как всегда надо вчера, но ты не знаешь что отвалится.
Спасает омниканальность, постепенное приведение к "целевой" архитектуре и единым стандартам либ. Когда все интерфейсы и потребители зарисованы, верифицированы системой при выкладке (т.е. это не мертвая документация).
Ой да прям. Там столько завязок внутрисистемных, что это именно монолитейший монолит. Вот даже на уровне органов - казалось бы, где сердце, а где почки? А они связаны в поддержании артериального давления. На уровне пониже вообще кровь есть везде и рецепторы к одним и тем же веществам как правило разбросаны по всему организму, а не сконцентрированы в одном органе.
назовите хоть один орган, который бы дублировал функции другого? не дополняют друг друга или влияют оба на что-то, а именно выполнение один и тех же функций. На давление много что влияет. Так же как и на успешность, скажем, создания заказа в микросервисной или монолитной среде.
так и кровь можно рассматривать под разными углами.
Спасибо за статью.
В целом, интересно. Я в архитектуре почти не разбираюсь, но вот насчёт ИИ не согласен. Мнение в статье выражено поверхностно и без доказательств.
Поясняю. Большинство ML-сервисов:
крутятся на Python-подобном (привет, PyTorch, TensorFlow и разные ...Py)
требуют туеву хучу ресурсов (необязательно)
очень чувствительны к чихам в данных
Поэтому запихнуть что-то что ещё не до конца осознано (как могут измениться данные? методы и модели? понадобится ли их засунуть в озеро?) в монолит выглядит странным. Для этого и есть микросервис, к которому ты можешь обратиться по необходимости, масштабировать, если данных стало много/мало, ну и наконец потушить. Отсюда и flask, FastAPI, и прочее. Нет, конечно есть Hadoop и прочее, но на мой взгляд это больше про ETL. Опять же моделей может быть не одна. Про переобучение, инференс есть отдельная история - не все модели требуется/есть возможность апдейтить на лету.
Ну наконец-то, в западном сегменте уже лет 5 как люди не бояться говорить, что микросервисы скорее не нужны, чем нужны. У нас только сейчас народ начинает задумываться.
Введение: Почему мы возвращаемся к монолиту?
Да потому что уже заработали бабла на том, что сначала распили всё что можно))). Теперь будем пилить на том, чтобы собрать обратно)) <сарказм>
Композитная архитектура: возвращение к монолиту на новом уровне