Каков наилучший способ синхронизации данных между несвязанными системами?

Question

У меня есть, скажем, 2 (но в будущем их станет больше) полностью отделенные системы: система A и система B.

Допустим, каждый фрагмент информации в каждой системе имеет идентификатор информации. Ничто не мешает информации, чтобы она была одинаковой в разных системах. То, что однозначно идентифицирует часть информации во всех системах, - это пара Source-informationID.

Допустим, мне нужно экспортировать часть информации из системы A в систему B. Затем я хочу экспортировать ту же часть информации из системы B и повторно импортировать ее в систему A, и мне нужно иметь возможность распознать та же часть информации.

Какой лучший способ сделать это на опыте людей?

Вот что я думаю сделать:

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

Это не решит тот факт, что мне все еще нужно носить с собой originalSource + originalSourceID.

Любая помощь приветствуется.

Answer 1

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

1. OpenESB
2. Mule
3. Apache ServiceMix
4. Apache Camel

Мой фаворит - OpenESB, я знаю его лучше, у него полная IDE (Netbeans), дополнительная поддержка от крупного поставщика и огромное количество дополнительных компонентов . За его простоту и эффективность я люблю Apache Camel, но вы можете попробовать некоторые из них и решить, какой из них лучше для вас. Тогда вы даже можете купить услуги поддержки для всех из них.

Answer 2

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

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

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

Это одна из основных причин, по которой были созданы GUID.

-Adam

Answer 3

Эта проблема решается поставщиками EAI (Enterprise Application Integration), такими как Tibco и webMethods (теперь является частью Software AG). Я никогда не использовал Tibco раньше, но я использовал webMethods для решения подобных проблем, поэтому я сосредоточусь только на webmethods. Например, на предприятии данные о сотрудниках могут находиться как в Active Directory, так и в PeopleSoft. WebMethods может быть использован для обеспечения того, чтобы изменения, дополнения, удаления в одной системе (приложении) отражались в другой в режиме реального времени. В некоторых других организациях данные о сотрудниках также могут находиться в базе данных Oracle или SQL Server. Опять не проблема. Эти инструменты EAI, такие как webMethods, могут общаться с широким спектром серверных частей. webMethods не ограничивается одним источником и одной целью, но поскольку он имеет архитектуру публикации-подписки, данные из одного источника могут передаваться нескольким заинтересованным целям, которые подписываются на конкретную часть информации. Гарантированная доставка и другие функции могут быть найдены в этих продуктах. Возвращаясь к примеру сотрудника, в конечном счете, если все сделать правильно, в любой момент времени все системы и приложения на предприятии могут содержать одинаковую информацию о сотрудниках без каких-либо расхождений.

Таким образом, вместо программирования на C # или Java, вы будете заниматься программированием webMethods, которое очень похоже на язык 4GL. Я называю это программированием, потому что в нем все еще присутствует логика, цикл, если не иначе, ветвление, переменные, пакеты и т. Д., Но он очень ориентирован на процедуры, т.е. вообще не имеет понятия ООП.

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

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

Answer 4

Мы делаем в точности то же самое, что и A -> B -> То, что вы описываете. Изначально мы рассматривали попытку сделать так, чтобы все A, B, C и т. Д. Были равноправными, но это было слишком сложно, поэтому мы теперь определяем одного как хозяина, а другие как рабов. Все еще достаточно легко получить материал от одного раба к другому, но через мастера.

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

Таким образом, код идентичен в каждой системе. Только рабы называют домом.

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

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

Кстати, мы не улучшили уникальность Source / Id:)

Answer 5

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