Премиум

Основы микросервисов

Базовый System Design
≈ 2 мин чтения

Микросервис — самостоятельная часть системы

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

Client -> API Gateway -> Orders Service
                    \-> Payments Service
                    \-> Users Service

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

Независимость даёт новые возможности

Отдельный сервис можно масштабировать под его нагрузку, развёртывать чаще остальных и поручить команде, которая полностью отвечает за его развитие. Сбой одного компонента также не обязан немедленно останавливать весь продукт, если остальные части умеют корректно работать с его временной недоступностью.

Но эта независимость появляется вместе с сетью. Вызовы могут завершаться по таймауту, версии контрактов приходится согласовывать, а единая операция пользователя может затронуть несколько процессов.

Микросервисы требуют организационной зрелости

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

«Микро» не означает «как можно меньше». Граница сервиса должна быть достаточно узкой для самостоятельности, но достаточно цельной, чтобы не превращать одну бизнес-операцию в цепочку десятков сетевых вызовов.
Назад Далее