Зачем нужен микросервис?

Зачем нужен микросервис?

Микросервисная архитектура решает критические проблемы, возникающие при росте систем и команд. Вот основные причины её применения:

Независимое развитие и развёртывание

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

// Пример: сервис Billing работает независимо
[ApiController]
[Route("api/v1/billing")]
public class BillingController : ControllerBase
{
    [HttpPost("charge")]
    public async Task<IActionResult> ChargeUser(ChargeRequest request)
    {
        // Логика биллинга, своё хранилище, свои зависимости
        return Ok(new { transactionId = Guid.NewGuid() });
    }
}

Масштабируемость

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

Отказоустойчивость

Если один микросервис падает, это не обрушит всю систему. Остальные сервисы продолжают работать. Используются паттерны Circuit Breaker и Retry для изоляции отказов.

// Использование Polly для отказоустойчивости
var policy = Policy
    .Handle<HttpRequestException>()
    .CircuitBreaker(handledEventsAllowedBeforeBreaking: 3, 
                   durationOfBreak: TimeSpan.FromSeconds(30));

await policy.ExecuteAsync(async () => 
    await httpClient.GetAsync("https://notification-service/send")
);

Технологическая гибкость

Каждый сервис может использовать свой стек технологий: один написан на C#, другой на Node.js, третий на Go. Это позволяет выбрать оптимальный язык для каждой задачи.

Изолированные данные

Каждый микросервис имеет собственную БД. Это предотвращает случайные зависимости между сервисами и облегчает масштабирование хранилища.

Команды, ориентированные на бизнес

Микросервисы позволяют организовать команды по доменам (Users, Products, Orders), а не по технологиям. Каждая команда отвечает за весь стек своего сервиса — от API до БД.

Минусы: сложность операций, распределённые транзакции, задержки в сетевых запросах. Начинать с микросервисов не стоит — лучше эволюционировать из монолита.