---
aliases:
  - связи микросервисов
tags:
  - maturity/🌱
date: 2024-11-26
---
В [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисной архитектуре]] каждый [[Микросервис|сервис]] имеет зависимости, которые можно разделить на **входящие** и **исходящие**:
- **Входящие зависимости** — это другие сервисы или клиенты, которые полагаются на данный сервис для выполнения своих задач.
- **Исходящие зависимости** — это внешние системы или микросервисы, от которых данный сервис зависит для выполнения своих функций.
## Входящие зависимости
Сервисы с высокой входящей зависимостью обычно выполняют функции, на которых завязаны многие другие компоненты. Отказ такого сервиса может привести к масштабным сбоям, поэтому требуется масштабируемость, мониторинг и резервирование.

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

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

Высокое число исходящих зависимостей может замедлять работу сервиса из-за сетевых задержек, ограничения пропускной способности или API-лимитов.
## Типы микросервисов на основе зависимостей
- **Центральные (Hub)**
	- Много входящих зависимостей, мало исходящих.
	- Выполняют ключевые функции, от которых зависят другие.
	- Пример: [[API Gateway]] или сервис аутентификации.
- **Агрегаторы**
	- Много исходящих зависимостей, среднее число входящих.
	- Сбор и обработка данных из множества источников.
	- Пример: сервис аналитики или отчётности.
- **Специализированные (Leaf)**
	- Мало входящих и исходящих зависимостей.
	- Выполняют автономные задачи, минимально влияя на другие части системы.
	- Пример: сервис генерации отчетов.
- **Мосты (Bridge)**
	- Баланс между входящими и исходящими зависимостями.
	- Соединяют разные домены или внешние API с внутренними сервисами.
- Пример: сервис интеграции с внешней платежной системой.
## Рекомендации
- **Минимизируйте исходящие зависимости**. Ограничьте количество внешних систем, от которых зависит сервис. Агрегируйте зависимости, чтобы уменьшить количество прямых связей.
- **Делайте отказоустойчивые сервисы с высокой входящей зависимостью**. Используйте [[кэширование]], [[highload/Балансировка нагрузки|балансировщики нагрузки]] и [[highload/Горизонтальное масштабирование|горизонтальное масштабирование]], чтобы снизить риски.
- **Используйте асинхронные коммуникации**. Асинхронные подходы (например, через [[Брокер сообщений|брокеры сообщений]]) помогают уменьшить плотность зависимостей и снизить нагрузку.
- **Мониторьте зависимости**. Отслеживайте состояние входящих и исходящих зависимостей с помощью [[Архитектурная схема|архитектурных схем]], чтобы своевременно выявлять узкие места и проблемы.
- **Сегментируйте систему** Разделение архитектуры на домены помогает уменьшить плотность зависимостей и сделать систему более управляемой.
***
## Мета информация
**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
**Родитель**:: 
**Источник**:: 
**Создана**:: [[2024-11-26]]
**Автор**:: 
### Дополнительные материалы
- 

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