❓Как выбрать тип межсистемной интеграции
В предыдущем посте мы рассмотрели 4 типа интеграции систем. Настало время подумать над тем, какой способ лучше и в каких случаях. Вопросы выбора конкретного способа реализации, например, REST vs SOAP, будет рассмотрен в других постах.
Попробуем выделить ряд критериев, которые помогут определиться. Нет такого решения, которое было бы универсальным в любой ситуации. Однако стоит учитывать, что вес того или иного критерия определяется текущими условиями и решаемыми задачами.
1️⃣ Периодичность межсистемного взаимодействия. Как часто системы должны взаимодействовать? Отчего это зависит? Периодичность может быть следующей:
• По расписанию: система Б получает сведения из системы А раз в определенный период времени (минута, час, сутки и пр.).
• По событию: передача данных и удаленные вызовы функций выполняются при наступлении какого-то события в одной из систем или внешнем мире.
• По запросу: по явному запросу пользователя или другой системы.
2️⃣ Допустимая задержка обработки данных. Это время, которое проходит с момента появления данных в источнике до их получения приемником. Если данные нужно обрабатывать в реальном времени или с минимальной задержкой, то подходят технологии потоковой передачи, такие как gRPC
3️⃣ Степень связанности и зависимости систем. Чем сильнее системы связаны и зависят друг от друга, тем выше требования к согласованности и актуальности данных.
4️⃣ Степень изменчивости и динамичности систем. Чем чаще и сильнее системы меняются и развиваются, тем выше требования к гибкости и масштабируемости интеграции. Мы не можем использовать в таком случае единую БД, так как невозможно менять схему данных настолько часто, насколько это необходимо.
6️⃣ Масштабируемость. Это способность системы к росту путем увеличения количества вычислительных узлов (серверов). Масштабируемость зависит от балансировки нагрузки и пропускной способности технологии. Например, Kafka может обеспечить высокую пропускную способность и автоматическую балансировку нагрузки при передаче большого количества сообщений. Также важно учитывать количество источников и приемников данных, которые должны быть подключены к системе интеграции.
7️⃣ Возможность всех участвующих систем использовать выбранный тип интеграции. Не секрет, что разные приложения могут быть реализованы в разных архитектурных стилях и парадигмах разработки. Если мы выбираем способ файловой интеграции, то мы должны быть уверены, что интегрируемые системы умеют работать с предоставляемыми форматами.
Итого
📌 Файловая интеграция подходит для передачи небольших объемов простых данных между слабосвязанными и малоизменяемыми системами. Это самый простой и дешевый способ интеграции, но он имеет низкую производительность, ненадежность и неактуальность данных
📌 Общая база данных подходит для передачи больших объемов сложных данных между сильносвязанными и зависимыми системами. Это самый быстрый и согласованный способ интеграции, но он имеет высокую стоимость, жесткость и риск потери данных
📌 Удаленный вызов процедур подходит для передачи средних объемов сложных данных между сильносвязанными и зависимыми системами. Это более гибкий и надежный способ интеграции, чем общая база данных, но он имеет низкую масштабируемость, высокую сложность и риск ошибок
📌 Обмен сообщениями подходит для передачи любых объемов и сложности данных между слабосвязанными и динамичными системами. Это самый гибкий и масштабируемый способ интеграции, но имеет сложности с согласованностью данных, высокую задержку и риск потери сообщений при неправильной реализации
💬 Пишите в комментариях, как вы определяете, какой тип интеграции нужно использовать👇
📎 Материалы по теме
1. Шаблоны интеграции корпоративных приложений — книга Хопа и Вульфа
2. 7 главных требований к интеграции ИС, чтобы определить решение — BABOK School
3. Типы системной интеграции
4. Базовое проектирование и разработка требований к интеграции систем (для начинающих аналитиков)
5. Интеграции IT систем и при чем тут бар?
#интеграции
В предыдущем посте мы рассмотрели 4 типа интеграции систем. Настало время подумать над тем, какой способ лучше и в каких случаях. Вопросы выбора конкретного способа реализации, например, REST vs SOAP, будет рассмотрен в других постах.
Попробуем выделить ряд критериев, которые помогут определиться. Нет такого решения, которое было бы универсальным в любой ситуации. Однако стоит учитывать, что вес того или иного критерия определяется текущими условиями и решаемыми задачами.
1️⃣ Периодичность межсистемного взаимодействия. Как часто системы должны взаимодействовать? Отчего это зависит? Периодичность может быть следующей:
• По расписанию: система Б получает сведения из системы А раз в определенный период времени (минута, час, сутки и пр.).
• По событию: передача данных и удаленные вызовы функций выполняются при наступлении какого-то события в одной из систем или внешнем мире.
• По запросу: по явному запросу пользователя или другой системы.
2️⃣ Допустимая задержка обработки данных. Это время, которое проходит с момента появления данных в источнике до их получения приемником. Если данные нужно обрабатывать в реальном времени или с минимальной задержкой, то подходят технологии потоковой передачи, такие как gRPC
3️⃣ Степень связанности и зависимости систем. Чем сильнее системы связаны и зависят друг от друга, тем выше требования к согласованности и актуальности данных.
4️⃣ Степень изменчивости и динамичности систем. Чем чаще и сильнее системы меняются и развиваются, тем выше требования к гибкости и масштабируемости интеграции. Мы не можем использовать в таком случае единую БД, так как невозможно менять схему данных настолько часто, насколько это необходимо.
6️⃣ Масштабируемость. Это способность системы к росту путем увеличения количества вычислительных узлов (серверов). Масштабируемость зависит от балансировки нагрузки и пропускной способности технологии. Например, Kafka может обеспечить высокую пропускную способность и автоматическую балансировку нагрузки при передаче большого количества сообщений. Также важно учитывать количество источников и приемников данных, которые должны быть подключены к системе интеграции.
7️⃣ Возможность всех участвующих систем использовать выбранный тип интеграции. Не секрет, что разные приложения могут быть реализованы в разных архитектурных стилях и парадигмах разработки. Если мы выбираем способ файловой интеграции, то мы должны быть уверены, что интегрируемые системы умеют работать с предоставляемыми форматами.
Итого
📌 Файловая интеграция подходит для передачи небольших объемов простых данных между слабосвязанными и малоизменяемыми системами. Это самый простой и дешевый способ интеграции, но он имеет низкую производительность, ненадежность и неактуальность данных
📌 Общая база данных подходит для передачи больших объемов сложных данных между сильносвязанными и зависимыми системами. Это самый быстрый и согласованный способ интеграции, но он имеет высокую стоимость, жесткость и риск потери данных
📌 Удаленный вызов процедур подходит для передачи средних объемов сложных данных между сильносвязанными и зависимыми системами. Это более гибкий и надежный способ интеграции, чем общая база данных, но он имеет низкую масштабируемость, высокую сложность и риск ошибок
📌 Обмен сообщениями подходит для передачи любых объемов и сложности данных между слабосвязанными и динамичными системами. Это самый гибкий и масштабируемый способ интеграции, но имеет сложности с согласованностью данных, высокую задержку и риск потери сообщений при неправильной реализации
💬 Пишите в комментариях, как вы определяете, какой тип интеграции нужно использовать👇
📎 Материалы по теме
1. Шаблоны интеграции корпоративных приложений — книга Хопа и Вульфа
2. 7 главных требований к интеграции ИС, чтобы определить решение — BABOK School
3. Типы системной интеграции
4. Базовое проектирование и разработка требований к интеграции систем (для начинающих аналитиков)
5. Интеграции IT систем и при чем тут бар?
#интеграции