Микросервисная VS монолитная ИТ-архитектура: очень подробный гайд для CIO

ИТ-архитектуры предприятий делятся на два типа: традиционные монолитные и более новые микросервисные. С ростом бизнеса и масштабов цифровизации монолитные ИТ-системы становятся неповоротливыми. Микросервисы призваны решить эту проблему.

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

Источник

Крайне продуктивная дискуссия по теме микросервисов с участием экспертов по разработке ПО состоялась на канале DEV Q&A.

Термины и определения

Рассмотрим определения микросервисной и монолитной ИТ-архитектур и их особенности.

Микросервисная архитектура

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

• Независимость: Каждый микросервис разрабатывается, тестируется и развертывается отдельно.
• Автономность: Сервисы слабо связаны между собой, изменения одного сервиса минимально влияют на остальные.
• Масштабируемость: Можно масштабировать отдельные сервисы независимо друг от друга.
• Технология независимости: Разные микросервисы могут быть написаны на разных языках программирования и технологиях.

Что такое микросервис в программировании

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

• Независимость: Работает самостоятельно, не зависит от других частей приложения.
• Самодостаточность: Имеет собственную базу данных, конфигурацию и инфраструктуру.
• Коммуникация через API: Общается с другими микросервисами посредством открытых интерфейсов (например, REST, gRPC).
• Легкость тестирования и развёртывания: Легче поддерживать, обновлять и масштабировать отдельно от остальных компонентов.

Пример: в интернет-магазине один микросервис может отвечать за обработку заказов, другой — за управление каталогом товаров, третий — за расчёты скидок и акций.

Простым языком

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

Примеры

• Сервис авторизации: отвечает исключительно за проверку пользователей и выдачу токенов.
• Каталог товаров: хранит и обрабатывает информацию о товарах онлайн-магазина.
• Корзина покупок: управляет состоянием корзины конкретного покупателя.
• Оплата заказов: взаимодействует с платежными системами и проводит транзакции.
• Рекомендационный сервис: формирует персональные рекомендации товаров для покупателей.
• Отправка уведомлений: отправляет уведомления пользователям по email или SMS.

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

Монолитная архитектура

Монолитная архитектура — это подход к построению приложения, при котором все компоненты (бизнес-логика, база данных, интерфейс и др.) объединены в одно целое и работают вместе внутри единого процесса. Основные характеристики:

• Единая структура: Все части приложения тесно взаимосвязаны и зависят друг от друга.
• Простота разработки: Проще начать разработку нового проекта, поскольку всё находится в одном месте.
• Трудности масштабирования: Масштабирование требует увеличения ресурсов всего приложения целиком.
• Зависимости: Изменение одной части приложения может повлиять на всю систему.

Сравнение микросервисов и монолита по пунктам

Ниже приведено детальное сравнение микросервисной и монолитной архитектур с подсчетом очков за каждую из них.

Конъюнктура рынка

1:0. Рост объема данных, масштабов и темпов цифровизации 

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

2:0. Монолит не современен

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

2:1. Если монолит работает стабильно, то лучше его не трогать

Переход на новую архитектуру сопряжен с риском возникновения проблем совместимости и нестабильности. Если существующая монолитная система удовлетворяет потребности бизнеса и не вызывает серьезных трудностей, целесообразней оставить её в неизменном виде, пока необходимость перехода на микросервисы не станет очевидна.

Поддержка и сопровождение

1:0. Монолит сложно поддерживать, если ушел разработчик

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

1:1. Обслуживание микросервисов дороже: Kubernetes, DevOps, и т.д.

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

Масштабирование

1:0. Монолит сложно масштабировать

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

1:1. В пиковые часы можно нарастить ресурсы для монолита

Переделывание монолитной системы на микросервисы — долгий и дорогостоящий процесс. Иногда проблему перегрузки можно решить быстрее и дешевле временным увеличением вычислительных мощностей (например, арендуя виртуальные CPU в облаке). Такой подход позволит избежать больших вложений в изменение архитектуры, сохраняя работоспособность системы во время высоких нагрузок.

