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

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

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

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

Стоит ли новый продукт делать монолитом

Почти всегда да, и у подхода есть имя: monolith first (Мартин Фаулер, 2015).

• Границы неизвестны. В новом продукте предметная область меняется каждую неделю. Граница внутри монолита переносится рефакторингом за час; между сервисами она обойдётся в миграцию данных, версионирование API и несколько недель координации релизов. Ошибиться в границах на старте нормально.
• Продукт может не выжить. Инфраструктурный налог платится сразу, а окупается через год-два. Тратить первые три месяца на Kubernetes и трейсинг вместо проверки гипотезы не стоит.
• Обратный путь дороже прямого. Разрезать монолит по живой границе неприятно, но реально. Склеивать обратно десять сервисов, у каждого из которых своя БД и свой контракт, мучительно. Segment схлопнул полторы сотни таких сервисов в один, Istio слил управляющие компоненты в istiod, Prime Video собрал свой конвейер анализа видео обратно в один процесс - и каждый раз это стоило дорого.

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

Модульный монолит: как его строить в Go

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

Практические правила, которые делают монолит модульным (а не «просто монолитом с папками»):

1. У модуля публичный API и приватные потроха. internal/order/ экспортирует order.Service и доменные типы, всё остальное пишется с маленькой буквы или прячется в подпакет internal/order/internal/…, куда компилятор просто не пустит чужих.
2. Модули общаются только через публичные интерфейсы модулей, а не через чужие репозитории и таблицы. Хочешь пользователя - зови user.Service, а не SELECT * FROM users.
3. Схема БД разделена по модулям. Отдельные схемы Postgres (orders.*, users.*) или хотя бы явное соглашение о префиксах. Запрет на JOIN между схемами разных модулей соблюдать тяжелее всего, и он же ценнее всего: именно совместные JOIN-ы потом делают распил невозможным.
4. Внутримодульные события вместо прямых вызовов там, где связь «уведомить». Простая шина в памяти сегодня превращается в Kafka завтра, а код модулей не меняется.
5. Границы проверяются автоматически. Линтер импортов (depguard, go-arch-lint) в CI: правило «никто, кроме order, не импортирует order/internal». Без такой проверки границы разъезжаются за квартал.

// internal/order/service.go - публичный контракт модуля
package order

type Service struct {
    repo    repository          // приватный интерфейс модуля
    users   UserProvider        // порт к соседнему модулю: только то, что нужно
    events  EventPublisher      // сегодня шина в памяти, завтра Kafka
}

// Порт: order не знает про пакет user, только про свой узкий интерфейс.
type UserProvider interface {
    ByID(ctx context.Context, id string) (Customer, error)
}

// main.go - единственное место, где модули встречаются
orderSvc := order.NewService(orderRepo, userAdapter{userSvc}, bus)

Когда монолит действительно упирается в потолок

«Стало много кода» ни о чём не говорит. Есть монолиты на миллионы строк, которые прекрасно живут. Настоящие признаки касаются людей и эксплуатации, и все они измеримы:

Стратегии распила

Strangler fig по шагам

1. Поставить фасад. Reverse proxy (nginx/Envoy/API Gateway) перед монолитом, который сначала проксирует 100 % трафика без изменений. Шаг важнее всех остальных: появляется точка, где можно переключать маршруты, не трогая клиентов.
2. Выбрать первый кусок. Не самый важный, а самый изолированный: мало данных, мало связей, понятный контракт. Обычно это уведомления, экспорт отчётов, загрузка файлов. Первый распил тренирует инфраструктуру, а не приносит бизнес-ценность.
3. Разделить данные до кода. Таблицы будущего сервиса перестают участвовать в JOIN-ах монолита; вместо прямых запросов появляются вызовы модуля. Это самая долгая часть, и её делают внутри монолита, пока откат бесплатный.
4. Написать сервис и включить двойную запись/чтение. Запросы идут в оба места, результаты сравниваются в фоне (shadow / dark launch). Расхождения это найденные баги, а не повод останавливаться.
5. Переключить маршрут на фасаде. Сначала 1 % трафика, потом 10 %, потом 100 %. Откат мгновенный.
6. Удалить код из монолита. Шаг, который пропускают чаще всего. Если старый код остался «на всякий случай», через полгода у тебя два источника правды и никто не помнит, какой живой.

Branch by abstraction

Альтернатива фасаду для случая, когда заменяемый кусок сидит внутри кода и наружу не торчит (нельзя переключить по URL). Порядок: (1) вводим абстракцию - интерфейс над старой реализацией, все вызовы идут через него; (2) пишем вторую реализацию, которая ходит в новый сервис; (3) переключаем по фиче-флагу, можно по проценту пользователей; (4) удаляем старую реализацию и, при желании, саму абстракцию. Всё это живёт в главной ветке, ничего не висит в долгоживущем бранче, отсюда и название.

type PricingEngine interface {
    Price(ctx context.Context, cart Cart) (Money, error)
}

// Флаг-переключатель: обе реализации живут одновременно
type switching struct {
    old, new PricingEngine
    flags    Flags
    log      *slog.Logger
}

