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

Типы интеграции систем. Преимущества и недостатки

Выделяют 4 основных типа интеграции:

  1. Файловая интеграция
  2. Общая база данных
  3. Удалённый вызов процедур
  4. Обмен сообщениями

1️⃣ Файловая интеграция​

Система А передает файл системе Б в определенном формате (например, CSV или XML). Файл с данными размещается в хранилище (например, файловом сервере), откуда другие системы могут его считать.

Преимущества​

  • Универсальность. Файлы поддерживаются любой операционной системой и языком программирования.
  • Простота. Просто закинули данные в файлик и готово.

Недостатки​

  • Скорость. Обмен данными через файлы может быть медленным и приводить к рассинхронизации данных.
  • Ненадежность. Нет гарантии, что файл дойдет до целевой системы и будет корректно обработан.

2️⃣ Общая база данных​

Система А размещает свои данные в общей БД, из которой система Б может спокойно читать.

Преимущества​

  • Высокая скорость. Нет нагрузки на сеть. Данные доступны для чтения сразу после их записи в общую БД.
  • Единый формат данных и их целостность.

Недостатки​

  • Высокая связанность. Любое изменение в схеме общей базы данных требует согласования всех интегрируемых приложений.
  • Сложность проектирования. БД общая, схема БД общая. Нужно учесть особенности всех систем, а это очень трудоёмко и долго.
  • Точка отказа. Если БД выйдет из строя, то конец всему.

3️⃣ Удалённый вызов процедур (API)​

Система А удаленно вызывает метод системы Б, передавая туда нужные параметры. Самые популярные способы реализовать этот подход: REST, SOAP, GraphQL и gRPC и т.д.

Преимущества​

  • Гибкость. Разработка и развертывание сервисов может быть выполнена независимо и быстро, без влияния на другие сервисы.
  • Инкапсуляция. Данные и логика их обработки скрыты внутри удаленной процедуры, что повышает безопасность и целостность данных.
  • Масштабируемость. Каждый сервис может быть масштабирован по отдельности в зависимости от нагрузки и потребностей.

Недостатки​

  • Контракты. Вызывающая система должна знать контракт вызываемой системы, а также её доступность и адрес. Любое изменение в API может потребовать изменения в вызывающей системе.
  • Сложность интеграции и эксплуатации. Распределение логики и данных по нескольким сервисам может затруднить координацию и мониторинг интеграционного решения.
  • Производительность. Вызов удаленной процедуры может быть менее эффективным, чем локальный вызов, из-за сетевых затрат и преобразования форматов данных.

4️⃣ Обмен сообщениями​

Асинхронный способ взаимодействия, при котором система А формирует сообщение и кладёт его в очередь. Система Б читает это сообщение и выполняет определённую логику. К этому способу относятся брокеры очередей сообщений (например, Kafka или RabbitMQ) и шины данных (ESB).

Преимущества​

  • Слабая связанность. Компоненты не нуждаются в знании друг о друге, они общаются только через брокер сообщений. Это повышает гибкость и масштабируемость.
  • Гарантированная доставка данных. Брокер сообщений может хранить и пересылать сообщения до тех пор, пока они не будут доставлены получателю. Это повышает надежность интеграционного решения.
  • Масштабируемость. Сравнительно легко: просто добавляем больше ёмкости в наш брокер.
  • Асинхронность. Система А не должна ждать ответа от системы Б и может продолжать работу. Не требуется одновременной доступности обоих систем.

Недостатки​

  • Сложность интеграции и эксплуатации. Разработка и поддержка интеграционного решения требует знания и управления брокером сообщений, его коннекторами, форматами и правилами обмена сообщениями.
  • Производительность. Обмен сообщениями может быть менее эффективным, чем прямой вызов, из-за сетевых затрат и дополнительной обработки сообщений брокером.
  • Трудности согласования данных. Обмен сообщениями может приводить к рассинхронизации данных между системами из-за асинхронности.

Как выбрать тип межсистемной интеграции. Основные критерии​

1. Периодичность межсистемного взаимодействия​

Как часто системы должны взаимодействовать? Отчего это зависит? Периодичность может быть следующей:

  • По расписанию: система Б получает сведения из системы А раз в определенный период времени (минута, час, сутки и пр.).
  • По событию: передача данных и удаленные вызовы функций выполняются при наступлении какого-то события в одной из систем или внешнем мире.
  • По запросу: по явному запросу пользователя или другой системы.

2. Допустимая задержка обработки данных​

Это время, которое проходит с момента появления данных в источнике до их получения приемником. Если данные нужно обрабатывать в реальном времени или с минимальной задержкой, то подходят технологии потоковой передачи, такие как gRPC.

3. Степень связанности и зависимости систем​

Чем сильнее системы связаны и зависят друг от друга, тем выше требования к согласованности и актуальности данных.

4. Степень изменчивости и динамичности систем​

Чем чаще и сильнее системы меняются и развиваются, тем выше требования к гибкости и масштабируемости интеграции. Мы не можем использовать в таком случае единую БД, так как невозможно менять схему данных настолько часто, насколько это необходимо.

5. Масштабируемость​

Это способность системы к росту путем увеличения количества вычислительных узлов (серверов). Масштабируемость зависит от балансировки нагрузки и пропускной способности технологии. Например, Kafka может обеспечить высокую пропускную способность и автоматическую балансировку нагрузки при передаче большого количества сообщений. Также важно учитывать количество источников и приемников данных, которые должны быть подключены к системе интеграции.

6. Возможность всех участвующих систем использовать выбранный тип интеграции​

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

Итого​

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

  • Общая база данных подходит для передачи больших объемов сложных данных между сильносвязанными и зависимыми системами. Это самый быстрый и согласованный способ интеграции, но он имеет высокую стоимость, жесткость и риск потери данных.

  • Удаленный вызов процедур подходит для передачи средних объемов сложных данных между сильносвязанными и зависимыми системами. Это более гибкий и надежный способ интеграции, чем общая база данных, но он имеет низкую масштабируемость, высокую сложность и риск ошибок.

  • Обмен сообщениями подходит для передачи любых объемов и сложности данных между слабосвязанными и динамичными системами. Это самый гибкий и масштабируемый способ интеграции, но имеет сложности с согласованностью данных, высокую задержку и риск потери сообщений при неправильной реализации.

Подборка материалов по теме​

  1. Шаблоны интеграции корпоративных приложений — книга Хопа и Вульфа
  2. 7 главных требований к интеграции ИС, чтобы определить решение — BABOK School
  3. Типы системной интеграции
  4. Базовое проектирование и разработка требований к интеграции систем (для начинающих аналитиков)
  5. Интеграции IT систем и при чем тут бар?
  6. Шаблоны интеграции корпоративных приложений — книга Хопа и Вульфа
  7. Интеграции IT систем и при чем тут бар? — статья на Хабре

Подборка бесплатных вебинаров по основам интеграции систем​

  1. Как описывать требования к интеграции информационных систем? Ольга Пономарева
  2. Введение в интеграции информационных систем · Татьяна Сальникова
  3. Наталья Косинова. Мастер-класс: Интеграция информационных систем
  4. Проектирование интеграционного взаимодействия между системами
  5. Что такое хорошая интеграция / Максим Цепков
  6. Межсервисные интеграции. Что может пойти не так? — Руслан Артамонов, Тинькофф
  7. Геннадий Круглов. Доменно-ориентированный подход к интеграции
  8. Обзор паттернов интеграции микросервисов
  9. Плейлист по интеграции от Systems Education (20 видео)