Рефакторинг от шаблона Shared Database

Question

На работе у нас есть несколько приложений с базами данных на централизованном сервере SQL. Всякий раз, когда одному приложению необходимо работать с данными из другого приложения, оно просто запрашивает их или обновляет через базу данных. Я считаю, что это шаблон «Общая база данных», описанный в книге «Шаблоны интеграции предприятия» (Hohpe & Woolf).

Эти взаимные зависимости баз данных вызывают у нас много-много головных болей. Крупнейшим из них сейчас является то, что мы сталкиваемся с проблемами производительности на сервере SQL и не можем масштабироваться из-за взаимозависимости между базами данных. Я думаю, что нам следует перейти от шаблона Shared Database к системе обмена сообщениями, как описано в книге EIP. Каждое приложение будет отвечать за все свои собственные данные, а другие приложения, которые хотят получить доступ к этим данным, будут получать их через службы (на шине обмена сообщениями?).

• С чего начать рефакторинг в направлении шаблона обмена сообщениями?
• Начнем ли мы с рефакторинга одного из приложений для управления собственной базой данных приложений?
• Тогда как насчет других приложений, которые в настоящее время интегрированы с этим через базу данных?
• Это лучший способ развязать зависимости от нашей базы данных или мы должны начать с чего-то еще?

Answer 1

Я бы предложил 3-х фазный переход.

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

Также, скажем, у вас есть 3 приложения; А, В и С.

Вы также можете просмотреть это как 3 отдельных перехода:

• Приложение A

  • Добавление сообщений к A
  • Изменить вызовы на A в B & C

• Приложение B

  • Добавить сообщения в B
  • Изменить вызовы на B в A & C

• Приложение C

  • Добавление сообщений в C
  • Изменить вызовы на C в A & B

В этот момент процесса результаты такие же, как в конце фазы 2, и фаза 3 может продолжаться. Разница лишь в том, будет ли продуктивнее сосредоточиться на типе рефакторинга или на приложении.

Answer 2

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

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

Другим важным отличием является разница между «в реальном времени» и «почти в реальном времени».

Предположим, что вашему различному приложению необходимо выполнять как транзакции (в режиме реального времени), так и некоторые отчеты по текущим / более старым данным; вам понадобятся два хранилища данных: транзакционное хранилище, созданное исключительно для оперативной скорости для поддержки операций приложений в режиме реального времени, и другое, содержащее «исторические» данные, которые будут созданы исключительно для отчетности.

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

Answer 3

Обмен сообщениями, безусловно, может быть одним из самых элегантных способов. Тем не менее, это также требует небольшой работы и будет меняться со временем при изменении каждой базы данных. Мы выбрали «более простой» подход, просто заставив каждое приложение знать, как войти в другую базу данных, а затем запросить каждую базу данных оттуда. Мы обнаружили, что большинство запросов к нескольким базам данных довольно легкие и поэтому не создают существенной базы кода во втором приложении. Существует некоторое дублирование запросов на выборку, но это было меньше работы, чем система обмена сообщениями.

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