Микросервисы или монолит? Споры об архитектуре программного обеспечения не утихают, но с 2018-2020 годов наметился интересный тренд: компании начинают переоценивать сложность микросервисного подхода. Возвращение к монолитам, но уже с учетом современных инструментов, вызывает жаркие обсуждения в техническом сообществе.
В этой статье я не буду защищать какую-либо из сторон. И не буду обещать волшебных решений, которые решат все архитектурные проблемы. Вместо этого разберем, что стоит за модной концепцией «монолиты 2.0», как эволюция технологий меняет восприятие архитектуры и почему возвращение к упрощению может быть выгодным. Добро пожаловать в мир архитектурных компромиссов — подробности под катом.
Эволюция архитектур
Переход от монолитов к микросервисам начался чуть более 10 лет назад, когда компании стали осознавать необходимость более гибких решений для сложных приложений. Микросервисы стали популярными благодаря своей способности справляться с высокими нагрузками и обеспечивать быстрое развертывание новых функций.
Однако с ростом числа микросервисов возникли новые вызовы: управление зависимостями, сложность инфраструктуры и высокие затраты на поддержку. Согласно Gartner, более 70% компаний, внедряющих микросервисы, сталкиваются с проблемами масштабирования DevOps-процессов, что приводит к увеличению времени разработки и операционных расходов.
Так мы пришли к гибридным моделям — модульным монолитам и микрофронтенду, а также вернулись к обновленным версиям монолитов, известным как монолиты 2.0. Эти решения стремятся сочетать лучшие качества микросервисов (гибкость) и монолитов (простота).
Хайп-цикл Gartner. Источник .
Кейсы успешных монолитов
Несмотря на свои ограничения, многие успешные компании продолжают использовать монолиты. Взглянем на примеры.
Stack Overflow — платформа для вопросов и ответов, запущенная в 2008 году. В 2024 году она обслуживает более 50 миллионов уникальных пользователей в месяц и имеет более 14 миллионов вопросов и ответов, а также более 5 миллионов новых вопросов в год.
Использование монолитной архитектуры позволило команде сосредоточиться на разработке функционала, который привлек пользователей. Простота разработки и возможность быстрого развертывания новых функций способствовали росту платформы.
Источник.
GitHub, основанный в 2008 году, стал крупнейшей платформой для совместной разработки программного обеспечения. На начало 2024 года GitHub имеет более 40 миллионов активных пользователей и хранит более 100 миллионов репозиториев.
Монолитная структура упростила управление кодом и позволила быстро внедрять изменения. GitHub обрабатывает более 40 миллионов запросов на пул (pull requests) каждый месяц, что подчеркивает его активное использование и необходимость высокой производительности.
Shopify была основана в 2006 году и на начало 2024 года обслуживает более 1,7 миллиона активных магазинов по всему миру. В 2023 году объем продаж через платформу составил более 61 миллиарда долларов.
Использование монолита позволило Shopify быстро реагировать на изменения рынка и внедрять новые функции. Платформа продолжает демонстрировать высокую производительность даже при значительном росте пользователей.
Источник.
Кейсы успешных микросервисов
Теперь посмотрим на известные компании, применяющие микросервисную архитектуру.
Netflix управляет более чем 800 микросервисами, обрабатывающими задачи от видеотранскодирования до персонализированных рекомендаций. Этот подход обеспечивает компании гибкость и позволяет оперативно масштабировать серверные мощности во время пиковых нагрузок — например, при выходе популярных сериалов. Однако такая архитектура создает сложные задачи для мониторинга и поддержки. По данным TechRadar, Netflix ежегодно инвестирует миллионы долларов в инструменты DevOps и инженеров, чтобы поддерживать стабильность своей инфраструктуры.
Uber применяет сотни микросервисов для функций, включая геолокацию, обработку платежей и управление водителями. Это решение доказало свою эффективность в условиях высокой нагрузки — например, во время крупных мероприятий или праздников. Однако, как отмечает DZone, сложность интеграции различных сервисов требует значительных ресурсов, включая команды инженеров и мощные инструменты для оркестрации вроде Kubernetes.
Пример сложного потока в Uber, где для простой интеграции до DOMA требовалось 10 точек соприкосновения.
Микросервисная архитектура Uber примерно в середине 2018 года. Источник.
eBay перешел на микросервисную архитектуру, чтобы повысить масштабируемость и сократить время вывода новых функций на рынок. Например, переработка страницы аукциона заняла всего несколько недель благодаря микросервисам. Однако, как сообщает Gartner, управление сотнями сервисов увеличило затраты на инфраструктуру и разработку более чем на 30%. Это привело компанию к необходимости внедрения новых подходов к оптимизации.
Что такое монолиты 2.0
Понятно, что монолиты 2.0 — это какой-то обновленный подход к созданию монолитных приложений. Но что именно там нового? Чаще всего подразумевается внедрение контейнеризации и модульности.
Тот же Docker позволяет упаковывать приложение вместе со всеми его зависимостями в единый контейнер. Это обеспечивает согласованность среды разработки и развертывания, а также упрощает управление версиями.
Модульный подход внутри единого приложения означает, что различные функциональные модули могут быть разработаны и протестированы независимо. Это должно снизить сложность разработки и позволить командам работать параллельно. Кроме того, благодаря модульному подходу команды смогут быстрее разрабатывать и тестировать отдельные компоненты приложения. Хоть это и теория, но так можно сократить время на вывод продукта на рынок.
Звучит все, конечно, здорово. Но как это реализовать? На сегодняшний день доступно несколько инструментов.
Spring Boot. Этот фреймворк для Java, который упрощает создание приложений с минимальными усилиями по конфигурации. Spring Boot поддерживает создание независимых приложений со встроенными серверами и предоставляет множество возможностей для интеграции с облачными сервисами.
Ruby on Rails. Rails — это мощный фреймворк для веб-разработки, который способствует быстрой разработке за счет использования конвенций вместо конфигураций. Он идеально подходит для создания прототипов и малых проектов, а также поддерживает модульность через гемы (плагины).
Laravel. Этот PHP-фреймворк известен своим элегантным синтаксисом и мощными инструментами для работы с базами данных через Eloquent ORM. Laravel также предлагает средства для тестирования и управления зависимостями, что делает его идеальным выбором для разработки современных веб-приложений.
Тренды 2024: почему это стало актуально
В 2024 году наблюдается несколько ключевых трендов, способствующих возрождению интереса к монолитам. В мире технологий каждый тренд рано или поздно вызывает обратную волну. После нескольких лет доминирования микросервисов монолиты 2.0 вновь стали обсуждаемой темой. Что их делает актуальными именно сейчас?
Отчасти этому способствует упрощение DevOps-процессов. Микросервисы требуют сложной оркестрации, множества инструментов и постоянного мониторинга. Компании, уставшие от этого, начали искать более простые решения. Монолиты 2.0 возвращают контроль в одни руки: меньше инструментов — меньше проблем. Согласно данным Forrester, переход на оптимизированную архитектуру позволяет сократить до 25% времени на DevOps-операции.
Другой важный фактор — экономия ресурсов. Это тренд не только в бизнесе, но и в архитектуре. Компании хотят снизить затраты на поддержку инфраструктуры на 15–20%. Как отмечает Deloitte: «Вместо борьбы с полусотней микросервисов компании экономят миллионы, переходя на оптимизированные монолиты».
Наконец, существует спрос на быстрое развертывание. Время — деньги, особенно в мире технологий. Быстрые обновления стали синонимом конкурентного преимущества. Если ты внедряешь изменения быстрее конкурентов, ты выигрываешь. McKinsey отмечает, что компании теряют до 30% пользователей, если новые функции выходят с задержкой.
Получается, монолиты 2.0 — это не шаг назад, а переосмысление архитектуры под современные задачи. Они позволяют быть гибкими и быстрыми, сохраняя бюджет и упрощая разработку. Возможно, это и есть тот баланс, которого не хватало микросервисам.
Будущее архитектуры: компромисс или крайность?
Уже сейчас можно видеть рост интереса к гибридным подходам, которые сочетают в себе элементы монолитной и микросервисной архитектур. Они позволяют компаниям адаптироваться к изменениям без необходимости полного перехода на одну из сторон.
Микросервисы изначально являются менее производительной архитектурой из-за накладных расходов на обслуживание. По мере роста монолита он становится сложнее. Источник.
Гибридная архитектура — это компромисс между монолитами и микросервисами, который позволяет использовать преимущества обоих подходов. В этом контексте можно выделить два основных варианта.
- Гибридный монолит. Основная часть функционала приложения реализована в виде монолита, но для некоторых сложных задач используются микросервисы. Например, веб-приложение может быть построено как монолит, а функции, требующие высокой производительности или масштабируемости, могут быть вынесены в отдельные микросервисы.
- Микросервисные модули. Монолитное приложение разбивается на отдельные функциональные компоненты, которые реализованы в виде микросервисов. При этом некоторые функции остаются внутри монолита. Это позволяет постепенно мигрировать с монолита на микросервисы, минимизируя риски и затраты.
Модуляризация помогает проектировать лучшие монолиты и микросервисы. Без тщательно определенных модулей мы либо попадаем в традиционный многослойный монолит, либо, что еще хуже, в распределенный монолит, который сочетает в себе худшие черты монолитов и микросервисов. Источник.
По данным исследования McKinsey, более 60% компаний, использующих гибридные подходы, отметили улучшение скорости разработки и гибкости системы при одновременном снижении затрат на поддержку.
Эксперты прогнозируют[a] несколько ключевых трендов в области архитектуры программного обеспечения. Один из них уже упомянут — рост интереса к гибридным решениям. Ожидается, что гибридные архитектуры будут становиться все более популярными среди компаний, стремящихся к оптимизации затрат и повышению гибкости. По прогнозам Forrester Research[b], к 2025 году более 75% компаний будут использовать гибридные модели для разработки своих приложений.
Еще один тренд — увеличение использования облачных технологий. Облачные вычисления продолжат развиваться, предоставляя компаниям новые возможности для хранения данных и обработки информации. Ожидается, что объем облачных услуг вырастет на 25% в год в ближайшие пять лет.
Интеграция IoT и периферийных вычислений: Увеличение числа устройств IoT требует новых подходов к обработке данных. Периферийные вычисления помогут снизить нагрузку на центральные серверы и улучшить производительность систем. Прогнозируется, что к 2026 году количество подключенных IoT-устройств достигнет 30 миллиардов.
Безопасность как приоритет: С увеличением числа кибератак компании будут уделять больше внимания безопасности своих приложений. Ожидается рост инвестиций в инструменты для обеспечения безопасности, такие как автоматическое обнаружение угроз и шифрование данных.
Будущее архитектуры программного обеспечения будет определяться гибридными подходами, которые позволяют компаниям адаптироваться к изменениям без необходимости полного перехода на одну из архитектур. Технологии, такие как Kubernetes и AI, будут играть ключевую роль в этом процессе, обеспечивая гибкость и эффективность разработки.
Компании должны быть готовы к изменениям и активно интегрировать новые технологии для повышения своей конкурентоспособности на рынке. Гибридные архитектуры представляют собой оптимальное решение для тех организаций, которые стремятся сочетать преимущества монолитов и микросервисов при минимизации рисков и затрат на поддержку.
Заключение
Источник.
Когда смотришь на эволюцию архитектур, понимаешь, что технологии всегда движутся по кругу. Возвращаясь к старым идеям, но с новым смыслом. Монолиты 2.0 — это как раз про это: не шаг назад, а переосмысление прошлого под реалии настоящего.
Гонка за микросервисами привела к важному выводу: универсального подхода не существует. Гибридные архитектуры, которые мы видим сегодня, — это попытка найти золотую середину. Они показывают, что иногда лучше комбинировать идеи, чем пытаться встроиться в жесткие рамки одного подхода.
На мой взгляд, основной тренд ближайших лет — это прагматизм. Компании все чаще выбирают то, что действительно работает для их задач, а не то, что звучит модно. Если нужен быстрый запуск — выбирают монолит. Если важна масштабируемость — микросервисы. Если бюджет ограничен, то гибриды, которые могут дать баланс между затратами и эффективностью.
Личный инсайт: технологии — это всегда про людей и их потребности. Архитектура должна решать проблемы бизнеса, а не создавать новые. Если у вас есть задача, которую можно решить проще, не бойтесь отойти от модных решений и сделать так, как действительно удобно.
И, возможно, главное: не стоит зацикливаться на трендах. Через пару лет мы, скорее всего, увидим очередной виток архитектурных подходов, который снова перевернет все наши представления. Поэтому важно оставаться гибкими, но помнить о целях.
А как вы считаете, куда приведет эволюция архитектур — к гибридному будущему или очередному повороту к «старому-новому»? Делитесь своими мыслями в комментариях, ставьте реакции и давайте обсудим!
Комментарии (73)
LexD1
31.12.2024 11:52универсального подхода не существует
Как бы, да.
Выбор инструмента зависит от целей, потребностей, возможностей.
atues
31.12.2024 11:52Чистый монолит это, наверное, зло злющее, но это работает. По крайней мере, он мало зависит от наличия и квалификации девопсов: достаточно сервера приложений вроде wildfly. Зато мало проблем с распределенными транзакциями, оркестрацией и коммуникациями между модулями.
Чистые микросервисы - это нечто вроде всем известного сферического коня. В условиях "давай-давай" и "выпускаем в продакшен, а после отрефакторим и допилим" они в подавляющем большинстве случаев досточно быстро превращаются в редкостную помойку из костылей. Плюс очень высокая зависимость от квалификации девопсов. Только в книжках все гладко и кучеряво. На деле, увы - там не завелось, тут отвалилось, здесь легло, токены протухли. Особенно при развертывании в коммунальных средах, когда ресурсы централизованы и выделяются по заявкам.
Может быть, мне просто не везло :)))
cheshirskins
31.12.2024 11:52быстро превращаются в редкостную помойку из костылей.
Это же в большей степени свойственно монолиту, разве нет? В случае микросервисного подхода при разработке нового можно учесть ошибки предыдущих и внести существенные изменения в архитектуру. Также можно постепенно, по мере необходимости, и относительно просто переносить функциональность со старого сервиса на новый. Да, с оркестрацией могут возникнуть трудности, но это всё-таки проще, как по мне, чем копаться в легаси, особенно когда оно без документации и написано без типизации.
dph
31.12.2024 11:52Ну, рефакторинг монолита обычно проще (на нормальных языках). В микросервисах любые изменения за пределами одного микросервиса становятся крайне сложными.
Так что микросервисы протухают, обычно, много быстрее. Обычно - еще до выхода в продакшен (cheshirskins
31.12.2024 11:52С микросервисами основная проблема заключается в плохой коммуникации между разработчиками. Например, когда за сервис отвечает разработчик, которому все равно или который не хочет идти на компромисс, а иногда такой разработчик вообще находиться в другом отделе и нормальная коммуникация с ним невозможна. При грамотной организации работы хорошо реализуется принцип разделения интерфейсов и вносить изменения можно относительно бесполезно.
atues
31.12.2024 11:52Вот оно, ключевое "внести существенные изменения в архитектуру". Когда код миновал стадию MVP и получил одобрение, то какая причина изменять архитектуру? Ведь работает же вроде, чего там менять. Заказчик именно из этого и исходит. А настоящие мины вылазят, как правило, потом. Прилетают новые требования. На полпути меняется база данных. Вместо "кролика" решают перейти на kafka... Уходят ключевые разработчики. Переделка архитектуры это выброшенное время, труд, деньги и настроение. Нет уж, допиливайте что есть, а там - будем поглядеть.
Не подумайте, я не топлю за монолит в противовес микросервисам (и наоборот). Если есть время, хороший архитектор (подчеркиваю - хороший, т.е. не брехло, выучившее модные словечки вроде DDD, gRPS, Reactive, Streams и т.п., а реально щупавший это), то и монолит, и микросервис можно сделать конфеткой. Конечно, я помню и о том, что нужен качественный системный анализ: для разработчиков это - даже в первую очередь.
Тема такая, что спорить тут можно до хрипоты и никто никого не переубедит, т.к. все зависит от множества факторов. Но можно и монолит сделать изящно. А можно и нет. Аналогично с микросервисамм
alteest2
31.12.2024 11:52Самое частая проблема это когда производительность в одном месте упёрлась и дальше вертикально скейлить уже дорого. Да, можно горизонтально скейлить весь монолит, но иногда монолит слишком большой, а иногда это не просто именно из за архитектуры и нужно все равно допивать, чтобы монолит нормально горизонтально скейлился. Тогда уже проще выделить в отдельный сервис только то куда упёрлись и то что нужно скейлить
un1t
31.12.2024 11:52Монолиты умеют скейлиться горизонтально, особенно, если изначально так проектировать.
MonkAlex
31.12.2024 11:52Не только проектировать, но и реально использовать. Иначе всё равно будут баги, когда спроектировали, но на местах налажали.
alteest2
31.12.2024 11:52Не всегда. Запихни в монолит ML часть (а такое бывает сплошь и рядом) и потом начинается: нам нужно куча CPU, и памяти, но только час в сутки и приходится платить за дорогой инстанс который используется по полной лишь малое количество времени. Не все могут/хотят выкидывать деньги на ветер. Проще выпилить часть в сервис и скейлить уже его, задеплоив оставшуюся часть на дешёвый инстанс
cheshirskins
31.12.2024 11:52Я с вами согласен. Просто я изхожу из позиции начинающего разработчика, который, в основном, дорабатывает существующие решения. В случае микросервисов при применении грамотной архитектуры, новичку проще разделить приложение на составляющие и, соответственно, проще влиться в проект.
Format-X22
31.12.2024 11:52Микросервисы хороши когда ты большой и сервер уже не влезает в терабайт оперативки, а работать надо. И/или когда ты ещё и международная корпорация и надо по всей планете сервера, причем не везде нужны полные функции. И всё прекрасно.
А потом приходят любители карго-культа и говорят мол смотрите, гугол на микросервисах и успешен. Мы же хотим быть успешными как гугол. Будем делать микросервисы.
А потом тебя на собесе не берут на работу потому что ты стар и как это монолит тут лучше, все же используют микросервисы.
Но рыночек порешал - когда в деньгах становится понятно что микросервисы стоит строить на первые сто миллионов прибыли и никак не раньше - сразу становится понятно как чего. Ну и хайп сходит потихоньку.
Конечно есть исключения где лучше брать микросервисы на старте. Ещё кто-то может сказать что отдельный микросервис может разрабатывать отдельная команда, удобно. Только вот… это называется сервис, не микро, просто сервис.
Приятно слышать что спадает хайп. Я в нем поболтался какое-то время, оценил плюсы и минусы. Из неожиданных плюсов назову тот что для однопоточных языков может быть неплохой кейс с нарезкой по функциональным микросервисам и тогда некоторых микросервисов мы создаем больше инстансов, а других, менее нагруженных - меньше. Особенно хорошо когда это в монорепозитории лежит и по факту это многопоточность на уровне серверов, вместо приложения.
А вот из минусов, о которых почти все забывают - огромные расходы коммуникаций. Это же надо данные подготовить, сериализовать в протокол, отправить по сети, иногда на другую машину у другой стойке, там обработать пакет, десериализовать, обработать данные и потом также назад с ответом. Огромное количество мусорных вычислений. Кто об этом задумывается? Мало кто. А деньги то горят там по чуть-чуть. Про отладку запроса что идет через тройку микросервисов насквозь - вообще молчу.
С другой стороны когда ты гугл - это всё очень нужно, иначе ты не сможешь держать столько функций вместе. Это неизбежно, это эволюция роста. И тогда микросервисы делают своё дело. Так что я рад что прозревает сообщество потихоньку.
BugM
31.12.2024 11:52А вот из минусов, о которых почти все забывают - огромные расходы коммуникаций
Сюда же огромное увеличение сложности управления надежностью.
Большой сервис зависит от нескольких БД и какой-нибудь Кафки. Пока они работают, он тоже должен работать. Просто и понятно. Делать надежные БД люди уже десятилетия умеют.
А вот микросеррвис зависящий от пяти других микросервисов (которые в свою очередь от чего-то зависят) это проблема. Как определить его надежность? Что должно ломаться если сломалась зависимость? Как сделать эту систему не менее надежной чем систему зависящую только от БД?
И сюда же сложность эксплуатации. Я в живую видел людей годящихся несколькими своими микросервисами которые держат десятки тысяч РПС. Они же рассказывали что Джава не ок, мол у нас нагрузки. При этом у них входной пользовательский РПС дай бог пара сотен. Остальное они сами внутри накрутили. На предложение найти эти десятки тысяч РПС и снизить хотя бы до тысяч (это точно возможно) меня посылали очень далеко. Мол у них продуманная и очень правильная архитектура системы.
В итоге я пришел к выводу что самые надежные и понятные системы это системы с зависимостями только через БД. Кафку тоже БД считаем. Все взаимодействие по АПИ со внешними системами надо выносить куда-то в асинхронный код.
Пришел запрос от юзера для обработки которого нужно в три внешних сервиса сходить? Положите его в Кафку и другим сервисом прочитайте и сходите куда надо. Если даже внешние системы упадут вы не потеряете запрос юзера и покажете ему что все сохранено, ожидайте. Это приятнее чем ловить пятисотки.
atues
31.12.2024 11:52Положите его в Кафку и другим сервисом прочитайте и сходите куда надо. Если даже внешние системы упадут вы не потеряете запрос юзера и покажете ему что все сохранено, ожидайте
Именно так. И не только запросы юзера, но и внутренние взаимодействия между сервисами
dph
31.12.2024 11:52И да и нет.
Асинхронное взаимодействие с состоянием более хрупкое (проще сломать) и сложнее в администрировании. Синхронное в современных условиях, при наличии оркестрации в стиле Temporal - самый простой способ работы в современных распределенных системах.BugM
31.12.2024 11:52Темпорал классный. Он как раз про асинхронность в том смысле как я это слово использовал. Вы сохранили запрос юзера и потом его обработали.
Синхронно это вы прямо на запросе юзера идете в кучку внешних сервисов и собираете ответ и возвращаете его юзеру / сохраняете в БД.
dph
31.12.2024 11:52Так темпорал позволяет делать и так и так.
Т.е. пришел запрос, его сохранили, обрабатываем и отдаем ответ синхронно. Но если в процессе обработки проблемы - кидаем timeout или просьбу повторить запрос. В таком подходе гораздо меньше проблем с отсутствием response, нет проблем с "локальностью контекста" и гораздо ниже latency.
При этом во многих случаях при проблемах с обработкой вообще не надо ничего делать, просто вернуть ошибку, а темпорал нужен только на "самом верху", только при инициализации бизнес-процесса и только на случай крайне редких сбоев (благо современная инфраструктура позволяет сделать синхронный вызов не менее надежным, нежели кафка).
sved
31.12.2024 11:52А почему в Кафку? Асинхронное взаимодействие хорошо только там, где без него действительно никак. По-умолчанию, всегда надо использовать RPC. Асинхронщина убивает перформанс и сильно запутывает разработку, отладку и траблшутинг.
Взаимодействие через БД создаёт проблему, что очень сложно модифицировать БД которую используют несколько команд. Для этого собственно и придумали микросервисы - одна база одна команда, за неё отвечающая
MonkAlex
31.12.2024 11:52Так описано же, почему кафка. Потому что сходить надо в другие системы, а они в микросервисной архитектуре всегда могут упасть. И ваш сервис тоже может.
Поэтому нам нужна очередь с гарантиями доставки, например кафка в её роли.
PetyaUmniy
31.12.2024 11:52Кому-то нужна, а кому-то не нужна. Нет никакого абсолютного решения.
Если это сервис обрабатывающий платежи - очевидно нужна. А если это сервис рекомендаций - то можно просто на фронтенде не отрисовывать этот блок (я на месте пользователя только бы обрадовался этому), нет ничего страшного что 0.01% запросов закончатся этим. С другой стороны это не бесплатно писать в стейтефул сервисы ни по железу, ни по стоимости сопровождения.BugM
31.12.2024 11:52Проблема не в 0.01 проценте запросов. А в том что ваш сервис может прилечь из-за соседнего сервиса. Без которого можно было обойтись и обработать данные в нем потом. Прилечь ваш сервис может как на пару минут, так и на пару часов. Вы на это не влияете.
Ютуб без рекомендаций пару часов это потеря кучи денег. Прямо большой кучи.
Железа там ерунда как показывает практика. Поддерживать даже удобнее. У вас есть все промежуточные данные. На них можно смотреть и даже править при необходимости. Можно сделать поверх них очень хорошие логи.
А вот писать дольше и сложнее. Тут согласен. Но это плата надежность.
MonkAlex
31.12.2024 11:52Вы к чему это? Нужна вам очередь или нет - это вопрос того, что вы делаете.
Если вы можете (бизнесово, логически) отдавать данные потребителю независимо от других сервисов - можете использовать вполне синхронное апи без очередей. Если запросы не на изменение данных, то даже с зависимостью от других сервисов можно делать запросы синхронно, да.
Если же речь идёт про запросы к другим сервисам на изменение данных - то обычно такие запросы нельзя терять\игнорировать, поэтому в свой сервис сохраняете в БД, остальных оповещаете по очереди (кафке в теме треда).
ПС: а ещё вопрос нагрузки важен, т.к. параллелить очередь очень легко - просто добавляйте обработчики (утрирую, в той же кафке это не всегда легко и понятно). Для синхронного апи вам потребуется дополнительный балансировщик входящих запросов.
alhimik45
31.12.2024 11:52другие системы, а они в микросервисной архитектуре всегда могут упасть. И ваш сервис тоже может
Да и кафка может.
BugM
31.12.2024 11:52Надежность Кафки обеспечить проще чем надежность нескольких произвольных сервисов.
Как минимум потому что Кафка не содержит бизнес логики, в нее не пишут фичи и вообще она обновляется раз в год ибо чаще не надо. Абстракции это хорошо.
MonkAlex
31.12.2024 11:52Как уже написал @BugM - кафка это одна система, стабильная, за дней проще ухаживать.
В дополнение - есть паттерн https://microservices.io/patterns/data/transactional-outbox.html который подразумевает что если сервис работает, то работает (мы надеемся) и его БД, что сохранит наши данные даже при упавшей кафке, а после её поднятия система продолжит работать как надо.
А если у сервиса не работает БД, то и в кафку ничего слать не надо, мы не можем фиксировать изменения.
ПС: идеальных решений нет, но часть вопросов так можно закрыть.
sved
31.12.2024 11:52Доставки куда? Если сервис упал, то что толку от этих сообщений в кафке? Вы потом будете чесать репу и думать как обработать сообщения вручную? А проигнорировать ошибку и при синхронном взаимодействии никто не мешает.
Я заметил что в некоторых организациях упавший сервис, проблемы с перфомансом или не работающее приложение считается в порядке вещей. Но это конечно не так.
MonkAlex
31.12.2024 11:52Условно, сервис А шлёт сообщение через кафку в сервис Б.
Сервис Б недоступен по любым причинам (нас, как разработчиков сервиса А это не волнует, может там питание выключили, может БД отвалилась, может сертификаты протухли). Мы как разработчики сервиса А положили сообщение в кафку и выполнили свою ответственность - сообщили о каком то событии.
Разработчики сервиса Б сервис подняли, сервис продолжил читать кафку с места, на котором он остановился. Дошел до нашего сообщения и его автоматически обработал.
Вручную обработка не требуется. Игнорировать "ошибки" никто не будет, т.к. их и нет во взаимодействии сервисов. А вот при синхронном взаимодействии этот сценарий не работает, что в том числе и решается очередями (кафкой к пример).
BugM
31.12.2024 11:52Сервис рано или поздно поднимется и обработает все накопившееся.
Сервисы падают. Это реальность. Обеспечивать 6 девяток доступности сложно и дорого. Зависимость от пяти сервисов с 5 девятками каждый дает вам полчаса недоступности в год по внешним причинам. Это обычно уже слишком плохо и такие зависимости использовать нельзя.
Тормоза это странная вещь. Можно сделать и тормозной сервис и быстрый на любой архитектуре.
serge_reva
31.12.2024 11:52ура-ура, что сходит хайп. 15 лет назад все носились с gof patterns, как с торбой писаной, теперь на собеседованиях ждут пересказа букваря про MSA. Причем пересказа дословного, если говоришь свое мнение, которое не на сто процентов совпадает с "мнением команды", то, как писал камрад выше, тебя гонят сцаными тряпками, даже если обратная связь по техническому интервью - exceed expectation. Вот и продолжаем дружно натягивать сову на глобус глаголами протокола, который был разработан десятилетия назад для простых задач вопрос-ответ при мендленных соединениях.
Хочу отметить, что в тех самых транснациональных корпорациях, где сервера по всему миру, такого секстанства не наблюдается. Там и шины, и сервисы(не микро) и даже телнеты в зеленый экран на хост, который может физически находится в другом континенте.. С другой стороны, в таких корпорациях потребитель информационных ресурсов внутренний, а в гуглах, ибеях, реддитах - внешний. До сих пор для меня загадка, зачем в суровом корпоративном ИТ необходимость "быстрой выкатке" изменений и зоопарк из команд, технологий и скиллов, которые превращаются во что-то монстрообразое. Бюджеты осваивать? : )
SSukharev
31.12.2024 11:52Придумали какие то "микросервисы" все уже было сто лет назад, com/dcom, corba.
ptr128
31.12.2024 11:52Я не понял принципиального отличия Монолит 2.0 от концепции пятидесятилетней давности, одна VM на одно модульное приложение в VM/SP
WebPeople
31.12.2024 11:52Когда смотришь на эволюцию архитектур, понимаешь, что технологии всегда движутся по кругу.
По спирали, а не по кругу. И это не случайность. Это 3 закон диалектики от Гегеля.
Он проявляется везде. От государственного и общественного устройства до бытовых моментов.
Звучит он как "отрицание отрицания". Смысл в том, что история всегда идёт по спирали. Переход к новому витку идёт через отрицание старого. А старое когда-то пришло через отрицание ещё более старого уклада. Вот и получается отрицание отрицания.
Также этот закон говорит о том, что все новое, даже возникнув в результате отрицания прошлого, будет использовать этот опыт в качестве основы для своей эволюции.
В случае архитектур следует ожидать новых монолитов, взявших многое от структур микросервисов. Кстати, это даже по комментам видно:
Придумали какие то "микросервисы" все уже было сто лет назад, com/dcom, corba.
Или вот
Я не понял принципиального отличия Монолит 2.0 от концепции пятидесятилетней давности, одна VM на одно модульное приложение в VM/SP
APXEOLOG
31.12.2024 11:52Serverless подход (лямбды в облаках) сочетает удобство монолита с масштабируемостью микросервисов (во всяком случае под нагрузки 99% среднестатистических приложений). Видимо люди не доверяют облакам (хотя можно и без вендорлока делать)
deathlenin
31.12.2024 11:52Просто это дорого. Облака дерут в три конца.
alhimik45
31.12.2024 11:52Ну сами лямбды кстати не сильно дорогие. Dev/QA лабы можно на каждый чих создавать и не париться что деньги будут за время существования браться, как в случае контейнеров. Так что их можно рассматривать как минимум при выборе контейнеры в облаке vs лямбды в том же облаке, когда косты на всё остальное плюс минус будут одинаковыми.
alhimik45
31.12.2024 11:52удобство монолита
А в чём удобство распределенного монолита? Если разные лямбды ходят в одну базу и используют общий код, то там такое веселье с консистентностью доступа к данным и апдейтов самого кода начинается.
saboteur_kiev
31.12.2024 11:52всегда считал, что микросервис - это возможность разбить что-то на мелкие модули и масштабировать только бутылочные горлышка. Но при этом разработчик, точнее архитектор, может заранее просчитать где будут бутылочные горлышка и микросервисами покрывать только потенциально высоконагружаемые части, остальное реализовывать обычными сервисами /монолитами.
Вся суть микросервиса - в том, что масштабировать малое можно дешево.
kivan_mih
31.12.2024 11:52А в чем вы видите проблему горизонтально масштабировать монолит?
Smokost
31.12.2024 11:52Если монолит такой большой, что прогретый процесс требует 32+ гига оперативы, то масштабировать такое горизонтально будет сильно накладно.
А некоторые, при запуске монолита, делают долгоживущие подключения в базы и в другие сервисы, которые множить тоже нежелательно.
Но для небольших (относительно) монолитов, с ленивой инициализацией модулей и подключений - почему бы и нет, вполне рабочее решение.
kivan_mih
31.12.2024 11:52Про память это условно, всё зависит от особенностей приложения, если у вас 32гб монолит, но масштабируетесь вы потому, что у вас на один эндпоинт, который потребляет при вызове 100 байт, миллион запросов в секунду, а остальное приложение просто пассивно висит в памяти, то да действительно скейлить всё приложение только ради одного эндпоинта странно и его нужно выносить. Однако если у вас нагрузка +- гомогенна на всё приложение, то распилив эти 32 гигабайта по микросервисам вы не получите преимуществ с точки зрения памяти, а скорее наоборот, поскольку помимо полезной нагрузки отдельные рантаймы будут потреблять память в то время как в монолите рантайм потребляет память один раз.
Что касается ресурсов, например коннекшенов, то здесь я соглашусь, за этим надо внимательно следить при масштабировании монолита, это может вызвать проблему, особенно если внешних ресурсов много и каждый из них используется только одним модулем. С другой стороны, например, если у вас подключение к одной базе, используется connection pool и модули работают с разными схемами, то как и в случае с памятью распилив приложение вы не получите преимуществ, а скорее наоборот.
BugM
31.12.2024 11:52Давно-давно было такое. Вроде умели как бы не с 80тых. Но в реальной реализации монолитов были иногда проблемы. Примерно в середины десятых все адекватные их решили.
PrinceKorwin
31.12.2024 11:52Смотря что за цель приследуется при масштабировании. Если обеспечить HA - то особой проблемы нет (но бывают нюансы), если для распределения нагрузки, то этот монолит должен быть с нуля написан так, чтобы такая возможность имелась. Иначе не выйдет. Обычно масштабировать монолит мешает:
Эксклюзивный подход в работе с БД, транзакциями и, собственно, самими данными
Способ кэширования (и инвалидации)
Другие механизмы роутинга и механизмы вызова бизнес-логики
Долгий старт и инициализация монолита
PetyaUmniy
31.12.2024 11:52Непонятно, если создается такой продукт с такими ограничениями на эксклюзивность (т.е. не допускается работа 2 инстансов), то как такое тогда обновлять? Ведь в момент обновления старая версия должна отработать полученные запросы и в то же время новые запросы уже идут работают с новой версией. Просто грубо вырубаете сервис (огребая кучу 5**) или дропаете трафик - типо у пользователя тормозит?
PrinceKorwin
31.12.2024 11:52Да. Именно так:
поднимаем новое рядом. как поднялось
переключаем роуты и дропаем старое
Большинству сервисов/приложений этого более чем достаточно. Даже downtime в 5 минут на перезапуск им не сделает погоды.
Требование к высокой доступности, на самом деле, мало кому нужно. А если так, то зачем платить больше?
PetyaUmniy
31.12.2024 11:52Большинству сервисов/приложений этого более чем достаточно. Даже downtime в 5 минут на перезапуск им не сделает погоды.
Это несколько сомнительно. Мы например на основном проекте делаем в среднем 2 (иногда до 5) выката в день. Если бы мы лежали в день 10-25 минут, пользователи точно не были бы в восторге (а если еще учесть контекст сервиса... биржа на которой удут торги). Кажется что никакому реально работающему сервису его пользователи не простят такого простоя. Смещать простой на ночь - это тоже не бесплатно. Эксплуатация не обрадуется и запросит или больше золота или юнитов.
PrinceKorwin
31.12.2024 11:52пользователи точно не были бы в восторге
Зависит от того, в чем выражается этот восторг, на как много пользователей это повлияло, и какое это оказало влияние на бизнес/прибыль.
а если еще учесть контекст сервиса... биржа на которой удут торги
Не все делают сервисы для бижри на которой идут торги.
saboteur_kiev
31.12.2024 11:52А в чем вы видите проблему горизонтально масштабировать монолит?
В общем случае, монолит жрет больше ресурсов, поэтому его масштабировать дороже.
kivan_mih
31.12.2024 11:52Приведите, пожалуйста, пример. В общем случае это не так и зависит от платформы. Если у вас есть монолит, например на java, который потребляет 8Гб памяти, то распилив его, суммарная потребляемая память увеличится, поскольку для каждого микросервиса помимо полезной нагрузки будет подниматься отдельный jvm рантайм, потребляющий память. В случае монолита, такой рантайм только один.
Rive
31.12.2024 11:52Shopify
Насколько помню, у них был доклад на конференции, в котором они поделились наблюдением, что узким местом у них оказался вовсе не приложение (которое монолит на Ruby), а база данных. И за счёт шардирования БД по подам (с несколькими клиентами на каждом) они начали лучше справляться с нагрузкой.
Arlekcangp
31.12.2024 11:52И так будет у 90%. Причем база будет забиваться на чтение. Т е добавление slave-реплик может решить проблему. А люди из-за этого хайпа огромные ресурсы тратят... Я помню с чего началось: появился ряд людей, которым "всë не нравится" (Такие есть всегда и везде, особенно в разработке) И выдвинули ультиматум ( именно ультиматум), что мол им не нравится, что они приходят в организацию, а там все пишут на яве (можно подставить что угодно - питон, перл, пхп, го, раст, эрланг) и используют один стек. Мы де, хотим свою уютную команду и свой уютный стек. И понеслось!
Этот подход начали всячески оправдывать, назвали микросервисами. Да, именно так! Именно это тогда выдвигалось, как главное преимущество! Я помню времена как хвастались, что у них в компании 10 разных стеков и "всë работает". Я тогда смотрел на этих шизиков и удивлялся. Потом как-то постепенно эту мантру, что все пишут на чем хотят, начали из списка преимуществ микросервисов выкидывать... Потому что преимущество сомнительное. Рациональность свое начала отвоевывать.
Потом стали говорить " Ой, да мы с новой архитектурой по 50 релизов в день делаем! " Тоже так себе идея. Во первых разрабы только и занимаются релизами, во вторых а что мешало с монолитом делать тоже самое? Явно не то, что его исполнимый файл больше весил. Значит бардак был в архитектуре. И тут в улучшение наконец вложили денег. Причем нехило так. Распил монолита - это не пять минут. А насчет количества релизов - так тоже бардак, но только организационный. Ваши команды не в состоянии скоординироваться и сделать релиз, например раз в три дня.
И вот только теперь всерьез говорят, а что собственно потерялось с переходом на микросервисы ? А потерялось дофига: нормальная транзакционность, нормализация данных, простота разработки (серьезно кто-то до сих пор думает, что с учетом первых двух пунктов разрабатывать микросервис проще монолита?), легкость тестирования, и не очевидное - надежность и детерминированность поведения (относительная, при условии что бд работает. Выше писали, полностью с этим согласен)
Ну и последнее: а чем на самом деле лучше микросервисы? Иными словами это вопрос, а зачем они нужны? Рациональное логическое мышление дает ответ: это отделение контекста исполнения, т е очень жесткий барьер, который при падении одного контекста, предотвращает падение соседних. Вот в такой трактовке микросервисы будут надежность повышать. Т е у нас есть некий критический компонент, который не должен стать не доступным. При этом к остальным частям системы таких требований нет. Мы этот компонент отделяем в отдельный контекст и дуплицируем, делаем облако. Ну для примера: компонент авториции и аутентификации. Критический, т к его используют все части системы. И при его недоступности всë остановится. Значит как то нужно обеспечить его надежность. Можно дублировать весь монолит, но тогда при его росте могут возникнуть проблемы различного рода. Плюс в этом случае требования надежности предъявляются к нему целиком. А это может всë сильно усложнить. Но вот тогда принимается решение вынести в отдельный сервис эту функциональность. (Я подозреваю, что очень много будет не согласных с таким подходом. Но что ж, у всех есть возможность свою точку зрения изложить... )
BugM
31.12.2024 11:52Подпишусь под словами что можно и нужно выделять общие сервисы без которых работать нет смысла и ходить в них синхронно.
Но я бы не хотел разрабатывать такой сервис. С такими требованиями по надежности там любой чих будет обложен парой регламентов, а релиз будет катиться месяц.
sherbinko
31.12.2024 11:52У микросервисов есть вполне осязаемые технические плюсы.
В классических микросервисах только один сервис владеет базой и никто другой.
Отсюда преимущества:
лёгкость изменения индексов, структуры и прочего одной командой.
возможность грамотно и надёжно кешировать данные в памяти микросервиса
Ну и очевидны недостатки связанные с БД: проблемы с консистентностью, транзакциями и перформансом.
Кроме того, микросервисы изолированы друг от друга, а значит меньше проблем с конфликтом библиотек.
Что же касается надёжности, то микросервисы в этом наоборот проигрывают
PjaniyAdmin
31.12.2024 11:52Из моих личных столкновений с монолитами и микроархитектурами в контексте телекома, использование монолитов сильно экономит место в стойках. По мимо места в стойках сетевая обвязка становится более простой и дешевой. Сказать что микросервисы дают какието реальные бонусы как клиету так и сетевому администратору нельзя. Вот у тебя железяка которая у тебя абонентский шлюз, а вот у тебя стойки на которой наверчен опенстэк, где на серваках живет абонентский шлюз в виде фиговой тонны машин, причем иногда такой же почти 1в 1. Когда у тебя чтобы собрать несколько каких нибудь pgw на микросервисах просят 10к ip адресов чтобы сшить всё это микросервисное чудо, думаешь "чтоже с тобой делать когда в тебе чтото сломается". Монолит в виде коробки тем временем, подключай к питанию, к фибрике 10 минут на залив конфига и ты в деле.
napolskih
31.12.2024 11:52Я нашел для себя лучший вариант и компромисс - это микросервисный монолит на Эликсир. Жаль только этот стек достаточно экзотичен. Очень недооценен.
odilovoybek
31.12.2024 11:52К примеру Next или любые другие fullstack фреймворки - это старый PHP, но намного неудобнее и даже медленнее из-за некой сложности конфигурации, так как PHP прямо-таки подточена под эту работу.
koreychenko
31.12.2024 11:52Опять сравнивают Uber и прочий eBay с мелкими сайтиками на 100 человек в день с точки зрения архитектуры.
В первую очередь количество отдельных сервисов у больших компаний связано с тем, что они работают на куче национальных рынков и должны соблюдать требования законодательства отдельных стран. Грубо говоря, Амазон в Европе и Амазон в США это два разных Амазона. Например, по расчету сроков/стоимости доставки проще выкатить отдельный сервис для каждой локации и собрать туда все тарифы и сделать интеграции с локальными доставляторами, чем городить глобального монстра. Ну и по администрированию, я думаю проще менеджеру в Испании разбираться со службами доставки в Испании, чем централизованно согласовывать все это.
PrinceKorwin
31.12.2024 11:52В первую очередь количество отдельных сервисов у больших компаний связано с тем...
у больших компаний это связано с законом Конвея, на самом деле :)
nikolaokonesh
31.12.2024 11:52к примеру Rails, в последней версии отказались от Redis. Теперь вебсокеты очереди и кеш основаны на БД. ещё и SQLite в продакшн. Думаю самый дешёвый монолит в плане обслуживания. По рассказам в просторах инета выдерживает довольно большие нагрузки.
savostin
Судя по внешнему виду, eBay до сих пор работает на Perl CGI и Apache. Я думал они уже лет 10 не "выводят новые функции на рынок"...
firehacker
Как будто это что-то плохое
mizugoji
А как вы определили что у ебей perl?
По данным https://www.wappalyzer.com/lookup/ebay.com/ у ebay самый продвинутый технологический стек: Marko.js, React, Node.js.
savostin
А внешний вид из девяностых. И удобство пользования.
Mayurifag
Я с Вами полностью согласен.
Но изменив этот внешний вид, они рискуют получить волну хейта за тем, для кого новый вид неудобен, этим они сломают все виды роботов/парсеров/скриптов/снайперов на аукционах и так далее. Непонятно заранее при том, выиграют ли в деньгах.
Так и приходится жить в неопределенности, видимо. Было бы известно заранее, что новый облик точно пошёл бы в плюс, — сделали бы.
tongohiti
Вот к примеру хабр. Ну поменяли тут всё "на современный лад", и? Стало точно не лучше. То, что вся страница сразу не прогружается (комментарии грузятся теперь отдельно) и что страница даже будучи прогруженной постоянно лезет в интернет - уже год как это всё выкатили, а до сих пор плююсь, не могу привыкнуть. Раньше как, открыл в новых фоновых вкладках с десяток интересных статей не глядя - и можно хоть в метро, хоть в самолёт. А теперь? Пока за ушком не почешешь - страница не прогрузится, ни иллюстраций ни комментариев. А комментарии в 2/3 случаев полезнее статьи. Если бы на хабре не было комментариев - скорее всего я бы его вообще не читал бы..
Так что иБэй молодцы, понимают что важно, а что шелуха. Наверно. Мнение личное, прошу не пинать.
Tony-Sol
а то, какая все же связь между «внешний вид из девяностых» и «работает на perl cgi», полагаю, останется загадкой