Микросервисы и интеграция — итоги
Кратко — что стоит унести из раздела "Микросервисы и интеграция". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Типичные сбои и ситуации, с которыми сталкиваются новички после раздела. Здесь — что делать и где копать в главах; определения для зачёта — в чек-листе.
Вопрос. Разбили монолит на 20 микросервисов — деплой стал кошмаром, быстрее не стало.
Ответ. Микросервисы дают независимый deploy частей, но добавляют сеть, observability и ops. Часто достаточно модульного монолита; декомпозиция по bounded context, не "по каждому классу". Подробнее здесь — Архитектура микросервисов (MSA) и распределённые системы, Первые шаги к микросервисам.
Вопрос. Сервис A вызывает B, B вызывает A — deadlock или бесконечные retry.
Ответ. Циклические синхронные вызовы — антипаттерн. Разрывайте событиями, timeout, circuit breaker, пересмотрите границы. Подробнее здесь — Коммуникация и интеграция, Синхронная коммуникация.
Вопрос. REST между сервисами — "timeout" под нагрузкой, хотя CPU низкий.
Ответ. Смотрите pool потоков, лимиты соединений, cascade latency. Синхронная цепочка умножает задержки. Подробнее здесь — Синхронная коммуникация, User/Order сценарий.
Вопрос. Выбрали Kafka для пяти сообщений в час.
Ответ. Kafka — для потоков и replay; для простых задач очереди RabbitMQ или даже cron проще в сопровождении. Инструмент под паттерн, не под хайп. Подробнее здесь — Брокеры сообщений, RabbitMQ, Kafka.
Вопрос. Сообщение в очереди обработалось дважды — двойное списание денег.
Ответ. At-least-once доставка требует идемпотентности consumer (idempotency key, dedup). "Ровно один раз" без транзакции — дорого и редко. Подробнее здесь — Асинхронная коммуникация, Реализация интеграции.
Вопрос. Shared database между тремя "микросервисами".
Ответ. Это распределённый монолит: схема связана, deploy не независим. У каждого сервиса — своя БД или чёткий owner таблиц. Подробнее здесь — Архитектура микросервисов (MSA) и распределённые системы.
Вопрос. API Gateway — "ещё один монолит"?
Ответ. Gateway централизует auth, rate limit, routing, но бизнес-логику не дублируйте. Тонкий edge, толстые сервисы за ним. Подробнее здесь — Проектирование API, prodakshn-стек.
Вопрос. gRPC "быстрее REST" — переписали всё, gain нулевой.
Ответ. gRPC выигрывает на внутренних высокочастотных вызовах; для браузера и публичного API часто REST/GraphQL. Профилируйте, не мигрируйте вслепую. Подробнее здесь — REST, REST, GraphQL и gRPC — стили API.
Вопрос. GraphQL — один запрос, сервер упал от N+1 к микросервисам.
Ответ. Нужны DataLoader, лимиты глубины, batching. GraphQL не отменяет архитектуру backend. Подробнее здесь — REST, Проектирование API.
Вопрос. Webhook от партнёра пришёл три раза — три заказа.
Ответ. Webhooks — at-least-once; храните event id, идемпотентный handler. Подробнее здесь — 129 polling/SSE/webhook, Реализация интеграции.
Вопрос. Circuit breaker "всегда open" — сервис якобы мёртв.
Ответ. Пороги и half-open настроены агрессивно или upstream реально падает. Смотрите health downstream, timeout, bulkhead. Подробнее здесь — Коммуникация и интеграция.
Вопрос. Saga "откатила" платёж, но письмо клиенту уже ушло.
Ответ. Распределённая транзакция — компенсирующие действия, не ACID как в одной БД. Проектируйте happy path и rollback заранее. Подробнее здесь — Коммуникация и интеграция.
Вопрос. Eventual consistency — пользователь "не видит" свой заказ секунду.
Ответ. Нормально для async; UI показывает pending state, polling или SSE. Обещайте UX под модель данных. Подробнее здесь — Асинхронная коммуникация, Реактивная коммуникация.
Вопрос. Horizontal scale — сессии пользователя "прыгают" между pod.
Ответ. Sticky session хрупкий; лучше stateless JWT или session store (Redis). Подробнее здесь — Первые шаги к микросервисам, 8.06.
Вопрос. Service discovery: сервис "не находит" соседа после деплоя.
Ответ. DNS TTL, stale registry, неверное имя в K8s Service. Проверьте labels, namespace, readiness. Подробнее здесь — 8.06, Реализация интеграции.
Вопрос. Версия API v2 вышла — все мобильные клиенты сломались.
Ответ. Нужна обратная совместимость, deprecation window, contract tests. Breaking change без версионирования — инцидент. Подробнее здесь — Проектирование API, 117 REST principles.
Вопрос. ESB "решит все интеграции" — стал узким горлышком.
Ответ. Центральная шина без governance превращается в распределённый монолит. Часто легче API + события point-to-point с контрактами. Подробнее здесь — Коммуникация и интеграция.
Вопрос. SOAP "устарел" — но банк требует WSDL.
Ответ. Legacy интеграции живут годами; adapter-сервис между SOAP и внутренним REST — нормальный паттерн. Подробнее здесь — Справочник по SOAP, Протокол SOAP.
Вопрос. Kafka lag растёт — consumer "не успевает".
Ответ. Масштабируйте consumer group и partitions, оптимизируйте обработку, проверьте poison message. Подробнее здесь — Kafka, 123 Kafka basics.
Вопрос. RabbitMQ queue без DLQ — сообщения исчезают при ошибке.
Ответ. Настройте dead letter exchange, retry с backoff, мониторинг depth. Подробнее здесь — RabbitMQ, 122 Rabbit basics.
Вопрос. CAP/PACELC — "выберите CP или AP" и забудьте?
Ответ. Компромиссы по согласованности и задержке осознанны под сценарий: платёж и каталог — разные профили. Подробнее здесь — 124 PACELC, NoSQL CAP.
Вопрос. Distributed trace есть, но непонятно, кто виноват в 502.
Ответ. Пробрасывайте trace id через все hop; без него логи бесполезны. Подробнее здесь — 19 DevOps / logs, экосистема MSA.
Вопрос. Strangler Fig — полгода два стека параллельно, бюджет горит.
Ответ. Миграция по вертикальным срезам (один use case), не big bang. Feature flag на routing. Подробнее здесь — 112 миграция.
Вопрос. Contract test упал — prod ещё не тронули, кто прав?
Ответ. Consumer-driven contracts ловят несовместимость до деплоя. Provider не ломает контракт без согласования. Подробнее здесь — Реализация интеграции, 7.05 тестирование.
Вопрос. WebSocket "для всего" — firewall блокирует.
Ответ. Реактивный канал нужен для чат, live, игры; корпоративные proxy часто режут long-lived. Fallback SSE/long polling. Подробнее здесь — Реактивная коммуникация, практикум REST/WebSocket.
Вопрос. С чего начать, если HTTP и JSON ещё путаю?
Ответ. Сначала 2.09 HTTP и API basics, затем Первые шаги к микросервисам и Архитектура микросервисов (MSA) и распределённые системы. Подробнее здесь — intro.
Вопрос. Микросервисы — что это простыми словами?
Ответ. Приложение из независимых сервисов со своими БД и деплоем, связанных по сети (HTTP, очереди). Подробнее здесь — Первые шаги к микросервисам, Архитектура микросервисов (MSA) и распределённые системы.
Вопрос. Микросервисы vs монолит — когда что?
Ответ. Монолит проще на старте; микросервисы — при масштабе команды и нагрузки, ценой сложности сети. Не дробите "ради моды". Подробнее здесь — Архитектура микросервисов (MSA) и распределённые системы.
Вопрос. RabbitMQ — что это и зачем?
Ответ. Брокер очередей для асинхронных задач и decoupling сервисов; модель queue/exchange. Подробнее здесь — RabbitMQ, 2.09 / Rabbit.
Вопрос. Apache Kafka — для чего используют?
Ответ. Потоковая шина с топиками и партициями, replay и high throughput; не замена простой очереди задач. Подробнее здесь — Kafka, 2.09 / Kafka.
Вопрос. Kafka vs RabbitMQ — что выбрать?
Ответ. Rabbit — очереди и routing; Kafka — event log и analytics stream. Задача определяет инструмент. Подробнее здесь — Брокеры сообщений.
Вопрос. REST API — что это?
Ответ. HTTP-методы и ресурсы (JSON); стандарт интеграции в вебе. Подробнее здесь — REST, 2.09 / REST.
Вопрос. gRPC vs REST — в чём разница?
Ответ. gRPC — бинарный Protocol Buffers, быстрее внутри кластера; REST — проще для браузера и публичного API. Подробнее здесь — REST, REST, GraphQL и gRPC — стили API.
Вопрос. GraphQL — что это и когда нужен?
Ответ. Клиент запрашивает нужные поля одним запросом; гибко для mobile, сложнее кэш и N+1 на backend. Подробнее здесь — REST.
Вопрос. API Gateway — зачем нужен?
Ответ. Единая точка входа: auth, rate limit, routing к микросервисам. Подробнее здесь — Проектирование API.
Вопрос. Service mesh (Istio) — что это?
Ответ. Sidecar-proxy управляют mTLS, retry, traffic split между pod; для зрелого K8s, не для первого MVP. Подробнее здесь — 8.06, prodakshn-стек.
Вопрос. Event-driven architecture — определение?
Ответ. Сервисы обмениваются событиями через брокер, слабая связность; eventual consistency. Подробнее здесь — Коммуникация и интеграция, Асинхронная коммуникация.
Вопрос. Saga pattern — что это в микросервисах?
Ответ. Цепочка локальных транзакций с компенсациями вместо одной global DB transaction. Подробнее здесь — Коммуникация и интеграция.
Вопрос. Circuit breaker — паттерн простыми словами?
Ответ. При серии ошибок вызовов временно блокирует обращения к упавшему сервису, чтобы не уронить всю цепочку. Подробнее здесь — Коммуникация и интеграция.
Вопрос. Horizontal vs vertical scaling — разница?
Ответ. Vertical — больше CPU/RAM одной машине; horizontal — больше экземпляров за балансировщиком. MSA обычно horizontal. Подробнее здесь — Первые шаги к микросервисам.
Вопрос. Message broker — что это?
Ответ. Посредник доставки сообщений между producer и consumer (Rabbit, Kafka, Redis streams). Подробнее здесь — Брокеры сообщений.
Вопрос. WebSocket vs REST — когда WebSocket?
Ответ. REST — request/response; WebSocket — двусторонний канал для чата, live, игр. Подробнее здесь — Реактивная коммуникация, практикум.
Вопрос. Как разбить монолит на микросервисы?
Ответ. По bounded context, Strangler Fig — вертикальные срезы, не "по слоям". Подробнее здесь — 112 / миграция.
Вопрос. Idempotency key в API — зачем?
Ответ. Повтор запроса (retry) не дублирует операцию (два списания). Обязательно для POST платежей. Подробнее здесь — Реализация интеграции.
Вопрос. Distributed tracing — что это?
Ответ. Сквозной trace id через все сервисы; Jaeger, Zipkin, OpenTelemetry. Подробнее здесь — 19 DevOps.
Вопрос. CAP theorem — кратко для практика?
Ответ. В сбое сети выбирают между consistency и availability; PACELC расширяет на latency. Подробнее здесь — PACELC и компромиссы распределённых систем, NoSQL.
Вопрос. Load balancer — что делает?
Ответ. Распределяет запросы между несколькими экземплярами сервиса; health checks отсекают мёртвые. Подробнее здесь — Первые шаги к микросервисам, 2.03 / порты.
Вопрос. SOAP vs REST — что актуальнее?
Ответ. REST/JSON доминирует в новых API; SOAP/WSDL — legacy банки и ERP. Adapter-сервис между мирами. Подробнее здесь — Справочник по SOAP.
Вопрос. CQRS — что это?
Ответ. Разделение моделей запись (command) и чтение (query) для масштаба read-heavy. Подробнее здесь — Коммуникация и интеграция, design patterns.
Вопрос. Event sourcing — простыми словами?
Ответ. Состояние = цепочка событий, не только текущая строка в таблице; audit и replay. Подробнее здесь — Коммуникация и интеграция.
Что запомнить
Основные категории:
- Масштабирование может быть горизонтальным и вертикальным;
- Микросервисная архитектура является наиболее эффективным способом масштабирования за счёт разделения монолита на микросервисы;
- Коммуникация бывает синхронная (HTTP, REST, gRPC), асинхронная (Rabbit, Kafka) и реактивная (WebSocket);
- RabbitMQ использует модель очередей, а Kafka основана на топиках с партициями.
Три основных правила использования технологий масштабирования:
- Выбор метода масштабирования зависит от текущих потребностей системы и её потенциала роста.
- При проектировании микросервисной архитектуры важно обеспечить независимость сервисов и чёткость их взаимодействия через API.
- Брокеры сообщений должны соответствовать специфике задач - RabbitMQ для очередей, Kafka для потоковой обработки данных.
Три фундаментальных момента:
- Правильная декомпозиция монолитного приложения на микросервисы критична для эффективности всей системы.
- Надёжная коммуникация между сервисами требует тщательного выбора протоколов и подходов к интеграции.
- Масштабируемость должна быть заложена в архитектуру системы изначально.
Куда идти дальше
| Тема | Раздел |
|---|---|
| "Основы интеграционного взаимодействия — о разделе" | "Основы интеграционного взаимодействия — о разделе" |
| "Методы защиты пользовательских и корпоративных данных" | "Методы защиты пользовательских и корпоративных данных" |
| "Контейнеризация и оркестрация — о разделе" | "Контейнеризация и оркестрация — о разделе" |
| "Low-code и No-code платформы" | "Low-code и No-code платформы" |
| "SQL — о разделе" | "SQL — о разделе" |
Проверьте себя: Чек-лист самопроверки.
Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.