---
aliases:
  - размер микросервиса
  - гранулярность микросервисов
  - декомпозиции на микросервисы
  - декомпозиции системы
tags:
  - maturity/🌱
date: 2024-11-24
---
Гранулярность микросервисов — это один из ключевых вопросов при проектировании распределённых систем. От неё зависит многое: гибкость архитектуры, масштабируемость, время разработки и стоимость поддержки. Однако определение оптимального размера каждого сервиса — задача не из лёгких.

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

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

**Принципы определения гранулярности**
1. **Бизнес-ориентированность**. Микросервис должен отражать конкретный бизнес-процесс или функциональную область. Если сервис охватывает слишком много бизнес-логики, его стоит разделить на более специализированные компоненты. Например, в системе для интернет-магазина логика управления заказами и обработка платежей должны быть разделены на два сервиса.
2. Правило [[Single Responsibility Principle|единственной ответственности]]. Каждый микросервис должен выполнять одну задачу и делать это хорошо. Если сервис отвечает за множество разнородных функций, вероятно, его стоит разделить. Например, сервис, отвечающий и за авторизацию, и за управление профилем пользователя, нарушает принцип единственной ответственности.
3. Слабая [[связанность]] и высокая [[Связность|связность]]. Сервисы должны быть слабо связаны друг с другом, чтобы изменения в одном не требовали изменений в других. В то же время внутренняя логика сервиса должна быть максимально когерентной — все функции должны быть тесно связаны и иметь смысл как единое целое.
4. **Коммуникационные накладные расходы**. При излишнем разделении микросервисов коммуникация между ними может стать значительной проблемой. Каждое взаимодействие требует сетевых запросов, которые увеличивают время отклика и усложняют тестирование. Избежать этого можно, объединяя сервисы, которые часто взаимодействуют друг с другом.
5. **Масштабируемость и независимость деплоя**. Один из ключевых факторов в пользу микросервисов — возможность масштабировать и развертывать сервисы независимо друг от друга. При этом важно помнить, что слишком мелкие микросервисы могут превратиться в головную боль для команды DevOps из-за увеличения количества деплоя и инфраструктурных задач.

**Подходы к выбору гранулярности**
- Разбиение по [[Доменная область|доменным областям]]. Этот подход предполагает разделение микросервисов по бизнес-доменам. Например, в системе для электронной коммерции могут существовать отдельные сервисы для управления каталогом товаров, работы с корзиной и обработкой платежей.
- **Использование событий**. [[Событийно-ориентированная архитектура|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы.
- **Практика "Strangler Fig"**. Этот метод подразумевает постепенное выделение функциональности из монолита в микросервисы. Это помогает определить оптимальную гранулярность, анализируя, какие части системы требуют частых изменений и могут быть разделены без излишних коммуникационных накладных расходов.

**Ошибки, которых следует избегать**
1. **Слишком крупные сервисы (микромонолиты)**. Они теряют преимущество независимости и приводят к тому, что разработчики вновь оказываются в рамках монолита, но с более сложной архитектурой деплоя и управления.
2. **Излишняя гранулярность**. Чрезмерное разделение приводит к лавине коммуникаций и делает систему неуправляемой. Это может также вызвать рост сложности в управлении транзакциями и согласованностью данных.
3. **Игнорирование бизнес-логики**. Определение границ микросервисов только на основе технических аспектов, без учёта бизнес-логики, приводит к нарушению когезии и снижению эффективности разработки.

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

***
## Мета информация
**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
**Родитель**:: [[Микросервис]]
**Источник**:: 
**Создана**:: [[2024-11-24]]
**Автор**:: 
### Дополнительные материалы
- 

### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Объединение данных из разных микросервисов]]
<!-- SerializedQuery END -->