Как вы синхронизируете две взаимосвязанные, но отдельные системы?

Question

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

Второй аспект - это внутреннее приложение, которое сотрудники используют для управления теми же записями (концептуально) и предоставления обновлений состояния, одобрений и т. Д. Это приложение размещено в корпоративном брандмауэре с собственной локальной базой данных SQL Server.

Две сети соединены аппаратным VPN-решением, которое вполне приемлемо, но, очевидно, не самая быстрая вещь в мире.

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

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

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

До сих пор я думал об использовании следующих типов подходов:

1. Двунаправленная репликация
2. Веб-сервис взаимодействует с обеими сторонами с кодом для синхронизации изменений по мере их внесения (в режиме реального времени).
3. Веб-сервис взаимодействует с обеими сторонами с кодом для асинхронной синхронизации изменений (с использованием механизма очередей).

Есть совет? Кто-нибудь сталкивался с этой проблемой раньше? Вы нашли решение, которое хорошо сработало для вас?

Answer 1

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

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

Синхронные веб-сервисы не идеальны, потому что ваш код должен быть очень сложным для обработки сценариев сбоев. Что происходит, когда одна система перезагружается, а другая продолжает публиковать изменения? Получает ли система отправки таймауты? Что это с ними делать? Если вы не готовы потерять данные, вам нужно, чтобы какая-то транзакционная очередь (например, MSMQ) получала уведомления об изменениях и заботилась о том, чтобы они попадали в другую систему. Если какая-либо из систем не работает, изменения (переданные как сообщения) просто накапливаются, и, как только соединение может быть установлено, перезапускающий сервер обработает все сообщения, поставленные в очередь, и подтянется, что значительно облегчит достижение целостности системы.

Существуют некоторые инструменты с открытым исходным кодом, которые действительно могут упростить вам эту задачу, если вы используете .NET (особенно если вы хотите использовать MSMQ).

1. nServiceBus , Udi Dahan
2. Общественный транспорт Дрю Селлерс и Криса Паттерсона

Существуют также коммерческие продукты, и если вы рассматриваете коммерческий вариант, см. здесь для получения списка вариантов в .NET. Конечно, WCF может выполнять асинхронный обмен сообщениями с использованием привязок MSMQ, но такой инструмент, как nServiceBus или MassTransit, предоставит вам очень простой API Send / Receive или Pub / Sub, который сделает ваше требование очень простой задачей.

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

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

Answer 2

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

Во-первых, вам нужно отслеживать изменения, если вы можете использовать SQL 2008 (даже версии Express достаточно, если ограничение в 2 ГБ не является проблемой), это значительно облегчит задачу, просто включите отслеживание изменений в базе данных и каждый Таблица. Мы используем SQL Server 2008 в головном офисе с расширенной схемой и SQL Express 2008 на каждом сайте с подмножеством данных и ограниченной схемой.

Во-вторых, вам нужно отслеживать свои изменения, Sync Services отлично справляется с задачей и поддерживает использование шлюза WCF в основной базе данных. В этом примере вам нужно будет использовать Sync с использованием образца SQL Express Client в качестве отправной точки, обратите внимание, что он основан на SQL 2005, поэтому вам нужно будет обновить его, чтобы воспользоваться функциями отслеживания изменений в 2008. По умолчанию Sync Services использует SQL CE на клиентах, что, я уверен, недостаточно в вашем случае. Вам понадобится служба, работающая на вашем веб-сервере, которая периодически (может быть, каждые 10 секунд, если хотите) запускает метод Synchronize (). Это сообщит вашей основной базе данных об изменениях, сделанных локально, а затем запросит у сервера все изменения, сделанные там. Вы можете настроить SQL-код get и apply для вызова хранимых процедур, а также добавить обработчики событий для обработки конфликтов (например, обновление клиента или обновление сервера) и соответственно разрешать их на каждом конце.

Answer 3

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

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

Это сильно недоразвитая часть SQL Server, которую стоит посмотреть.

Answer 4

У нас есть магазин в качестве клиента с тремя магазинами, подключенными к одному VPN
В двух магазинах есть компьютер, работающий в качестве «сервера» для этого магазина, а в третьем - «основная база данных»
Чтобы синхронизировать все с мастером, у нас нет лучшего решения, но оно работает: есть специальный ПК, на котором выполняется приложение, которое проверяет временную метку каждой записи в каждой таблице из двух хранилищ и, если она отличается от прошлой, Вы синхронизируете, он копирует результаты
Обратите внимание, что это работает в обоих направлениях. То есть если вы обновите продукт в базе данных master, это изменение будет распространено на два других магазина. Если у вас есть новый заказ в одном из магазинов, он будет передан «мастеру».
С некоторыми оптимизациями вы можете синхронизировать все магазины за 20 минут

Answer 5

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