Привет! Меня зовут Максим Рогоза, я работаю корпоративным архитектором в крупнейших компаниях последние 7 лет. В настоящее время занимаюсь стратегическим IT консалтингом в компании Аксеникс, где мне приходится консультировать крупные компании по вопросам построения эффективной IT архитектуры. В рамках этой деятельности я часто сталкиваюсь с задачами трансформации архитектуры информационных систем, и все чаще приходится рассказывать про композитную архитектуру как оптимальное решение для крупных корпоративных систем.
Мой путь в IT начался 26 лет назад, и за это время я наблюдал всю эволюцию архитектурных подходов: от классических монолитов к микросервисам, и теперь - к новому витку развития в виде композитной архитектуры. Особенно интересно наблюдать, как теоретические концепции находят свое практическое применение в реальных проектах, и как компании адаптируют архитектурные решения под свои конкретные задачи.
Введение: Почему мы возвращаемся к монолиту?
За последние годы микросервисная архитектура стала де-факто стандартом для enterprise-решений. Однако сегодня мы наблюдаем интересный тренд: крупные системы всё чаще возвращаются к монолитному ядру, сохраняя микросервисы лишь для определённых компонентов. Это явление требует детального анализа, поскольку оно отражает фундаментальные изменения в подходах к построению корпоративных систем.
Кризис микросервисной архитектуры
Проблема сложности
При внедрении микросервисной архитектуры одним из ключевых вызовов становится нелинейный рост сложности системы по мере увеличения количества сервисов. Этот феномен можно описать математически: для n сервисов потенциальное количество взаимодействий может достигать n(n-1)/2, что приводит к квадратичному росту сложности. Давайте рассмотрим основные факторы, которые приводят к увеличению затрат на разработку и поддержку микросервисной архитектуры.
Распределенные транзакции становятся первым серьезным вызовом при работе с микросервисами. В монолитной архитектуре транзакции обрабатываются в рамках единой базы данных, что обеспечивает надежную ACID-семантику. В микросервисной архитектуре каждая транзакция, затрагивающая несколько сервисов, требует реализации паттерна Saga или других механизмов распределенных транзакций. Это существенно усложняет разработку, так как команде необходимо продумывать и реализовывать компенсирующие транзакции для каждого возможного сценария отказа. Более того, тестирование таких сценариев требует значительно больше времени и ресурсов, чем тестирование обычных транзакций в монолите.
Согласованность данных представляет собой следующий уровень сложности. В микросервисной архитектуре данные распределены между различными сервисами, каждый из которых имеет собственное хранилище. Поддержание консистентности между этими хранилищами требует реализации сложных механизмов синхронизации. Разработчикам приходится иметь дело с временными несоответствиями данных, решать проблемы дублирования информации и обрабатывать конфликты при одновременном обновлении. Выявление и устранение аномалий в данных становится нетривиальной задачей, требующей специальных инструментов и процессов.
Версионирование API добавляет еще один слой сложности в микросервисную архитектуру. Каждый сервис может развиваться независимо, что приводит к необходимости поддерживать несколько версий API одновременно. Координация изменений между сервисами требует тщательного планирования и коммуникации между командами. Тестирование совместимости различных версий сервисов становится сложной задачей, а поддержка обратной совместимости требует дополнительных ресурсов на разработку и тестирование.
Инфраструктурная сложность также вносит существенный вклад в общие затраты. Для эффективной работы микросервисной архитектуры необходимо внедрять и поддерживать множество инфраструктурных компонентов: service discovery, системы конфигурации, средства мониторинга и трейсинга распределенных вызовов. Каждый из этих компонентов требует отдельного внимания при настройке, обновлении и поддержке. Отладка проблем производительности в распределенной системе становится существенно сложнее, так как необходимо анализировать взаимодействие множества компонентов.
Организационные вызовы часто недооцениваются при переходе к микросервисной архитектуре. Эффективная разработка и поддержка микросервисов требует высокого уровня координации между командами. Поддержание единых стандартов разработки, согласование изменений в API, координация релизов – все это требует дополнительного времени на коммуникацию и согласование. При этом растут затраты на документацию и обучение новых членов команды, так как каждый разработчик должен понимать не только свой сервис, но и принципы взаимодействия с другими компонентами системы.
С ростом системы комбинация этих факторов приводит к значительному увеличению времени разработки. Проектирование взаимодействий между сервисами, реализация распределенных механизмов, тестирование и отладка – все эти процессы занимают больше времени по сравнению с разработкой монолитной архитектуры. Требования к квалификации разработчиков также возрастают, что приводит к увеличению расходов на персонал. При этом растут затраты на инфраструктуру, инструменты мониторинга и поддержку системы в целом.
Отдельно стоит отметить проблему технического долга, который в микросервисной архитектуре имеет тенденцию накапливаться быстрее. Сложность в API и контрактах между сервисами, устаревшие версии протоколов, неоптимальные паттерны взаимодействия – все это постепенно усложняет процессы деплоя и откатов. С течением времени стоимость внесения изменений в систему растет, а эффективность команды разработки снижается.
В результате после определенного порога сложности затраты на разработку и поддержку микросервисной архитектуры начинают существенно превышать аналогичные затраты для монолитной архитектуры. Это особенно заметно в системах, где нет критической необходимости в экстремальном масштабировании отдельных компонентов. В таких случаях переход к композитной архитектуре может стать оптимальным решением, позволяющим сохранить преимущества обоих подходов при разумном уровне сложности системы.
Влияние AI на архитектурные решения
Появление и стремительное развитие искусственного интеллекта создает новые вызовы для микросервисной архитектуры и становится одним из ключевых факторов, влияющих на выбор архитектурных решений. Внедрение AI-функциональности в существующие системы требует пересмотра многих архитектурных принципов, которые ещё недавно считались неоспоримыми преимуществами микросервисного подхода.
Фрагментация данных, являющаяся естественным следствием микросервисной архитектуры, становится серьезным препятствием при работе с искусственным интеллектом. AI-модели требуют целостного представления о данных для эффективного обучения и формирования качественных предсказаний. Когда данные распределены между множеством независимых сервисов, каждый из которых хранит только свою часть информации, создание единой картины становится сложной технической задачей. Процесс сбора и консолидации данных из разных источников не только увеличивает латентность, но и создает риски несогласованности данных, что может приводить к некорректным результатам работы AI-моделей.
Особую проблему представляет обеспечение актуальности данных для AI-моделей в реальном времени. В микросервисной архитектуре, где каждый сервис может обновлять свои данные независимо, синхронизация изменений для поддержания актуального состояния становится критически важной. Традиционные подходы к обеспечению eventual consistency, хорошо работающие для обычных бизнес-процессов, могут оказаться недостаточными для AI-сценариев, требующих моментального доступа к актуальным данным.
Производительность также становится критическим фактором при интеграции AI в микросервисную архитектуру. Современные AI-модели часто требуют обработки больших объемов данных с минимальной задержкой. В распределенной системе каждый дополнительный сетевой вызов увеличивает общую латентность, что может сделать работу AI-функциональности неприемлемо медленной для конечных пользователей. При этом оптимизация производительности путем кэширования данных в микросервисной архитектуре сопряжена с дополнительными сложностями в обеспечении консистентности кэшей.
Вопросы безопасности и конфиденциальности данных приобретают новое измерение в контексте AI. Микросервисная архитектура, предполагающая множественные точки доступа к данным, усложняет контроль над тем, какие данные и каким образом используются AI-моделями. Необходимость обеспечения комплексной защиты персональных данных и соблюдения регуляторных требований становится дополнительным аргументом в пользу централизации критически важных данных.
Возрастающие требования к ресурсам для работы AI-моделей также влияют на архитектурные решения. Если раньше одним из ключевых преимуществ микросервисной архитектуры считалась возможность независимого масштабирования отдельных компонентов, то теперь этот подход может приводить к неэффективному использованию ресурсов. AI-модели часто требуют доступа к значительным вычислительным мощностям и большим объемам памяти, и распределение этих ресурсов между множеством сервисов может оказаться менее эффективным, чем их консолидация.
Тенденция к использованию предобученных моделей и инференсу в реальном времени также оказывает влияние на архитектурные решения. Предобученные модели часто требуют доступа к широкому контексту данных для точного инференса, что плохо согласуется с принципом изоляции данных в микросервисах. В результате возникает необходимость в создании централизованных хранилищ данных или сервисов-агрегаторов, что фактически возвращает нас к более монолитной архитектуре, по крайней мере в части управления данными.
Эксплуатация и мониторинг AI-компонентов в микросервисной архитектуре также представляют определенные сложности. Отслеживание качества предсказаний, выявление дрейфа данных и своевременное переобучение моделей требуют целостного взгляда на систему, который сложно обеспечить в сильно распределенной архитектуре. Это создает дополнительную нагрузку на команды разработки и поддержки, увеличивая операционные затраты.
В результате мы наблюдаем тенденцию к частичному возврату к монолитной архитектуре, особенно в части управления данными и AI-функциональности. Композитная архитектура, сочетающая преимущества обоих подходов, становится все более привлекательным выбором. Она позволяет централизовать критически важные данные и AI-функциональность в монолитном ядре, сохраняя при этом гибкость микросервисов для компонентов, где это действительно необходимо. Такой подход обеспечивает более эффективную работу AI-моделей при сохранении разумного баланса между сложностью системы и её производительностью.
Фундаментальный курс по проектированию систем с опорой на архитектурные принципы — «Архитектура приложений».
Комментарии (46)
nuclight
25.12.2024 19:25Ясен пень, как только кризис начинается, сразу из головы дурь про микросервисы выбивает. Квадратичный рост - фактически то же самое, что закон Брукса, только уже на командах.
Ну и забавно, как гордость не позволяет сказать "микросервисы были ошибкой, давайте вернемся к монолиту". Нет, надо обозвать повычурней, теперь "композитная архитектура"! Хотя ничего нового в вынесении некоторых отдельных компонентов в сервисы нет, десятилетиями применяется.
kivan_mih
25.12.2024 19:25Не совсем корректно смешивать классический монолит и модульный(композитный) монолит. В первом обычно из любого места проекта видно весь остальной проект, программисты активно этим пользуются и чем дольше, тем хуже клубок зависимостей получается, код становится неподдерживаемым. Модульный монолит фактически организован как микросервисы и вы не можете в любом месте использовать весь проект, только некоторую часть, которая доступна для этого места. Но при этом за счет композиции модулей в один бинарник, в котором разные модули общаются через память, вам не нужно тратить значительные ресурсы на организацию работы, версионирование и взаимодействие, что обычно происходит в случае микросервисов. Тем не менее, что важно - в грамотно организованном модульном монолите при желании вы легко можете собрать из модулей и несколько сервисов, просто заменив реализации контрактов их взаимодействия и не переписывая половину проекта.
Arlekcangp
25.12.2024 19:25Ну ок, модули... А как эти модули взаимодействовать то будут? Если опять через сеть, (или пайпы, что не сильно отличается) - то будут всë те же проблемы, что и с микросервисами. Отсутствие единой транзакции... Если через базу - ну так это классический монолит. Разве что внутри можно немного поделить модель, но практически это мало что даст. За монолитом сложнее следить, что бы он не превратился в большой коричневый ком. Думается, тут баланс нужен. И да, это работа архитектора, определить какие границы у сервисов. И правильно @nuclight написал - это старо как сам софт. Отделяли части приложения в отдельные слои/модули/сервисы, но называли иначе. От перемен названий проблемы сами не уйдут.
kivan_mih
25.12.2024 19:25Модульный монолит не про транзакции, он решает другую проблему - устраняет необходимость поддерживать медиаторы типа сервис меша, очередей, инфраструктуры для всего этого, поддерживать и мучаться с разными версиями сервисов, их разными жизненными циклами и так далее. Когда взаимодействие идёт просто через память без посредников, то о посредниках не надо думать, и это экономит много времени. Для небольших и средних компаний это бывает важно. Что касается транзакций, то если вы хотите делать транзакции между модулями, то возможно стоит перепроектировать.
nuclight
25.12.2024 19:25По-разному можно. В только что упомянутом биллинге о двух тыщах бинарей в основном это единая оракловая база (на самом деле четыре, но там разделение вида "здесь живёт мониторинг"), но многие взаимодействуют через файлы, некоторые через shared memory, и еще большой кусок через RPC от Tuxedo, но это для условных клиентов.
nuclight
25.12.2024 19:25Да кто вам сказал, что бинарник должен быть один, и что видимость определяется не волевым решением? У нас вон в биллинге опсоса под две тысячи бинарников, и при этом это вполне себе монолит "без конкретного уточняющего прилагательного", потому что об этом прилагательном никто не задумывался за отсутствием нужды - нет хайпа про микросервисы (ему более 30 лет, там код на Коболе есть), нет и нужды названия выдумывать.
kivan_mih
25.12.2024 19:25И как эти бинари взаимодействуют?
nuclight
25.12.2024 19:25kivan_mih
25.12.2024 19:25В таком случае я бы не стал называть приложение, состоящее из разрозненных бинарных файлов, потенциально имеющих разные версии, написанных на разных языках разными командами и по-разному взаимодействующих друг с другом монолитом. Для меня основным признаком монолита является то, что он работает через общую память и собирается как единое целое одной системой сборки, у чего есть понятные плюсы и минусы. Как только у вас появляются дополнительные части, пусть и лежащие на той же машине и работающие не через сеть, рассуждение об этом как о монолите может привести к неправильным выводам
nuclight
25.12.2024 19:25Нет, версия разумеется общая (у некоторых билдинг-блоков может быть своя, но это скорее для потенциальной возможности миграции меж заказчиками) - релиз единый идёт. Потому что не только репа общая (ну, оставляя в стороне вопрос RCS), но и система сборки общая - например, добавление одного домена (типы данных местные) приведет к соответствующей кодогенерации и соответственно изменениях через инклуды во всём проекте. Ну и база данных общая, конечно же.
Монолит - это прежде всего способ организации команд(ы) и работы с кодом, конкретные методы взаимодействия программных частей меж собой в рантайме не столь важны. К неправильным выводам может привести разве что рассуждение об этом в контексте микросервисов, которым, чтобы "продать", надо было обозвать как-то отличающееся, и побольше недостатков засунуть в свое определение, конечно. Это сродни тому как agile придумал нам "водопад" - не было ведь никакого водопада до того, на самом деле, ибо никто его так не называл. Просто надо было выдумать жупел, показать, чем мы отличаемся. Так же и с монолитами вышло.
lear
25.12.2024 19:25Вариаций реализации монолитов/микросервисов много. Ругать или хвалить стоит конкретные решения, но зачастую это будут субъективные плюсы и минусы для определенного проекта/задачи.
А вообще делайте как хотите и что хотите. Ведь неважно хороший или плохой вы сапожник, всё равно вы сделаете сапог и получите опыт. Теория тоже важна, но опыт сложнее получить.
PS. Я не говорю что не нужно учиться, Я за то, чтобы набивались шишки, а когда не будет хватать теории (будут конкретные проблемы), то её можно будет гораздо легче получить, нежели находиться в фрустрации и искать идеальное решение.
kivan_mih
25.12.2024 19:25В целом с автором согласен - "диктатура микросервисов" второй половины 10х годов - это штука ужасная и скольким командам она принесла больше вреда, чем пользы не перечесть, так что популяризация модульного монолита - это на мой взгляд действительно благо для индустрии. Что касается части про AI я не очень согласен, на своей практике даже если команда работала в рамках модульного монолита, AI/ML модули обычно выносили в отдельные сервисы со своим рантаймом по разным причинам, например потому что язык был другой или не хотелось тянуть очень тяжелые зависимости в основной бинарник и т.д.
Myz17
25.12.2024 19:25Архтектура - это искусство выбора компромисных решений для закрытия требований к продукту. Наивно думать, что если была причина перехода на микросервисы, то в один прекрасный день, можно взять и переписать всё в монолит.
kivan_mih
25.12.2024 19:25Причиной было то, что крупным компаниям, где сотни и тысячи разработчиков работают над одной экосистемой без микросервисов никак и они стали популяризовать этот подход, чтобы сразу с рынка брать знакомых с ним людей. Компаниям со значительно меньшими отделами разработки это было далеко не так необходимо, но повинуясь моде и давлению крупных компаний (все конференции были только про микросервисы в те времена), во многих мелких компаниях начинали без разбора переходить на микросервисы. Из самых плачевных результатов, которые я встречал: люди занимаются прослойками - чинят очереди, ковыряют кубер, сравнивают версии микросервисов и ищут в них нестыковки, а бизнес фичи стоят по несколько спринтов.
Konstantin1978
25.12.2024 19:25Это говорит о чем? О том, что умение программировать на java еще не означает умение думать головой и анализировать. Это был фееричный исторический пример crapification, где тысячи "инженеров" обгадились.
nuclight
25.12.2024 19:25А причем тут конкретно Java? Хотя, конечно, с ней миллионы гадятся с 90-х...
kivan_mih
25.12.2024 19:25Java вообще не при чем. Первый микросервайс хел, который я увидел, был на ноде. Что касается инженеров и думать головой - нужен архитектор, кто придумает, как оно всё вместе будет работать вместе. К инженерам, которые пишут непосредственно код на любом языке, это не имеет отношения.
Myz17
25.12.2024 19:25причём тут команды? микросервисы это же не про разделение задач в разработке. И монолит можно писать десятком команд. И оно даже часто так и пишется. А как вы монолит масштабировать будете? Целиком в сотне инстансов? Даже если масштабировать нужно буквально одну функцию?
nuclight
25.12.2024 19:25Ну вообще, для менеджмента - это в основном как раз про разделение на команды.
А масштабирование "монолита" проблемы не составляет (да, берем и масштабируем инстансы, даже если на инстансе сконфигурена всего одна функция), кроме вырожденных случаев, когда там статический бинарь за 4 гига и т.п.
kivan_mih
25.12.2024 19:25Микросервисы - это в первую очередь про управление командами и определенную интерпретацию принципа разделяй и властвуй для больших компаний. Когда компания и отдел разработки маленькие всё это теряет смысл и прослойки начинают съедать больше ресурсов, чем полезная нагрузка.
Konstantin1978
25.12.2024 19:25А я всегда говорил фанатам микросервисной архитектуры: "Ребята, вы хоть один пример из реального мира (желательно природы) микросервисной архитектуры можете привести? Не можете! Так как эволюцией и временем доказано что микросервисная архитектура не жизнеспособна сама по себе и проигрывает монолитам." Есть примеры в природе взаимодействия монолитов, но микросервисов нет!
nuclight
25.12.2024 19:25А как бы оно вообще могло выглядеть в природе, где нет никаких API, хоть даже с теми же монолитами ? Рой пчёл/муравьев сойдет?
Konstantin1978
25.12.2024 19:25Рой пчел/муравьев это как раз пример взаимодействия монолитов, стая волков тоже еще один пример. Вы должны назвать рой, где нет одинаковых особей и где все выполняют разные функции. Таких примеров нет. Насчет API, в природе роль API выполняет язык на котором происходит общение.
Delphis
25.12.2024 19:25На самом деле рой пчел больше похож на микросервисы, пчелы делятся по функциям, они не одинаковые, есть пчелы разведчики, есть пчелы которые нектар собирают, есть солдаты, есть те кто соты строит и так далее там у них сложная конструкция. И АПИ есть, пчелы могут передавать информацию через феромоны и через танец, например разведчики танцем показыают рабочим пчелам куда лететь за нектаром.
Но в данном случае пчелы - это скорее исключение которое подтверждает правило. Пчелы со своей микросервисной архитектурой очень уязвимы и не захватили мир, а захватил мир монолитный человек благодаря ИИ в мозгуKonstantin1978
25.12.2024 19:25Вы назвали всего четыре функции разных пчел, но в рое пчел сотни тысяч, тогда и функций должно бцть сотни тысяч, либо мы имеем "дублирование програмного кода" в данном примере.
AlekseyKuzmin
25.12.2024 19:25Мне кажется, что группа пчел одного типа (разведчики, собиратели и т.п.) похожа на скейлинг (scale) в микросервисной парадигме. Можно поднять от 1 до 1000 инстансов одного микросервиса, если того требует нагрузка. Код в данном случае не дублируется, а масштабируется производительность отдельного функционала системы. Причем горизонтально масштабируется, решая попутно проблему резервирования и отказоустойчивости.
Konstantin1978
25.12.2024 19:25Т.е. в итоге мы имеем 4 сервиса и 1000 инстансов каждого из них. А почему тысячу? Не маловато будет? Ведь в рое сотни тысяч пчел! Должно быть 25 000 инстансов!
Проблема большинства людей в том, что они не умеют считать. Достаточно взять в руки калькулятор, как абсурдность многих предположений и идей сразу становится очевидна. Как бы вы не пытались натянуть сову на глобус, но мат.расчеты не позаолят вам это сделать. Пчелы - это не микросервисы.
AlekseyKuzmin
25.12.2024 19:25Все зависит от задачи и размеров проекта.
Давайте представим, что нам нужно создать бекенд платформу для чат-приложения (такого как whatsapp/telegram). В этой платформе нам нужен тип микроссервиса который будет отвечать за websocket соединения от клиентских приложений. Этот серис должен принимать сообщения от клиентских приложений, доставлять адресованные сообщения. Предположим, что с учетом ограничений по железу, один сервис способен обсуживать, например, 10К онлайн клиентов. (ремака по железу: обычно много маленьких серверов дешевле, чем они супер мощный).
Представим, что в первое время аудитория нашего чат-приложения будет 100К пользователей. Для них нам нужно поднять 10 инстансов сервиса.
Далее возникает вопрос масштабированиея системы с ростом полулярности - нам нуужно большк инстансов.
Вот у Телеграм 950 млн пользователей. Для обслуживания такой аудитории 25К инстансов может быть мало.Konstantin1978
25.12.2024 19:25Здесь не микросервисы, а репликация, масштабирование единственного сервиса. В вашем примере нет микросервисов. Не понимаю для чего вы пытаетесь подменить понятия.
nuclight
25.12.2024 19:25Как забавно наблюдать "не умеют считать" на примере этого же самого сообщения. Нет в рое "сотен тысяч" пчёл. Не поместятся в улей.
Konstantin1978
25.12.2024 19:25Это в вашем суженном представлении нет. Пойдите на пасеку и посмотрите сколько там всего улей и посчитайте сколько всего пчел. Я же говорю, люди считать не умеют, какой смысл сними вообще о чем то говорить.
Delphis
25.12.2024 19:25На самом деле, там все интереснее. В улье действительно больше специализаций пчел - есть уборщицы которые чистят ячейки, кормилицы для личинок, пчелы-регулировщики которые вентилируют улей и поддерживают температуру, пчелы-водоносы, пчелы-приемщицы которые забирают нектар у сборщиц и сгущают его в мед, пчелы-строители, пчелы-разведчики, пчелы-охранники на входе, пчелы-санитары которые выносят умерших, есть даже специальные пчелы которые запечатывают соты воском. Кроме рабочих пчел есть еще матка, которая отвечает за воспроизводство всей системы, и трутни, у которых своя специализированная роль
А по поводу дублирования - тут как раз работает правильный скейлинг, как в микросервисах. Если нужно больше меда - улей увеличивает количество пчел-сборщиц. Если идет активное строительство сот - больше строителей. То есть "инстансов" каждого типа пчел ровно столько, сколько нужно под текущую задачу.
И насчет количества - в улье обычно 20-60 тысяч пчел, а не сотни тысяч. Это как раз нормальное количество микросервисов для крупной системы, где каждый тип сервиса масштабируется отдельно под нагрузку.
Так что аналогия с микросервисами очень точная - специализированные юниты, свои протоколы общения, автомасштабирование под нагрузку. Другое дело что такая система реально сложная в поддержке, стоит матке заболеть - и всё, привет. И наверное поэтому пчелы так и не захватили мир - один монолитный медведь может запросто уничтожить несколько десятков распределенных микросервисных ульев. А уж когда появились модульно организованные люди, которые научились создавать крупные монолитные структуры вроде сельского хозяйства - пчелы вообще оказались на грани выживания как вид. Потому что против огромной согласованной системы вроде промышленного земледелия с пестицидами даже идеально организованная микросервисная архитектура улья оказалась бессильна.
nuclight
25.12.2024 19:25в природе роль API выполняет язык на котором происходит общение.
Я тонко намекал о некорректности аналогии, придется уже толсто. Не выполняет. *Язык* есть только у человека, у остальных лишь сигнальная система. И API оно тоже не является, более корректным является понятие протокол (впрочем, это сокращение вообще в нынешнем Вебе обычно применяется неверно).
А из некорректной аналогии следуют дальнейшие логические ошибки. Например:
Вы должны назвать рой, где нет одинаковых особей и где все выполняют разные функции.
С чего такое требование взялось вдруг? Более того, микросервисы нередко продают под соусом как раз масштабирования одинаковых инстансов одной функции (вона, половина хайпа всяких, простите за выражение, кубернетесов именно об этом).
Если пофилософствовать абстракциями, то исходное объектно-ориентированное программирование - передача сообщений - было забыто (нет, Java и C++ не оно), потом переродилось в виде акторов и дальше в идею микросервисов. Аналогия роя - из максимально простых объектов - как раз очень даже подходит тут.
Фанатам микросервисов надо было показывать ту гифку, что на днях в телеге ходила, где рой муравьев очень долго протаскивает двутавр через лабиринт - вот, посмотрите, какое оно неффэективное по сравению с монолитной обезьяной. Вы же рассуждениями пошли в какую-то совсем неверную сторону.
Delphis
25.12.2024 19:25А вот насчет распределенных систем интересное замечание. Смотри - у тех же пчел и муравьев распределенная система возникла не от хорошей жизни, а потому что один маленький муравей или одна маленькая пчела физически не могут решить большую задачу. У них просто нет выбора, они обязаны кооперироваться.
А у человека есть мощный процессор в голове, который позволяет решать сложные задачи монолитно. И когда мы делаем микросервисы - мы как бы добровольно отказываемся от этого преимущества, разбивая простую задачу на много маленьких. Это как если бы человек вместо того чтобы просто взять и поднять бревно, начал бы бегать вокруг него кучей маленьких человечков.
Поэтому сравнение с роем не очень корректное - рой это вынужденное решение из-за ограничений отдельной особи. А микросервисы это когда мы сами себе создаем сложности, разбивая монолит на кучу мелких сервисов, а потом героически эти сложности преодолеваем.
И кстати, муравьи с двутавром это отличный пример - они конечно затащат его куда надо, но это будет стоить огромных усилий по координации. А один человек с нормальным мозгом просто возьмет и перенесет его, потому что может просчитать траекторию и все сделать эффективно.
nApoBo3
25.12.2024 19:25Покажите мне природную систему которую возможно поддерживать и направленно изменять, или хотя бы тестами покрыть.
gexeg
Миллион связей внутри, миллион связей наружи.. хрен редьки не слаще..
Проектироварие это грязная проблема, проектирование это эвристика, а не алгоритм. Вот здесь то собака и зарыта. Проще говоря - заставь дурака молиться, он и лоб расшибет (нашлепает бездумно микросервисы, монолиты, композиты и все что хочешь)
Delphis
У вас в голове миллиарды синапсов образуют связи и тем не менее вы можете легко получить доступ к тому что знаете, а вот в больших организациях где знания распределены по головам тысяч или даже всего лишь сотен человек собор знаний требует больших усилий и уж точно не быстрый, как орг структуру не проектируй и какие процессы не внедряй.
nuclight
Может, потому что "бизнес" просто забивает на это? Может, в других оргструктурах с этим получше?
gexeg
Кто сказал, что я могу легко получить доступ к знаниям? Что такое легко?
При чем здесь мой комент и статья?
Delphis
Вы извините, я возможно не верно вашу мысль понял про "Миллион связей внутри, миллион связей наружу.. хрен редьки не слаще". Мне кажется что разница есть и она принципиальная, если смотреть с точки зрения системы принятия решений.
Когда у вас монолит (как человеческий мозг), то доступ к данным и принятие решений происходят очень просто - ваш мозг просто берет и обрабатывает всю информацию что есть в памяти. Вы не управляете этим специально, у мозга просто есть прямой доступ ко всем знаниям, поэтому решения принимаются быстро - либо моментально, либо за несколько минут подумав.
Да, иногда можно биться над решением часами или днями, но это обычно когда не хватает какой-то информации. А вот если вся информация есть - монолитный мозг думает быстро.
А теперь посмотрите как работает большая корпорация с микросервисной архитектурой - там быстрых решений вообще не бывает. Работает целая система сбора и подготовки данных: сначала отделы строят отчеты и шлют их в департаменты, там эти отчеты собирают и обрабатывают, потом отправляют наверх. Там на основе этого строят стратегии, передают их в менеджмент борд, и только там принимаются решения. При этом часто даже делаются обратные запросы, которые запускают весь этот процесс по новой.
Вот это второе - и есть типичный пример микросервисной архитектуры, где каждый шаг принятия решения требует кучи согласований и передачи данных между сервисами.
Так что, позволю себе не согласиться с тем, что внутренние и внешние связи - это "хрен редьки не слаще". Внутренние связи обеспечивают мгновенный доступ к данным и эффективное принятие решений, в то время как внешние связи неизбежно создают существенные накладные расходы на коммуникацию и координацию. Это особенно критично для систем с искусственным интеллектом, где скорость доступа к данным напрямую влияет на эффективность принятия решений.
И вы абсолютно правы насчет того, что проектирование - это грязная эвристическая проблема, а не алгоритм. Именно поэтому так важно понимать фундаментальные принципы и ограничения разных архитектурных подходов, а не просто следовать модным трендам. Потому что иначе действительно получится как в поговорке про молитву и лоб - можно и микросервисов наделать где не надо, и монолит раздуть до невменяемого состояния. Архитектура должна следовать за реальными потребностями системы, а не за абстрактными принципами.
PS. Я автор той статьи которую мы комментируем, если что.