Communication & API Style (Macro-Architecture)¶
Архитектура клиент-серверного взаимодействия веб приложений. Как deployment units общаются друг с другом и как фиксируется контракт.
| Группа | Стиль | Что это |
|---|---|---|
| Синхронные | REST API | Ресурсы и методы HTTP: статус-коды, HATEOAS, модель зрелости Ричардсона, контракт в OpenAPI |
| RPC | Вызов удалённой функции: действие, а не ресурс | |
| gRPC | Процедуры по контракту: HTTP/2, Protobuf, стриминг, кодогенерация. Типичный выбор для сервис <-> сервис | |
| GraphQL | Клиент сам формирует запрос: одна точка входа, нет over-fetching и under-fetching, проблемы N+1 и кэширования | |
| SOAP, WSDL и WS-* | XML-сообщения по контракту WSDL, стандарты WS-*. Легаси и enterprise-интеграции | |
| CORBA, DCE/RPC | Устаревшие и нишевые RPC | |
| Двусторонние и push | WebSocket | Постоянное двустороннее соединение: чаты, игры, биржи |
| SSE (Server-Sent Events) | Односторонний поток сервер -> клиент поверх обычного HTTP: ленты, уведомления, прогресс | |
| Long polling, HTTP polling | Сервер держит запрос открытым, пока не появятся данные: push без постоянного соединения | |
| Webhook | Сервер сам шлёт HTTP-запрос на заданный URL другого сервера: платежи, CI, интеграции | |
| WebTransport | Поверх HTTP/3 | |
| WebRTC Data Channels | Прямой канал между клиентами | |
| Асинхронные | Sync & async Messaging | Отправитель кладёт сообщение в брокер и не ждёт обработки |
| Event-Driven Architecture | Части общаются фактами о произошедшем, а не командами | |
| Инфраструктура связи | API Gateway | Вход в систему: маршрутизация, auth, rate limiting, TLS, сборка ответа |
| API Composition | Собирает ответ из нескольких сервисов в памяти: в gateway, BFF или отдельном сервисе | |
| BFF (Backend-for-Frontend) | Вход по одному на тип клиента, подгоняет ответ под свой UI | |
| Load Balancer | Распределяет запросы по инстансам одного сервиса, про API не знает | |
| Service Discovery | Отвечает, где сейчас живые инстансы сервиса | |
| Service Mesh | Прокси рядом с каждым сервисом: mTLS, retry, timeout, маршруты и метрики без кода в сервисе |
Оркестрация или хореография - центральный координатор или сервисы реагируют на события друг друга (см. Choreography и orchestration и SAGA).
| Брокер | Как работает | Для чего |
|---|---|---|
| Kafka | Распределённый лог событий: pub-sub, события хранятся и читаются повторно | Стриминг событий, передача состояния между системами, большой поток |
| RabbitMQ | Брокер очередей на AMQP: exchange, очереди, маршрутизация, push консьюмерам | Распределение задач, интеграция сервисов |
| IBM MQ | Enterprise-брокер очередей с гарантированной доставкой и XA-транзакциями | Банки, крупный легаси-энтерпрайз |
| Apache ActiveMQ (Classic, Artemis) | Java-брокер с JMS, понимает OpenWire, AMQP, MQTT, STOMP | Интеграции в Java-мире |
| Apache Pulsar | Лог и очереди в одном, хранение (BookKeeper) отделено от брокеров | Стриминг с мультиарендностью и гео-репликацией |
| Apache RocketMQ | Очереди и стриминг, транзакционные сообщения | E-commerce и финансы |
| NATS (JetStream) | Лёгкий pub-sub с низкой задержкой, JetStream добавляет хранение | Сигналы между сервисами, edge, IoT |
| Redis Streams, Redis Pub/Sub | Лог в Redis или pub-sub без хранения | Небольшой поток, когда Redis уже есть |
| Amazon SQS, SNS | Managed-очередь (SQS) и pub-sub рассылка (SNS) в AWS | Облако AWS без своих брокеров |
| Google Cloud Pub/Sub | Managed pub-sub в GCP | Облако Google |
| Azure Service Bus | Managed-брокер в Azure: очереди и топики | Облако Azure |
| ZeroMQ | Библиотека сообщений без брокера | Обмен напрямую между процессами |
| Протокол | Как работает | Для чего |
|---|---|---|
| AMQP | Протокол брокеров сообщений: exchange, очереди, маршрутизация | RabbitMQ, ActiveMQ, Azure Service Bus |
| MQTT | Лёгкий pub-sub через брокер | IoT, слабые устройства и сети |
| STOMP | Простой текстовый протокол поверх TCP или WebSocket | Сообщения из браузера и скриптов |
| JMS | Java API для брокеров, а не сетевой протокол | Java-приложения |
| CoAP | REST-подобный протокол поверх UDP | Ограниченные устройства IoT |
| XMPP | XML-сообщения и статусы присутствия | Мессенджеры |
Критерии выбора¶
- Синхронно / асинхронно - ждёт ли вызывающий ответа: HTTP-запрос или сообщение в очередь (см. Sync и async)
- Паттерн обмена - request-response, fire-and-forget, publish-subscribe, streaming (server, client, bidirectional)
- Кардинальность - один к одному (point-to-point) или один ко многим (broadcast, topic)
- Модель API - ресурсная (REST), процедурная (RPC), запросная (GraphQL), событийная (events)
- Связанность - по времени (оба должны быть онлайн), по формату (общая схема), по расположению (знание адреса)
Контракты и их жизненный цикл¶
- описание - OpenAPI, Protobuf и другие IDL, GraphQL SDL, AsyncAPI для событий, WSDL
- подход - contract-first или code-first
- версионирование - в URI, в заголовках, через эволюцию схемы без версий. Политика deprecation
- contract testing - consumer-driven contracts (Pact)