Перейти к основному содержимому

2.09. Виды взаимодействия

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Всем

Виды взаимодействия​

Выбор модели взаимодействия определяет архитектурные свойства системы: отзывчивость, устойчивость к сбоям, сложность отладки и масштабируемость.

Синхронное взаимодействие предполагает, что инициатор запроса ждёт ответа до продолжения своей работы. Классический пример — HTTP-запрос к REST API. Пока ответ не получен, вызывающая система блокирована (или работает в режиме ожидания). Преимущества: простота логики, предсказуемость последовательности операций. Недостатки: блокировка ресурсов, зависимость от времени отклика удалённой системы, низкая устойчивость к сбоям.

Асинхронное взаимодействие разрывает прямую связь во времени между отправкой сообщения и его обработкой. Инициатор не ждёт ответа и продолжает работу. Сообщение помещается в промежуточную очередь (например, RabbitMQ, Kafka, AWS SQS), из которой его забирает получатель, когда будет готов. Преимущества: декуплинг компонентов, устойчивость к кратковременным сбоям, масштабируемость. Недостатки: усложнение логики обработки ошибок, необходимость отслеживания состояния, потенциальная несогласованность данных.

Реактивное взаимодействие — это эволюция асинхронной модели, основанная на принципах реактивного программирования (Reactive Manifesto). Здесь системы посылают сообщения, обмениваются потоками событий, реагируют на изменения состояния, применяют backpressure для управления нагрузкой. Примеры: WebSocket-каналы, стриминг через gRPC, реактивные фреймворки (Project Reactor, RxJava). Реактивность позволяет строить высоконагруженные, отзывчивые системы, но требует переосмысления традиционных подходов к обработке данных и ошибок.

Эти модели не являются взаимоисключающими. В одной системе могут сосуществовать синхронные вызовы для пользовательского интерфейса, асинхронные события для внутренней обработки и реактивные потоки для аналитики.

Концепция автономности систем и трансформация данных​

Фундаментальный принцип распределённых систем заключается в том, что каждая из них существует и функционирует автономно. Это означает, что:

  • система обладает собственной логикой обработки данных;
  • управляет собственным состоянием (часто — через локальную или выделенную базу данных);
  • имеет независимый жизненный цикл разработки, развертывания и масштабирования;
  • не зависит от внутреннего устройства других систем.

Автономность — условие устойчивости и гибкости архитектуры. Однако она порождает новую проблему: данные, необходимые для выполнения сквозного бизнес-процесса, физически и логически распределены. Чтобы координировать действия, системы должны обмениваться информацией, но эта информация редко бывает совместимой «из коробки».

Здесь возникает необходимость трансформации данных — преобразования структуры, семантики и формата информации из представления, понятного отправителю, в представление, пригодное для получателя.

Трансформация может происходить на нескольких уровнях:

  1. Синтаксическая трансформация: изменение формата данных без изменения смысла. Например, преобразование XML в JSON, или сериализация объекта в Protocol Buffers. Такие преобразования часто выполняются шлюзами (API Gateway), адаптерами (в паттерне Enterprise Integration Patterns) или ETL-процессами.

  2. Семантическая трансформация: приведение значений к общему смысловому контексту. Пример: система А передаёт статус заказа как “shipped”, а система Б понимает только “dispatched”. Здесь требуется маппинг значений, возможно — с использованием справочников или онтологий.

  3. Агрегационная трансформация: сборка данных из нескольких источников в единое сообщение. Например, для формирования единого карточки клиента может потребоваться информация из CRM, биллинг-системы и службы поддержки. Такая трансформация часто реализуется в оркестраторах (BPM-движки, Saga-оркестрация) или через композитные API.

  4. Проекционная трансформация: отбор только тех полей или сущностей, которые необходимы получателю. Это снижает объём передаваемых данных и повышает безопасность (принцип минимальных привилегий).

Трансформация — неотъемлемая часть интеграционного слоя. Она может быть реализована программно (в коде микросервиса), декларативно (через правила в интеграционной платформе, например, Apache Camel), или с помощью специализированных сервисов (Data Transformation Service в облаке).