Разработка ИТ-решений

1:0. Равномерность разработки

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

2:0. Распределение ответственности между командами

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

3:0. Изоляция ответственности благодаря Kafka

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

4:0. У монолита проблемы в плане информационной безопасности

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

4:1. Отчуждаемый код

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

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

Итого 8:4 в пользу микросервисов? Точно?

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

Что и зачем нужно для создания микросервисов

Критерии деления на микросервисы

Изначально всё зависит от типа серверной инфраструктуры. А далее — от масштабов нарезки на микросервисы.

Микросервисы для облаков, монолит — в он-преме

Преимущества микросервисов в облаке:

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

Почему монолит удобен для on-premise решений:

• Простота развертывания и обслуживания на собственных серверах.
• Меньшие накладные расходы на инфраструктуру.
• Низкая потребность в специальных инструментах типа Kubernetes или Docker.

Таким образом, выбор зависит от конкретной инфраструктуры и потребностей организации.

Обслуживание обвязки МС не более 30% проекта

Микросервисы требуют значительных ресурсов на создание и поддержку среды развертывания (Kubernetes, оркестрация контейнеров, автоматизация CI/CD-процессов, мониторинг, управление конфигурациями и версиями).

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

Порядка 40 таблиц СУБД на один микросервис

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

Считается разумным деление на микросервисы таким образом, чтобы на него приходилась СУБД в 20-50 таблиц. Более крупные микросервисы уже очень сложны. Более мелкие тоже не имеют смысла, лучше укрупнить.

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

Один запрос — один или несколько МС (не десятки)

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

Хорошее решение — оптимизировать структуру сервиса таким образом, чтобы большинство операций могли выполняться в рамках небольшого числа микросервисов. Оптимальным считается ситуация, когда запрос выполняется двумя-тремя микросервисами, а не десятью-двадцатью.

Самостоятельная коммерческая ценность микросервиса

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

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

Как избежать микросервисной архитектуры

Если вы не планируете создание микросервисной архитектуры, то рассмотрите альтернативные сценарии, приведенные ниже.

Создавать вспомогательные библиотеки для монолита

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

Вместо разделения на многочисленные микросервисы, используйте стандартные практики структурирования монолитного приложения: создайте удобные внутренние API, разделяйте логику на слои и следуйте принципу DRY («Don’t Repeat Yourself»).

Мыслить на уровне сервисов, а не микросервисов

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

Модульный монолит

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

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

Готовое ПО вместо разработки микросервисов

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

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

Полезные книги по микросервисам

Автор	Название книги в оригинале	Название книги на русском
Эрик Эванс	Domain-Driven Design: Tackling Complexity in the Heart of Software	Предметно-ориентированное проектирование (DDD): Структуризация сложных программных систем
Брюс Эккель	Thinking in Java	Философия Java
Роберт С. Мартин	Clean Code: A Handbook of Agile Software Craftsmanship	Чистый код: основы профессионального программирования
	Clean Architecture: A Craftsman’s Guide to Software Structure and Design	Чистая архитектура: искусство разработки программного обеспечения
Крис Ричардсон	Microservice Patterns: Implementing Service-Oriented Architectures with Spring Boot and Spring Cloud	Паттерны микросервисов: реализация сервис-ориентированной архитектуры с использованием Spring Boot и Spring Cloud
Мартин Фаулер	Microservices article	(Нет официального перевода статьи, опубликована на сайте O’Reilly)
Джеймс Хеви	Testable Objects series	(Серия статей о создании тестируемых объектов, нет официальной русской книги)
Сам Ньюман	Building Microservices	Создание микросервисов
Марти́н Фа́улер	Patterns of Enterprise Application Architecture	Шаблоны корпоративных приложений
Марк Харрис	Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions	Интеграция корпоративных приложений: разработка, построение и эксплуатация решений обмена сообщениями

Заключение

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

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

Таким образом, хотя микросервисы открывают широкие перспективы развития, их успешное применение требует зрелости IT-инфраструктуры и значительного опыта DevOps-команд.