Введение
Микросервисная архитектура – архитектурный стиль, при котором приложение строится как набор небольших, независимо развёртываемых сервисов, каждый из которых реализует чётко ограниченную бизнес-функцию («ограниченный контекст»). Сервисы взаимодействуют через легковесные механизмы – как правило, HTTP/REST API или асинхронные очереди сообщений – и могут разрабатываться, тестироваться и развёртываться независимо друг от друга.
Микросервисы появились как ответ на проблемы роста монолитных приложений: тяжёлые монолиты сложно масштабировать, медленно развёртывать и трудно поддерживать при росте команды. Netflix, Amazon, Uber стали первопроходцами в промышленном применении микросервисов в 2010-е годы.
История и контекст
Термин «микросервисы» был популяризирован Мартином Фаулером и Джеймсом Льюисом в их знаменитой статье 2014 года. Фактически архитектурные паттерны, описанные в статье, использовались Netflix с 2009 года при переходе на облако AWS, а Amazon – с начала 2000-х через «two-pizza rule» Безоса.
В России микросервисы активно внедряют с 2015–2018 годов. Сбербанк, Тинькофф, Яндекс, крупные телеком-операторы перешли с монолитов на микросервисные платформы для ускорения разработки. Параллельно выросла экосистема: Docker (2013), Kubernetes (2014–2015), service mesh (Istio, Linkerd), CI/CD-инструменты.
Как это работает
Ключевые принципы микросервисной архитектуры:
- Единственная ответственность – каждый сервис делает одну вещь хорошо (Single Responsibility Principle).
- Независимое развёртывание – сервисы деплоятся независимо через CI/CD пайплайны.
- Децентрализованное управление данными – каждый сервис владеет своей БД (database per service).
- Умные конечные точки, тупые каналы – логика в сервисах, передача данных через простые протоколы.
- Проектирование для отказов – каждый сервис должен обрабатывать недоступность зависимостей (circuit breaker, retry, fallback).
Типовой стек: контейнеры Docker, оркестрация Kubernetes, API Gateway (Kong, nginx), service mesh (Istio), мониторинг (Prometheus/Grafana), трассировка (Jaeger), брокер сообщений (Kafka, RabbitMQ).
Где применяется
- Банки и финтех – независимая разработка продуктов: кредиты, вклады, платежи – каждый как отдельный сервис.
- E-commerce – каталог, корзина, оплата, доставка – независимые сервисы с разными требованиями к нагрузке.
- Телеком – разделение BSS (биллинг, CRM) и OSS (управление сетью) на микросервисы.
- Цифровые платформы – агрегаторы, маркетплейсы с высокими требованиями к масштабируемости.
Преимущества и ограничения
Преимущества: независимое масштабирование компонентов, ускорение разработки через параллельные команды, технологическая гибкость (разные языки и БД для разных сервисов), изоляция отказов, упрощение CI/CD.
Ограничения: значительное усложнение инфраструктуры и операций (distributed systems problem). Латентность сетевых вызовов между сервисами. Сложность распределённых транзакций. Overhead на коммуникацию и сериализацию. Требует зрелого DevOps.
Связь с другими понятиями
Событийная архитектура часто используется совместно с микросервисами для асинхронного взаимодействия. ESB и iPaaS – альтернативный/дополняющий подход к интеграции. Интеграционная шина в микросервисах заменяется на API Gateway и брокеры событий. Контейнеры (Docker, Kubernetes) – стандартная среда выполнения микросервисов.
