Какой протокол используется для внутренней интеграции?

Протоколы для внутренней интеграции

Внутренняя интеграция (internal integration) — это обмен данными и коммуникация между компонентами, сервисами и системами внутри организации. Рассмотрю основные протоколы и подходы, используемые в различных архитектурах.

1. REST (Representational State Transfer)

Описание: Основано на HTTP протоколе, использует стандартные методы (GET, POST, PUT, DELETE) и JSON для передачи данных.

Когда используется:

• Синхронная коммуникация между микросервисами
• Интеграция legacy систем с новыми
• API-first архитектуры
• Cloud-native приложения

Плюсы:

• Простота реализации и отладки
• Стандартизированный подход
• Легко масштабируется
• Работает поверх HTTP (есть везде)
• Developer-friendly

Минусы:

• Синхронный запрос-ответ может быть медленным
• Нет встроенного механизма retry
• Overhead HTTP headers

Пример:

GET /api/v1/users/123
POST /api/v1/orders
Content-Type: application/json

{"user_id": 123, "items": [...]}

2. Message Queue / Event Bus

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

Технологии:

• RabbitMQ
• Apache Kafka
• AWS SQS / SNS
• Redis (Pub/Sub)

Когда используется:

• Асинхронные операции (отправка email, логирование)
• High-volume обработка данных
• Decoupling сервисов (один сервис не зависит от времени ответа другого)
• Event-driven архитектуры

Плюсы:

• Асинхронность: не блокирует вызывающий сервис
• Масштабируемость: несколько consumers могут обрабатывать один queue
• Отказоустойчивость: сообщение хранится до обработки
• Decoupling: сервисы не знают друг о друге

Минусы:

• Сложность отладки
• Eventual consistency (данные синхронизируются не сразу)
• Нужна дополнительная infrastructure

Пример (RabbitMQ):

Producer отправляет: {"order_id": 123, "status": "created"}
  ↓ (в очередь orders.created)
Consumer слушает и обрабатывает
  → отправляет email
  → обновляет analytics
  → уведомляет warehouse

3. gRPC (gRPC Remote Procedure Call)

Описание: Высокопроизводительный RPC фреймворк от Google. Использует HTTP/2 и Protocol Buffers (protobuf).

Когда используется:

• Высокочастотная коммуникация между сервисами
• Микросервисная архитектура
• Когда нужна высокая производительность
• Streaming data

Плюсы:

• Очень быстро (HTTP/2, binary protocol)
• Типизированные контракты (protobuf)
• Bi-directional streaming
• Lightweight
• Автоматическое генерирование клиент-код

Минусы:

• Меньше tooling чем REST
• Не browser-friendly (нет стандартного браузера support)
• Кривая обучения (protobuf)
• Firewall issues (не стандартный 80/443 порт)

Пример:

service UserService {
  rpc GetUser(UserId) returns (User);
  rpc ListUsers(Empty) returns (stream User);
}

4. GraphQL

Описание: Query язык для API. Клиент запрашивает ровно те данные, которые ему нужны.

Когда используется:

• Когда нужна гибкость в запросах данных
• Mobile-first приложения (меньше bandwidth)
• Зависимые entities (один запрос вместо N запросов)
• API Gateway для множества backend сервисов

Плюсы:

• Ровно те данные, которые запросил
• Меньше over-fetching и under-fetching
• Сильная типизация
• Introspection (self-documenting API)

Минусы:

• Сложнее реализовать than REST
• Caching сложнее
• N+1 queries проблема без optimization

Пример:

query {
  user(id: 123) {
    name
    email
    orders {
      id
      total
    }
  }
}

5. SOAP (Simple Object Access Protocol) и XML-RPC

Описание: Легаси протокол для RPC, использует XML для сообщений.

Когда используется:

• Legacy системы (банки, enterprise)
• Когда требуется WS-Security
• WSDL контракты

Плюсы:

• Надежность (исторически проверено)
• Enterprise support
• Транспортно-агностичный

Минусы:

• Громоздкий (много XML)
• Медленный
• Считается устаревшим

Пример:

<?xml version="1.0"?>
<soap:Envelope>
  <soap:Body>
    <GetUser>
      <id>123</id>
    </GetUser>
  </soap:Body>
</soap:Envelope>

6. Webhook

Описание: HTTP callback: система A отправляет POST запрос на URL системы B, когда происходит событие.

Когда используется:

• Event notifications
• Интеграция с external systems
• Когда система B должна узнать об событии из системы A

Плюсы:

• Простой и universal
• Асинхронный
• Стандартный (HTTP POST)

Минусы:

• Нужна retry логика на обеих сторонах
• Сложная отладка (асинхронный)
• Нужна security (verify signature)

Пример:

Получатель платежа отправляет:
POST https://myapp.com/webhooks/payment
{
  "event": "payment.success",
  "payment_id": 456,
  "amount": 100
}

7. Database Replication

Описание: Данные дублируются между базами данных (master-slave, multi-master).

Когда используется:

• High availability
• Disaster recovery
• Read scaling
• Geographic distribution

Плюсы:

• Очень надежно (data level)
• Прозрачно для приложений
• Синхронизация в реальном времени

Минусы:

• Требует shared database infrastructure
• Сложность consistency
• Не подходит для разных schema

8. File-based Integration

Описание: Обмен данными через файлы (CSV, XML, JSON, Binary).

Когда используется:

• Legacy системы без API
• Batch processing
• Offline scenarios
• Big data transfers

Плюсы:

• Простой (нет нужно сложный protocol)
• Работает везде
• Подходит для больших объемов

Минусы:

• Не real-time
• Нужна file management
• Сложность синхронизации

9. AMQP (Advanced Message Queuing Protocol)

Описание: Открытый стандарт для message queue, более мощный чем JMS.

Когда используется:

• Enterprise messaging
• Guaranteed delivery
• Complex routing

Плюсы:

• Стандартизированный
• Надежность
• Flexible routing

Минусы:

• Более complex чем простой RabbitMQ

Сравнительная таблица

Рекомендация для современных систем

Синхронная коммуникация:

• API между микросервисами: REST или gRPC
• Complex queries: GraphQL
• Legacy: SOAP или REST с XML

Асинхронная коммуникация:

• Event streaming: Kafka
• Task queues: RabbitMQ, Redis
• Notifications: Webhooks, SNS

Hybrid подход (рекомендуется):

• REST для стандартных операций
• Message queue для async events
• gRPC для inter-microservice high-performance calls
• Database sync для critical data (HA)

Как BA я рекомендую выбирать протокол на основе:

1. Синхронность (нужен ответ сразу?)
2. Производительность requirements
3. Reliability requirements
4. Complexity of operations
5. Existing infrastructure