Несколько приложений для единой архитектуры базы данных

В настоящее время мы создаем новую стратегию для наших внутренних приложений. В настоящее время у нас около 10-15 приложений, которые напрямую связаны с той же базой данных. Это, очевидно, не очень хорошо, и мы хотим оценить наши варианты. Насколько я вижу, у нас есть выбор:

  • Дублируйте базу данных и используйте репликацию и т.д., чтобы синхронизировать их.
  • Создайте новое приложение между базой данных и приложениями 10-15 сверху.
  • Другое?

Я очень хотел бы услышать ваши опьянения по этому поводу. Я верю, что второй вариант - это путь, который также дает нам эффективный уровень для реализации кэширования. Но как бы вы раскрыли этот слой для всех приложений? Будет ли webservices/rest быть способ пойти или есть другие, лучшие способы сделать это?

4 ответа

Я думаю, что ответ на модное слово - "Ориентированная на обслуживание архитектура" - это действительно вариант 2.

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

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

Другое - хорошо, вы на самом деле не говорите, какова конкретная проблема, которую вы пытаетесь решить. Если его производительность - самый дешевый способ решения проблем с производительностью, это бросать аппаратные средства в проблему. Если это управляемость - SOA может помочь в этом, но она часто также вводит дополнительную инфраструктуру в состав, который также необходимо поддерживать. Удостоверьтесь, что вы действительно четко понимаете, что заставляет вас выбирать архитектуру, потому что нет единого "лучшего" решения - все это касается компромиссов.


Анализ опций, которые вы раскрываете:

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

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

Создайте новое приложение между базой данных и приложениями 10-15 сверху.

Это действительно хорошая возможность. Если вы не хотите, чтобы все эти приложения зависели от деталей реализации базы данных (например, изменение одной таблицы повлияло на код всех из них), вы можете "скрыть" базу данных за приложением, которое предлагает "бизнес значимые" операции с этими "клиентскими приложениями".

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


Я не понимаю, почему 10-15 приложений должны совместно использовать базу данных? Действительно ли все приложения должны использовать все таблицы?

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

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


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

Я бы сказал, что ваш второй вариант - лучший выбор здесь. Если вы находитесь на платформе .NET, WCF - это действительно простой и эффективный способ.

licensed under cc by-sa 3.0 with attribution.