Интеграция систем посредством шины данных

Ранее я писал о том, как мы интегрировали системы через шину данных. Этот пост продолжает тему интеграции систем через шину данных.

Дано: несколько систем и шина данных, реализующая обмен сообщениями через отдельные каналы (топики) по принципу publish - subscribe.

Цель: интегрировать системы посредством сообщений об изменениях, передаваемых и получаемых в/из шины данных.

(Представим, что у нас есть Apacahe Kafka в качестве шины данных и соглашение о передаче сообщений в формате Avro.)

Сформулируем дополнительные требования к интеграции, чтобы решение получилось эффективным и расширяемым.

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

Например, пусть система A является источником данных о компаниях, а системы Б и В получают данные о компаниях, но с разным набором атрибутов. Тогда система А, вместо того, чтобы формировать по отдельности сообщения для систем Б и В, должна формировать сообщения с набором атрибутов компаний, включающим атрибуты для систем Б и В, как вариант - со всеми имеющимися атрибутами.

Данное требование предполагает, что организация-владелец систем и шины данных обладает необходимыми компетенциями (или подрядчиками) для реализации исходящих потоков из системы-источника.

Во-вторых, нужно исключить неоправданное связывание (cohesion) систем друг с другом из-за передачи/учета деталей, специфичных для реализации конкретных систем.

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

В-третьих, желательно обеспечить минимальную "толщину" (сложность) интеграции каждой из систем с шиной данных.

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

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

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

Данные загружаемых в БД сообщений помещаются в 3NF схему данных, так реализуется хранилище оперативных данных (ODS). Таким образом, функции данной БД не ограничиваются поддержкой агентов-посредников на шине данных, а включают также оперативную аналитику.

Итак, проектируя интеграцию систем посредством шины данных будем стремиться

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

В свете этих требований рассмотрим три похода к интеграции систем, которые условно назовем "модельный", "специальный" и "наивный".

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

1. исключаем дублирование,
2. устраняем неоправданное связывание и
3. должны для каждой системы реализовать толстые (в общем случае) исходящие и входящие интерфейсы с шиной данных.

Специальный подход учитывает, что у систем имеются готовые решения для интеграции – собственные интеграционные API, предлагающие набор сообщений с готовыми структурами и атрибутами. Тогда системы передают в шину данных исходящие сообщения и получают из шины данных входящие сообщения, соответствующие их интеграционным API. При таком подходе мы

1. исключаем дублирование, если готовые API его исключают,
2. должны, для исключения связывания, для каждой системы реализовать агента-посредника, и
3. получаем тонкие исходящие и входящие интерфейсы систем с шиной данных.

По сути, в этом случае толщина интеграционого решения каждой системы распределяется между тонким интерфейсом система - шина данных и агентом-посредником системы.

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

1. исключаем дублирование, если готовые API его исключают,
2. создаем связывание и взаимную зависисмость систем на уровне их API, и
3. получаем тонкие исходящие и толстые (в общем случае) входящие интерфейсы систем с шиной данных.

К сожалению, это распространенная практика из-за соблазна решить вопрос быстро, не принимая во внимание ничего, кроме непосредственного результата: системы интегрированы и работают. Наивный подход игнорирует вопрос о том, станут ли порожденные зависимости проблемой в будущем.

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

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

1. реализации интерфейса новой системы с шиной данных,
2. разработки агента новой системы,
3. вероятно, доработки интерфейсов других систем с шиной данных и их агентов, если в обмене с новой системой задействованы новые данные.

Преимущества модельного подхода менее очевидны. Есть ли место для него при интеграции систем?

Есть, если интеграционный интерфейс систем делается с нуля или является достаточно гибким и адаптивным. В этом случае исключительно полезно при проектировании набора и структур сообщений опираться на единую модель данных предметной области. Новые интегрируемые системы, интерфейс которых делается с нуля или достаточно гибок, могут использовать уже готовые модельные потоки сообщений в качестве входящих как они есть, не нуждаясь в посредничестве агентов. А при замене системы-источника модельных сообщений на другую систему, которая реиспользует ту же модель, ни одна из других систем на шине данных не заметит замены.

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

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

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

Первые кандидаты на реализацию обмена данными в рамках модельного подхода - мастер-данные, или справочники и ресурсы. Далее имеет смысл распространить его и на другие виды данных.

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