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

Question

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

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

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

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

Answer 1

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

Есть четыре общих уровней интеграции:

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

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

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

Answer 2

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

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

Это не «лишние» накладные расходы. Это лучший способ развязать системы. Он называется Service Oriented Architecture (SOA), и использование сообщений абсолютно важно для дизайна.

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

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

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

Answer 3

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