Архитектура микросервисов (MSA) и распределённые системы
Статья связывает три темы — что такое распределённая система, чем монолит отличается от микросервисов, и какие подходы к масштабированию применяют на практике. Если вы уже прошли масштабирование и балансировку, здесь — архитектурный контекст: зачем вообще дробить приложение и как MSA вписывается в рост нагрузки.
Распределение и MSA
Распределённая система
Распределённая система — это совокупность независимых компонентов (серверов, узлов, микросервисов), которые взаимодействуют друг с другом через сеть для выполнения общей задачи.
Эти компоненты могут находиться в разных физических местах, но для конечного пользователя система выглядит как единое целое. Распределёнными могут быть микросервисы, базы данных NoSQL и CDN (Content Delivery Networks).
Зачастую приложение поначалу бывает монолитным. Пример - работа новичка, который только изучил язык программирования и написал простенькое приложение, оформив его в едином проекте. У приложения куча функций, но если одна из функций сбоит - падает всё приложение. И только после этого возникает идея распределения этой системы по компонентам, развернув их как два независимых приложения, которые друг с другом взаимодействуют, что представляет собой более продвинутую технологию.
Монолитное приложение
Монолитное приложение (Monolith) — это традиционная архитектура программного обеспечения, в которой все компоненты системы (бизнес-логика, пользовательский интерфейс, база данных и т.д.) объединены в единый исполняемый модуль или кодовую базу. Кодовая база, как правило, единая, все функциональные модули находятся в одном проекте и разворачиваются как единое целое. Обычно используется одна база данных для всех компонентов системы, а для обновления любой части системы требуется пересобрать и перезапустить всё приложение.
Масштабирование систем
Семь стратегий на уровне данных (индексы, кэш, репликация, шардинг и др.) — в обзоре масштабирования РСУБД. Ниже — как те же идеи ложатся на архитектуру сервисов.
Подходы к масштабирование
Какие бывают подходы к масштабированию?
- Микросервисная архитектура — каждый сервис масштабируется отдельно. Если сервис авторизации получает пик логинов, увеличивают только его реплики, не трогая каталог или оплату. Требует чётких контрактов и observability.
- Шардирование (Sharding) — данные делят по ключу (регион,
user_id % N). Снижает размер индексов на одном узле БД; усложняет JOIN между шардами и миграции. См. NoSQL, семь стратегий масштабирования БД, шардинг в обзоре РСУБД. - Кэширование — Redis/Memcached для горячих ключей (профиль, справочники). Cache-aside: сначала кэш, при промахе — БД. Инвалидация при обновлении — отдельная дисциплина. Сводка — семь стратегий, девять рычагов производительности.
- Асинхронная обработка — пики сглаживаются очередью (RabbitMQ, Kafka): HTTP быстро отвечает "принято", воркеры догоняют позже.
- Облачные решения — autoscaling групп, managed Kubernetes, serverless. Платите за фактическое потребление; нужен контроль лимитов бюджета.
- Гибридное масштабирование — сочетание вертикального и горизонтального масштабирования: например, увеличить RAM у primary БД и параллельно добавить read-replica + больше pod'ов API.
На практике грамотное масштабирование — работа администраторов, архитекторов и DevOps-инженеров — метрики, лимиты, runbook'и на инциденты. Это ключевой фактор успеха системы при росте пользователей и данных.
| Подход | Что разгружает в первую очередь |
|---|---|
| MSA | CPU/RAM конкретного сервиса |
| Шарды | Один огромный объём данных в БД |
| Кэш | Повторяющиеся чтения |
| Очереди | Пики записи и фоновые задачи |
| Облако | Операционная рутина по железу |
Микросервисная архитектура
Что такое MSA и что такое микросервис?
Поскольку микросервисная архитектура является наиболее востребованной и эффективной, мы поговорим именно о ней.
Микросервисная архитектура (Microservice Architecture, MSA) — подход, при котором приложение делят на независимые сервисы, каждый из которых выполняет свою задачу, разворачивается и масштабируется отдельно и взаимодействует с остальными через API или сообщения. Сервисы слабо связаны по коду, но опираются на общую инфраструктуру — БД, брокеры, контейнеры, мониторинг, CI/CD и безопасность; сводная карта таких слоёв — экосистема технологий вокруг микросервиса.
Микросервис — это небольшой, автономный компонент программного обеспечения, который выполняет одну конкретную бизнес-функцию и работает в собственном процессе. Микросервисы взаимодействуют друг с другом через четко определенные API (например, REST, gRPC, Kafka) или асинхронные сообщения.
Каждый микросервис разрабатывается, развёртывается и масштабируется независимо от других, и решает только одну задачу или группу тесно связанных задач. Например, сервис авторизации, сервис обработки платежей, сервис каталога товаров. У микросервиса может быть своя база данных или хранилище данных, что изолирует его от других сервисов.
Разные микросервисы могут быть написаны на разных языках программирования и использовать разные технологии (например, один сервис на Java, другой на Python), их можно обновить или заменить, не затрагивая остальную часть системы. Микросервисы часто общаются через асинхронные очереди сообщений (например, Kafka, RabbitMQ), что снижает зависимость между компонентами.
Пример микросервисной архитектуры:
Здесь каждый сервис полностью независим, имеет свою базу данных, язык программирования и API. Сервисы общаются через API Gateway.
Декомпозиция — это процесс разделения монолитного приложения на набор микросервисов. Этот процесс требует тщательного анализа бизнес-логики и её структурирования, а также корректного подхода - допустим, декомпозировать по бизнес-функциям или по данным и технологическим требованиям.
API Gateway на схеме — единая точка входа для клиентов — маршрутизация, TLS, rate limit, иногда агрегация ответов. Внутренние сервисы не обязаны быть доступны из интернета напрямую.
Компоненты продакшн-стека
Учебная схема с тремя сервисами показывает идею MSA. В продакшене к ней добавляют инфраструктурные блоки, без которых распределённая система плохо живёт под нагрузкой:
| Блок | Зачем |
|---|---|
| Service Registry | Gateway и сервисы находят актуальные адреса инстансов после деплоя и autoscaling |
| Authorization Server | Единая выдача OAuth/OIDC-токенов; сервисы проверяют права, а не хранят пароли |
| Слой БД + репликация | Своя БД на сервис; копии для отказоустойчивости и чтения |
| Распределённый кэш | Redis и аналоги — горячие данные и сессии без лишних обращений к БД |
| Брокер сообщений | Асинхронные задачи, события, сглаживание пиков (Kafka, RabbitMQ) |
| Метрики и логи | Prometheus + Grafana, конвейер ELK (или Loki) — единая картина при инциденте; Практикум Prometheus и Grafana, PromQL — галерея; классическая инфраструктура — Практикум Zabbix |
Полная карта из девяти компонентов, схема потоков и ссылки на главы энциклопедии — в Паттернах микросервисной архитектуры. Таблица технологий по слоям (SQL/NoSQL, Kafka, K8s, Prometheus и др.) — экосистема MSA. Шпаргалка по балансировке, кэшу и gateway — 12 концепций.
Практический старт декомпозиции — первые шаги к микросервисам; компромиссы распределённых систем — PACELC.
Миграция с монолита
Полный "большой взрыв" — переписать всё и одним релизом переключить прод — в инфраструктурной практике почти не применяют. Вместо этого используют переходные паттерны, которые стыкуются с API Gateway, очередями и observability из этого раздела.
| Паттерн | Роль на стороне DevOps / платформы |
|---|---|
| Strangler Fig | Правила маршрутизации на балансировщике или gateway, canary, откат трафика |
| Parallel Run | Дублирование запросов, метрики расхождений, семплирование нагрузки |
| Decorating Collaborator | Sidecar или edge-proxy, синхронные вызовы к новому сервису рядом с legacy |
| CDC | Поток изменений из БД монолита в Kafka и проекции сервисов (Debezium и др.) |
Теория, сочетание паттернов и чеклист миграции — в главе проектирования Паттерны перехода от монолита к микросервисам. Декомпозиция по домену и данным — Стратегии декомпозиции; углублённый Strangler Fig — Strangler Fig.
Перед cutover нового сервиса в проде проверьте — сквозная трассировка, отдельные дашборды lag для CDC, политика отката маршрута на gateway и прогон Parallel Run на репрезентативном трафике.