Граница сервиса следует за задачей
Разделять приложение исключительно по техническим слоям часто неудобно: одна пользовательская операция начинает требовать изменения во множестве сервисов. Полезнее рассмотреть предметные обязанности. В учебном магазине можно выделить каталог, оформление заказа и уведомления. Однако это ещё не готовое решение: нужно понять, какие правила и данные тесно связаны. Если две части постоянно требуют синхронных изменений, граница может быть проведена неудачно. Модульный монолит остаётся допустимым вариантом, когда независимое развёртывание не приносит достаточной пользы.
Владение данными уменьшает скрытую связанность
Сервис должен иметь понятную ответственность за свои данные и предоставлять согласованный способ взаимодействия. Если соседние сервисы напрямую изменяют его таблицы, внутренняя схема превращается в общий неявный договор. Тогда простое изменение структуры может сломать чужую работу. Передача данных через интерфейс или событие делает зависимость видимой. При этом копии сведений в разных местах не обязательно обновляются одновременно. Проект должен определить, где временное расхождение допустимо, а где требуется иной способ согласования.
Сетевой вызов может завершиться неопределённо
Отсутствие ответа не всегда означает, что операция не выполнена. Например, сервис заказов отправил запрос, получатель обработал его, но подтверждение потерялось. Слепой повтор способен создать дубликат. Поэтому для повторяемых команд продумывают идентификатор операции и правила идемпотентности: повтор одного намерения не должен бесконтрольно создавать новый результат. Нужны также ограниченные ожидания ответа, понятная обработка ошибок и наблюдаемость. Бесконечные повторы могут увеличить нагрузку именно тогда, когда зависимый сервис уже испытывает трудности.
Проверять нужно всю цепочку
Успешный тест отдельной функции не доказывает работоспособность распределённого сценария. Полезны проверки договоров между сервисами, обработки повторов и поведения при недоступности зависимости. Журналы должны позволять связать шаги одной операции без ненужного раскрытия личных данных. Отдельно продумывают изменение версий интерфейса: отправитель и получатель не всегда обновляются одновременно. Маленький сервис удобен только тогда, когда его назначение, эксплуатация и взаимодействие остаются понятными людям, которые поддерживают систему.
Попробуйте на практике
Спроектируйте на бумаге учебную цепочку заказа без установки программ и обращения к реальным системам.
- Нарисуйте три блока: каталог, заказы и уведомления; подпишите данные, за которые отвечает каждый.
- Проведите стрелки обмена и для каждой укажите, требуется немедленный ответ или допустима обработка позже.
- Добавьте сценарий: заказ сохранён, но подтверждение потерялось. Опишите, как повтор запроса узнаётся как та же операция.
- Выберите один сбой и запишите, что увидит пользователь, что останется в журнале и как система продолжит работу.
Как проверить результат. У каждого набора данных есть владелец, повтор не создаёт второй заказ автоматически, а выбранный сбой имеет явное поведение вместо бесконечного ожидания.
Частые вопросы
Нужно ли выделять отдельный сервис для каждой таблицы?
Нет. Таблица является способом хранения, а граница сервиса должна отражать связную ответственность и правила. Слишком мелкое деление увеличивает число взаимодействий.
Микросервисы всегда ускоряют разработку?
Нет. Независимость отдельных частей приходится оплачивать сетевыми взаимодействиями, наблюдаемостью и эксплуатацией. Для небольшой системы эти затраты могут превышать пользу разделения.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.