База данных — хорошая точка развязки системы?

Question

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

В настоящее время в системе B есть процесс, который опрашивает данные в таблице БД и обрабатывает любые новые вставленные строки.

Один из предложенных вариантов заключается в том, что система A просто вставляет данные в таблицу базы данных системы B, а система B обрабатывает новые строки существующим процессом.Вопрос в том, отвечает ли это решение требованию разделения двух систем?Считается ли база данных частью системы Б, которая может стать недоступной и привести к взрыву системы А?

Другое решение состоит в том, чтобы система A поместила данные в очередь MQ и создала процесс, который будет читать из MQ, а затем вставлять их в базу данных системы B.Но является ли это просто дополнительными накладными расходами?В конечном итоге, является ли очередь MQ более отказоустойчивой, чем таблица БД?

Answer 1

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

Существует четыре общих уровня интеграции:

1. Совместное использование базы данных
2. Обмен файлами
3. Удаленный вызов процедур
4. Передача сообщений

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

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

Answer 2

Используйте очереди для общения.Не «передавайте» данные из системы A в систему B через базу данных.Вы используете базу данных как гигантскую, дорогую и сложную очередь сообщений.

Используйте очередь сообщений в качестве очереди сообщений.

Это не «дополнительные» накладные расходы.Это лучший способ разъединить системы.Это называется сервис-ориентированной архитектурой (SOA), и использование сообщений занимает центральное место в проекте.

Очередь MQ намного проще, чем таблица БД.

Не сравнивайте «отказоустойчивость», потому что СУБД использует огромные (почти невообразимые) накладные расходы для достижения разумного уровня уверенности в том, что ваша транзакция завершится правильно.Блокировка.Буферизация.Пишите очереди.Управление хранилищем.И т. д.И т. д.

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

Answer 3

В SQL Server Я хотел бы сделать это с помощью пакета служб SSIS или работы (в зависимости от количества записей и сложностей того, что я двигался). Другие базы данных также ETL решений. Мне нравится ETL решение я еще потому могу держать журналы, что изменилось, и какие ошибки были обработаны, я могу отправить записи, которые по какой-то причине не пойдет к другой системе (структуры данных редко совпадают между двумя базами данных) для проведения стол, не убивая остальную часть процесса. Я могу также внести изменения в данные, как она течет для корректировки различий в базах данных (такие вещи, как значения таблицы преобразования, скажем, завершенный статус в DB1 составляет 5 и 7 в db2 или сказать db2 имеет обязательное поле, DB1 не делает, и вы должны добавить значение по умолчанию, поданной, если она равна нулю). Если один или другой servver вниз задание запуска пакета служб SSIS не удастся, и ни одна система не будет затронута, поэтому он сохраняет datbases отсоединенное, как с помощью триггеров или репликации не будет.