func (s *switching) Price(ctx context.Context, c Cart) (Money, error) {
    if !s.flags.Enabled(ctx, "pricing_v2") {
        return s.old.Price(ctx, c)
    }
    // «тёмный» прогон: считаем новым, но отдаём старое, пока не совпадёт
    got, err := s.new.Price(ctx, c)
    want, errOld := s.old.Price(ctx, c)
    if err == nil && errOld == nil && got != want {
        s.log.Warn("pricing mismatch", "new", got, "old", want, "cart", c.ID)
    }
    return want, errOld
}

Антипаттерн: распределённый монолит

Признаки, по которым его узнают:

• Общая база данных. Два сервиса пишут в одну таблицу, значит это один сервис, разложенный по двум процессам. Миграция схемы становится общесистемным событием.
• Релиз «поездом». Чтобы выкатить фичу, нужно выкатить три сервиса в правильном порядке, и откат тоже по порядку.
• Длинные синхронные цепочки. Один клиентский запрос порождает 5–10 последовательных вызовов; латентность складывается, доступности перемножаются.
• Общая библиотека с доменными типами. Изменил структуру в shared-пакете - обязан пересобрать и выкатить всех потребителей. Это компиляционная связность, просто спрятанная в go.mod.
• Нельзя протестировать сервис в одиночку. Для локального запуска нужен docker-compose на восемь контейнеров.

Как проводить границы сервисов

Рабочие критерии границы, по убыванию надёжности:

1. Bounded context из DDD. Граница проходит там, где меняется смысл слова. «Заказ» в корзине это черновик с товарами; в доставке - адрес, вес и маршрут; в бухгалтерии - сумма и НДС. Три разных модели одного слова дают три кандидата в сервисы. Общая «универсальная» модель заказа, которая устраивает всех, не устраивает никого и намертво связывает команды.
2. По данным, а не по действиям. Сервис эксклюзивно владеет своими таблицами и остаётся для них единственным источником правды. Если для одной операции нужна транзакция по таблицам двух сервисов, значит граница проведена неверно, и это самый сильный сигнал.
3. По причине изменения. Смотришь историю git: какие файлы меняются вместе. То, что всегда правится одним коммитом, должно жить в одном сервисе. Это буквально SRP, поднятый на уровень системы.
4. По команде (закон Конвея). Система копирует структуру коммуникаций организации. Если границы сервисов не совпадают с границами команд, побеждают команды: код всё равно расползётся по чужим сервисам. При «обратном манёвре Конвея» сначала строят команды так, как хотят видеть архитектуру.
5. По требованиям к нагрузке и SLA. Кусок с другим профилем трафика или другой требуемой доступностью тянет на отдельный сервис, даже если доменно он невелик.

Из DDD при нарезке пригодятся ещё два правила. Агрегат задаёт границу транзакции, поэтому он никогда не должен пересекать границу сервиса. А легаси-монолит при распиле обычно отгораживают anticorruption layer, чтобы его модель не протекала в новые сервисы.

Полная цена микросервисов

• Сеть вместо вызова функции. Вызов метода занимает единицы наносекунд, вызов по сети внутри датацентра сотни микросекунд плюс сериализация. Это пять-шесть порядков. Плюс сеть ненадёжна: таймауты, ретраи, дубликаты, частичные отказы становятся частью бизнес-логики.
• Консистентность. Транзакции больше нет. Всё, что раньше было одним BEGIN … COMMIT, превращается в сагу с компенсациями, outbox и идемпотентными обработчиками. Это не «немного кода», а отдельная подсистема со своим состоянием и багами.
• Наблюдаемость обязательна, а не желательна. Без distributed tracing, единого сбора логов с trace_id и метрик по каждому вызову отладка превращается в гадание. Это отдельный стек (OpenTelemetry, Jaeger/Tempo, Prometheus, Loki) со своей стоимостью хранения.
• Инфраструктура и эксплуатация. Оркестратор, реестр образов, service discovery, секреты, N пайплайнов CI, N дашбордов, N алертов, дежурства и рантбуки. Плюс средства локальной разработки, чтобы человек мог поднять кусок системы на ноутбуке.
• Версионирование контрактов. Ни один сервис нельзя выкатить, сломав контракт: нужны обратная совместимость, дедлайны миграции и contract-тесты.
• Дублирование данных и кода. Копии справочников в нескольких сервисах, их синхронизация, повторяющаяся обвязка (аутентификация, логирование, конфиг). Дальше или копипаста, или общая платформенная библиотека со своей проблемой версий.
• Когнитивная нагрузка. Понять один сервис легко, понять систему тяжело. Нужна карта сервисов и владельцев, иначе появляются «сервисы-сироты», которые все боятся трогать.

Что стоит запомнить

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

Частые ошибки

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

type UserProvider interface {
    ByID(ctx context.Context, id string) (Customer, error)
}
userProvider := user.NewService(userRepo)
orderSvc := order.NewService(repo, userProvider, eventPublisher)
server := httpapi.NewHandler(orderSvc)

price, err := pricing.Get(ctx, sku)
if err != nil { return err }
stock, err := inventory.Get(ctx, sku)
if err != nil { return err }
promo, err := promotion.Get(ctx, sku)
if err != nil { return err }
return writeResponse(price, stock, promo)