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

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

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

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

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

    Монолит

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

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

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

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

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

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

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

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

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

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

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

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

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

    Бизнес-аналитик и системный аналитик в ИТ: кто есть кто и в чем разница

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

    21 мая 2025

    5 распространенных ошибок в работе системных аналитиков

    Ошибки системных аналитиков редко видны сразу, но последствия могут быть весьма заметными. Срыв сроков, недовольство заказчика, бесконечные правки требований, ощущение, что проект «расползается» — это часто не проблема менеджмента, а не выявленные вовремя аналитические ошибки и риски. Мы регулярно анализируем дипломные проекты выпускников курса «Системный аналитик» — не ради оценок, а чтобы понять, какие трудности реально возникают на практике, и обозначить направления для дальнейшего развития навыков. Даже у мотивированных специалистов с практическим опытом есть «слепые» зоны. Где-то не хватает чёткости в декомпозиции, где-то — качества проработки связей между сущностями, понимания архитектуры. Даже отсутствие умения аргументировать выбор решений перед бизнесом может негативно повлиять на проект. Мы вместе с Екатериной Тихомировой — практикующим аналитиком с более чем десятилетним опытом — разобрали некоторые типичные ошибки и риски, и способы, как их предотвратить.

    20 мая 2025

    Итоги работы Центра сертификации IBS

    Центр сертификации IBS начал свою работу в апреле 2023 года, поэтому мы традиционно подводим итоги работы в апреле-мае. Прошедший год стал для нас периодом важных изменений. В 2024 году произошло несколько знаковых событий: наша команда обновила программы сертификации системных аналитиков и Java-разработчиков, подготовила к запуску сертификацию бизнес-аналитиков, получила аккредитацию от АПКИТ и стала обладателем Гран-при премии «Смарт пирамида». Рассказываем подробнее, каких результатов мы достигли в уходящем году и как это отразилось на нашей работе.

    Новости
    19 мая 2025

    Какой метод тестирования выбрать: черный, белый или серый ящики?

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

    14 мая 2025

    Удостоверение, диплом и сертификат: в чем разница и что выбрать

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

    12 мая 2025

    Выгодный май — на курсы залетай!

    Друзья, спешим поделиться отличной новостью — вы можете получить скидки до 40% на наши популярные курсы. Это отличная возможность улучшить навыки и инвестировать в профессиональное развитие по более выгодной цене. Выбирайте направление и подавайте заявку прямо сейчас!

    05 мая 2025

    Кейс: кастомизация курса по Jira

    Кейс по проведению кастомизированного курса «Основы Jira» для крупной российской компании, занимающейся производством цифровой техники.

    05 мая 2025

    Зачем специалистам по 1С изучать системный анализ и архитектуру ПО

    Как системный анализ и архитектура ПО помогают эффективнее работать в 1С.

    29 апреля 2025

    Банка Nutella, IT, ESG — что общего?

    Когда вы читали этикетку на продукте не из-за состава, а из-за ESG-маркировки?

    25 апреля 2025

    Каковы плюсы и минусы монолитной и микросервисной архитектуры при разработке ИТ-продуктов?

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

    25 апреля 2025

    Станьте архитектором ПО с выгодой! Только в апреле сэкономьте 20 000 ₽ и получите новый модуль по микросервисам в подарок

    24 апреля стартует обучение на комплексной программе «Архитектор ПО. Путь к мастерству в проектировании систем»*.

    14 апреля 2025

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

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

    Новости
    10 апреля 2025

    Кейс: Интенсив по управлению проектами для промышленной компании

    Мы адаптировали курс по управлению проектами под запрос команды крупной промышленной компании и провели обучение. Вот что из этого вышло.

    27 марта 2025

    Кейс: Обучение сотрудников крупной компании работе с ClickHouse

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

    19 марта 2025

    Платформа сертификации IBS получила аккредитацию АПКИТ

    Ассоциация предприятий компьютерных и информационных технологий (АПКИТ) приняла новый регламент сертификации ИТ-специалистов.

    Новости
    10 марта 2025

    Специальные акции на учебные программы

    У нас отличная новость для всех, кто стремится развивать свои навыки в мире ИТ.

    06 марта 2025

    Как остановить спам-атаку

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

    06 марта 2025

    Учебный центр IBS подписал партнерское соглашение с ООО «РусБИТех-Астра», разработчиком российской операционной системы Astra Linux.

    Теперь мы можем проводить авторизованное обучение по работе с Astra Linux для специалистов в области информационной безопасности.

    17 февраля 2025

    Двойная выгода: покупай один курс — получай второй за 50% стоимости!

    Воспользуйтесь возможностью изучить более глубокие аспекты одной области — например, при покупке курса по Java, архитектуре ПО, управлению проектами, системному и бизнес-анализу, тестированию ПО и Big Data вы можете получить второй курс этой же тематики за полцены! Не упустите шанс развить свои навыки и поднять свою карьеру на новый уровень. 

    29 января 2025

    Сертификация преподавателя Java-разработки для крупного провайдера ИТ-обучения

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

    Новости
    21 января 2025

    Не нашли, что искали? — Просто напишите, и мы поможем

    Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
    Пользователь только что записался на курс ""
    Спасибо!
    Форма отправлена успешно.