Какие критерии вы бы использовали для разделения системы на микросервисы?

Question

Разделять систему на микросервисы стоит по бизнес-границам, а не по слоям (UI/DAO/Service). Хороший критерий — сервис отвечает за одну понятную область и владеет своими данными. Важно, чтобы изменения внутри сервиса редко требовали синхронных изменений в других сервисах. Также смотрят на независимый деплой, разные требования к масштабированию и разные темпы изменений. Если границы неочевидны — лучше начинать с более крупных модулей и уточнять их по мере опыта.

YeaHub · Accepted Answer

ОпределениеРазделение на микросервисы — это разбиение системы на автономные компоненты, каждый из которых реализует свою бизнес-способность и может разрабатываться/деплоиться независимо.Ключевые критерии декомпозицииБизнес-границы (bounded context)Сервис соответствует одному домену/поддомену: “оплата”, “доставка”, “каталог”.Внутри сервиса термины и правила не противоречат сами себе.Владение даннымиУ сервиса есть свой источник истины (своя схема/БД/таблицы).Другие сервисы не “ходят” напрямую в его БД, а используют API/ивенты.Слабая связанность измененийЕсли фича часто требует правок сразу в 3–4 компонентах, граница проведена плохо.Цель — чтобы большинство изменений были локальными.Независимый деплойСервис можно выкатывать без обязательного “синхронного” релиза соседей.Контрактная совместимость важнее общих библиотек “на все случаи”.Разные требования к нагрузке и масштабированиюЕсли один участок системы требует x10 CPU, а другой — нет, это аргумент к разделению.Но “разная нагрузка” — не повод дробить слишком мелко.Разные требования к надежности и критичностиКритичный сервис может требовать других SLA, алертов, изоляции отказов.Командные границыОдин сервис — одна команда (в идеале): меньше координации, быстрее релизы.Если сервисом владеют “все”, он обычно становится монолитом внутри микросервисов.Типовые ошибкиДелить “по слоям” (users-api, users-db, users-worker) вместо бизнес-способностей.Делать сервисы слишком маленькими до появления реальной необходимости.Общая база данных на всех сервисов → формально микросервисы, фактически монолит.Практический мини-пример (как проверять границу)# Плохой сигнал: сервис "Order" напрямую читает таблицы "Payments"
# Вместо этого — запрос к API платежей или событие PaymentCompleted.

payment_status = payments_client.get_status(order.payment_id)  # ок
# payment_status = db.query("select ... from payments")        # плохо
ВыводДекомпозировать на микросервисы стоит по бизнес-границам + владению данными + независимости изменений, а не ради “модной архитектуры”.