25 апреля 2025 3003
Монолитная и микросервисная архитектуры представляют собой два различных подхода к разработке ИТ-продуктов, каждый из которых имеет свои преимущества и недостатки.

Микросервисы

Микросервисы — это архитектурный стиль, при котором приложение или система строится как набор сервисов, каждый из которых решает ряд определенных задач и закрывает отдельный набор потребностей бизнеса. При этом задачи, решаемые каждым отдельным сервисом, как правило не дублируются внутри других сервисов.

Плюсы микросервисов:
  • Масштабируемость и отказоустойчивость за счет того, что может быть запущено несколько экземпляров одного сервиса.
  • Возможность частичного обновления. Т.е. для реализации разработки функционала необходимо внести изменения только в одном микросервисе, без остановки всего приложения. Это позитивно влияет на показатель доступности приложения.
  • Лучшая надежность. В случае сбоев, удастся быстрее локализовать источник проблемы, определив сервис. При этом, при наличии ошибки в одном сервисе, система в целом может продолжить функционировать и станет недоступна лишь ее часть.
  • Меньшие издержки на тестирование. Как для регрессионного, так и для юнит-тестов, компоненты участвующие в процессе тестирования автономны, что позволяет уменьшить объем тестирования.

  •  Минусы микросервисов:
  • Ассортимент технологических стеков. В виду того, что компоненты такой архитектуры могут быть написаны на разных языках программирования, для разработки и поддержки приложения необходима команда, обладающая более широким набором компетенций.
  • Сложная стандартизация. Поскольку знания разделены между несколькими командами, и при этом каждая отвечает за свой сервис или набор сервисов, это приводит к отсутствию единого стандарта разработки и централизованного процесса обновления. С другой стороны, такой подход за счет наличия нескольких практик в разных командах позволяет выбрать лучший, и адаптировав его, распространить на остальных.
  • Оркестрация и шардирование. Если мы имеем несколько экземпляров одного сервиса, то чтобы избежать простоя во время обновления, экземпляры сервисов можно обновлять по одному. При этом надо поддерживать старую версию API и настраивать структуру взаимодействия. Если у нас несколько экземпляров одного и того же сервиса, то получается, что у нас есть несколько потребителей сообщений, надо настраивать маршрутизацию таким образом, чтобы, например, все сообщения, относящиеся к одному заказу в интернет-магазине, попадали к одному и тому же экземпляру сервиса.
  • Микросервисы.png

    Монолит

    «Монолит» — архитектурный стиль, в котором вся логика выполнения целевого действия выполняется в рамках одного процесса взаимодействия между клиентом, базой данных и сервером.

    Плюсы монолита:
  • Производительность. Правильно написанный монолит состоит из модулей, которые легко «распилить» на микросервисы. Сообщение между модулями происходит через память, поэтому оно быстрее, чем, например, через брокеры.
  • Единый технологический стек. Для разработки и поддержки приложения достаточно иметь команду, обладающую схожим набором компетенций, при этом члены команды легко дополняют и заменяют друг друга. Процессы написания кода и код-ревью выполнять проще, поскольку выполняются они в рамках одного компонента.
  • Единая среда данных. Это означает, что каждый компонент системы имеет физический доступ к данным из единого источника. При этом данные целостны, и нет потребности в их синхронизации. Архитектуру, состоящую из набора микросервисов, имеющих по одному экземпляру и обращающихся к одной централизованной БД, нельзя назвать эталоном микросервисной архитектуры, т.к. у приложения в целом появляется единая точка отказа — база данных.

  • Минусы монолита:
  • Время простоя при обновлении. Даже при минимальных доработках необходима приостановка работы и пересборка всего монолита или как минимум его серверной части. Если сборка осуществляется в рамках CI/CD, то удастся существенно сократить это время.
  • Масштабируемость. Речь идет не о том, что монолит нельзя масштабировать. Само масштабирование выполняется по вертикали, за счет увеличения ресурсов, используемых приложением в целом. Такой подход создает сложность при необходимости увеличить производительность одного процесса, т.к. далеко не все приложения позволяют это сделать.
  • Зависимость компонентов плохо влияет на производительность. Отсутствие возможности выделить ресурсоемкую операцию в отдельный процесс создает проблемы при запуске такой операции у всех пользователей системы.

  • Микросервисы.png
    Нельзя сказать, что компании предпочитают какой-то из вариантов архитектуры, ввиду того, что каждый вариант применим для решения определенных задач, все зависит от ситуации.

    Сценарий 1. К примеру, компания решила проверить бизнес-гипотезу и разработать какое-то приложение с последующим выводом на рынок или для собственного использования.

    Архитектуру этого приложения трудно определить сразу, но при этом есть некоторые ограничения:
  • нет уверенности в успешности гипотезы;
  • задачи для команды разработки сформулированы расплывчато;
  • существует строгое ограничение по ресурсам и этих ресурсов немного.

  • В таком сценарии компании чаще выбирают монолитную архитектуру, но при этом строят «правильный монолит» ее с учетом того, что дальше этот монолит будет нарезаться на микросервисы.

    Сценарий 2. Корпоративные информационные системы. Крупные системы управления предприятием ERP (SAP или 1С) и пр. построены исходя из принципов монолитной архитектуры, либо стремятся к соответствию этим принципам. Внутри одного приложения возможно разделение на модули, каждый из которых выполняет свою бизнес-функцию, но при этом данные для таких систем привязаны к самому приложению и взаимозависимость модулей (один модуль потребляет данные другого и производит данные для третьего) не позволяет назвать такие модули микросервисами.

    При этом, если представить, что вокруг ERP-системы появляются такие решения как: система учета заработной платы, корпоративный портал и сервис электронного документооборота, то эту архитектуру уже нельзя назвать микросервисной, т.к. каждый компонент, входящий в ее состав, является отдельным крупным монолитом, выполняющим целый комплекс бизнес-задач и сервисов.

    Сценарий 3. Продуктовая компания, которая занимается разработкой и развитием продукта, являющимся центральным ядром их бизнеса и главным инструментом общения с клиентами. Например, приложение онлайн-банка или приложение для заказа такси или еды.
    Для такого приложения чаще всего используется микросервисная архитектура, в связи с тем, что:
  • понятна бизнес цель разработки данного приложения;
  • возможно определить сложность этого приложения и тех компонентов, которые будут входить в состав;
  • есть бюджет на разработку продукта, и не только на стадию MVP;
  • объем потребителей приложения понятен только примерно и скорее понятен его максимум, но система должна иметь возможность горизонтального масштабирования, поскольку мы не знаем динамику, с которой новые пользователи будут добавляться в приложение;
  • надежность и отказоустойчивость важна, и архитектура проектируется с учетом этих ограничений.

  • Автор: Сергей Политыко

    Оригинал статьи размещен на ibs.ru

    Последние статьи в блоге

    IBS запускает независимую сертификацию для тестировщиков ПО

    Центр сертификации IBS инициировал новую программу независимой оценки квалификации для тестировщиков программного обеспечения. Сертификация IBS позволяет ИТ-специалистам систематизировать знания, подтвердить соответствие единому стандарту качества и повысить конкурентоспособность на рынке труда.

    21 июля 2026

    Внедрение BI-систем: почему проект может не дать результатов

    Реализация системы бизнес-аналитики (BI) может пройти технически гладко, но не принести ожидаемого эффекта компании. Причина обычно не в самой платформе, а в организации работы над проектом. Начальник отдела витрин данных и аналитики IBS Анна Филиппова поделилась взглядом на то, почему возникают такие ситуации и как их избежать.

    17 июля 2026

    Саммари вебинара «Проектирование высоконагруженной системы на примере агрегатора авиабилетов»

    Алексей Додонов, эксперт с 20-летним опытом в ИТ, на сквозном кейсе разобрал эволюцию архитектуры стартапа по продаже авиабилетов — от монолита до распределённой системы, и как команда решала проблемы производительности на каждом этапе.

    16 июля 2026

    Бесплатный вебинар «Результативный ИИ в бизнесе: как внедрять безопасно, измеримо и с реальной пользой»

    Искусственный интеллект — это уже не просто тренд, а рабочий инструмент. Но как перейти от пилотов и экспериментов к системному процессу с понятными метриками и управляемыми рисками?

    Новости
    03 июля 2026

    ИИ в бизнесе: почему экономия на зарплате не всегда равна прибыли

    Внедрение ИИ в корпоративную среду стало рутинной задачей для многих ИТ-директоров и руководителей проектов. Однако первые волны оптимизма уже столкнулись с суровой реальностью.

    Жизнь компании
    18 июня 2026

    Саммари вебинара «Техсобес на Java: как системный подход и работа с ИИ превращают стресс в оффер»

    Владимир Низов, технический директор с 10-летним стажем и эксперт Учебного центра IBS, рассказал, почему кандидаты проваливают технические интервью и как этого избежать. Отдельно разобрал работу с ИИ. Главное: заучивать тысячи страниц не нужно. Достаточно освоить индексный подход и единый паттерн системного дизайна. А ИИ воспринимать как инструмент с чёткими ограничениями.

    Новости
    09 июня 2026

    Опыт развертывания корпоративной/ведомственной ИИ-инфраструктуры

    Разговор о проблемах развертывания ИИ-инфраструктуры часто ведется на макроуровне: дефицит вычислительных мощностей, стоимость ускорителей, зависимость от внешних поставщиков, регуляторные ограничения. Все это важно, но если посмотреть на ситуацию глазами специалиста, которому предстоит решить эту задачу, вопрос становится более прикладным: как развернуть корпоративную ИИ-инфраструктуру, чтобы она не превратилась в дорогой, трудноуправляемый и слабо загруженный набор серверов?

    Новости
    02 июня 2026

    «Аниматор с провалами памяти»: 6 ограничений ИИ, которые не дают вам писать качественный код

    Вы когда-нибудь просили ИИ написать метод на Spring Boot, получали красивый, идеально отформатированный код, а он не работал? Потом вы копали глубже и находили, что нейросеть использовала RestTemplate вместо WebClient, забыла про @Transactional, а в методе с @PreUpdate пыталась изменить данные, которые уже ушли в SQL. И вы думали: «Ну, нейросеть же глупая». Нет. Не глупая. Она просто пишет код не как человек.

    Новости
    28 мая 2026

    Роль и место России в мировой гонке в сфере ИИ

    По масштабу амбиций и геополитическому значению гонку в сфере искусственного интеллекта все чаще сравнивают с космической гонкой эпохи холодной войны. Соревнование разворачивается одновременно по нескольким осям: вычислительные мощности, данные, кадры, модели и регулирование. В настоящее время ни одну из мировых держав нельзя назвать ведущей по всем направлениям, что оставляет возможность для разных подходов и стратегий в достижении лидерства. О положении России в этом глобальном соревновании, ее стратегических целях, инфраструктурных ограничениях и потенциале для развития рассказывает Денис Воденеев, заместитель директора центра перспективных разработок IBS.

    Новости
    21 мая 2026

    Систематизация ИИ-компетенций: курсы под роли, карты эффективности и модули в комплексных программах

    Учебный центр IBS систематизировал подход к развитию навыков работы с искусственным интеллектом. Хаотичное использование нейросетей, как показала практика, не даёт измеримого эффекта. Новое направление построено так, чтобы ИИ решал конкретные бизнес-задачи, а не просто ускорял рутину.

    Новости
    18 мая 2026

    Как защитить бизнес и данные при внедрении ИИ

    Искусственный интеллект способен резко расширить возможности развития бизнеса, однако просчеты при внедрении подобных систем могут обернуться серьезными убытками.

    Новости
    13 мая 2026

    Искусственный архитектор: как нейросети справляются с проектированием ПО

    В этой статье расскажем про большие языковые модели в приложении к работе архитектора ПО. Вместе мы посмотрим, насколько хорошо GPT понимает ИТ-архитектуру и сможет ли уже сегодня заменить архитектора. Пора разобраться, насколько глубоко ИИ может встроиться в рабочие процессы архитектора ПО — и стоит ли ему там оставаться.

    Новости
    24 апреля 2026

    Бабушка с долгом в полмиллиона, однопоточное ядро и другие грабли: как не повторить чужие архитектурные ошибки

    Любая система рано или поздно проверяется на прочность: нагрузкой, ростом бизнеса или человеческим фактором. Именно в эти моменты всплывают решения, которые казались безобидными на старте. Ниже — реальные кейсы из практики, где небольшие архитектурные допущения со временем превращались в ощутимые проблемы. Разберем, какие сигналы можно было заметить сразу и что стоит учитывать, чтобы не повторить эти сценарии в своих проектах.

    Новости
    16 апреля 2026

    Как защитить информацию в приложениях, использующих ИИ

    Представим, что системы контроля и анализа транзакций в банке начинают игнорировать 30% мошеннических операций. Система управления энергосетью выводит из строя ключевой узел подачи электроэнергии в город. Чат-бот службы поддержки начинает массово раскрывать персональные данные клиентов. К сожалению, это новая реальность, с которой может столкнуться любая компания, интегрирующая ИИ-системы в бизнеспроцессы.

    Новости
    08 апреля 2026

    Java без розовых очков: какие знания отделяют грейды

    Почти каждый разработчик рано или поздно задается вопросом: «Я уже Middle или все еще уверенный Junior?» Опыт растет, задач становится больше, стек шире — но вместе с этим появляется и иллюзия, что раз ты пишешь на Java каждый день, значит, язык знаешь.

    Новости
    23 марта 2026

    ИИ против джуна: как победить нейросети при устройстве на работу

    Начинающим разработчикам и раньше было непросто найти первую работу, а сейчас и подавно: конкуренция выросла кратно, а рынок окончательно стал «рынком работодателя».

    11 марта 2026

    Мартовский апгрейд: обновляем компетенции со скидкой 20% и приятными бонусами

    Март — традиционное время не только для обновления природы, но и для профессионального роста. С 1 по 31 марта 2026 года у нас действует акция «Мартовский апгрейд».

    05 марта 2026

    Февраль 2026: Разбираем тренды, прокачиваем архитектуру и учимся договариваться с ИИ. Бесплатные вебинары для ИТ-специалистов

    Февраль — месяц, когда уже видны цели на год, но еще есть время скорректировать курс и зарядиться новыми знаниями.

    Новости
    06 февраля 2026

    Как ИТ-компании могут компенсировать до 10 млн ₽ на обучении сотрудников в 2026 году

    Как аккредитованный учебный центр, специализирующийся на подготовке ИТ-специалистов, мы не только проводим программы дополнительного профессионального образования, но и помогаем корпоративным клиентам корректно оформить документы для участия в программе «Субсидия на обучение сотрудников» Департамента предпринимательства и инновационного развития города Москвы. В этой статье — структурированный обзор условий, требования к компаниям и сотрудникам, а также как мы можем помочь вам при подаче заявки.

    Жизнь компании
    20 января 2026

    Архитекторы vs Рутина: Как открытый вебинар за 2 недели превратился в кастомный ИИ-интенсив

    В Учебном центре IBS мы регулярно проводим бесплатные вебинары для ИТ-специалистов. Это наша философия — делиться реальными знаниями, а не просто давать рекламу. Один из таких вебинаров, посвященный практическому применению ИИ в инженерии, посетили сотрудники крупной компании — лидера в спортивном ритейле.

    12 января 2026

    Нужна помощь? Оставьте заявку, и мы свяжемся с вами в ближайшее время

    Согласен получать на e-mail информационные рассылки о новостях Учебного центра IBS
    Корпоративное обучение Оценка персонала Сертификация О нас Стать тренером Блог Личный кабинет
    Пользователь только что записался на курс ""
    Спасибо!
    Форма отправлена успешно.