# Монолит vs Микросервисы

|                              | Монолит        | Микросервисы                              |
| ---------------------------- | -------------- | ----------------------------------------- |
| Масштабирование              | Только целиком | Можно масштабировать отдельные компоненты |
| Устойчивость к сбоям         | Низкая         | Высокая                                   |
| Развертывание                | Только целиком | Можно разворачивать отдельные компоненты  |
| Гибкость в выборе технологий | Ограничен      | Свободный                                 |
| Time-to-market продуктов     | Низкий         | Высокий                                   |
| Управление разработкой       | Сложное        | Простое                                   |
| Зависимость от модели данных | Есть           | Нет                                       |

## Выбор правильной архитектуры для вашего проекта <a href="#vybor-pravil-noi-arkhitektury-dlia-vashego-proekta" id="vybor-pravil-noi-arkhitektury-dlia-vashego-proekta"></a>

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

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

## Ключевые отличия монолитной архитектуры от микросервисов

Сравнение двух данных архитектур позволяет выявить нам следующие ключевые отличия:

* **Структура приложения**

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

* **Простота разработки и тестирования**

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

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

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

* **Зависимости**

В монолитной архитектуре отсутствуют зависимости между компонентами, в то время как в микросервисах управление зависимостями становится более сложной задачей.

## Основные признаки, что вам нужно переходить на микросервисную архитектуру <a href="#osnovnye-priznaki-chto-vam-nujno-perehodit-na-mikroservisnuu-arhitekturuu" id="osnovnye-priznaki-chto-vam-nujno-perehodit-na-mikroservisnuu-arhitekturuu"></a>

### Рост нагрузки <a href="#rost-nagruzki" id="rost-nagruzki"></a>

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

Пример: изначально была монолитная CMS Bitrix, товарная база насчитывала 7-9 тыс. товаров, но сейчас они активно развиваются и в скором времени товарная база пополнится еще на 1 млн. товаров. Такое резкое расширение товаров существенно увеличит нагрузку на:

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

### Рост системы, разработка нового функционала <a href="#rost-sistemy-razrabotka-novogo-funkcionala" id="rost-sistemy-razrabotka-novogo-funkcionala"></a>

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

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

### Проблемы со скоростью доставки каждого нового релиза <a href="#problemy-so-skorostu-dostavki-kajdogo-novogo-relizaa" id="problemy-so-skorostu-dostavki-kajdogo-novogo-relizaa"></a>

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

Источники:&#x20;

* <https://iqdev.digital/blog/perehod-na-mikroservisnuyu-arhitekturu-perejti-nelzya-ostatsya>
* <https://vc.ru/dev/922352-monolitnaya-vs-mikroservisnoy-arhitektury>
* <https://appmaster.io/ru/blog/monolitnaia-i-mikroservisnaia-arkhitektura>
* <https://cloud.mts.ru/cloud-thinking/blog/monolitnaya-i-mikroservisnaya-arhitektura/>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.system-analyst-base.ru/hard-skills/proektirovanie/arkhitektura/monolit-vs-mikroservisy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
