Архитектура общей базы данных и обмена сообщениями

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

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

Существуют также другие приложения с базой данных, которые также используются другими приложениями прямым соединением JDBC с кодом доступа к данным (не распространенным между двумя приложениями - дублируется!! erghh!).

Мой вопрос связан с плюсами/минусами этой архитектуры и архитектурой, где каждое приложение содержит "ведущие" данные в бункере. Если приложение x требует данных из приложения y, они используют веб-службы или некоторую технологию обмена сообщениями для получения этих данных.

Подход к обмену сообщениями приведет к возникновению проблемы, при которой коды данных справочной информации (или внешние ключи), которые используются в db других приложений, которые в настоящее время сейчас должны быть получены из другого источника. В текущей архитектуре "декодирование" для них может измениться в любое время и сразу отразиться во внешнем приложении, вместо того, чтобы иметь отношение "ведущее/ведомое", где копируются данные, или альтернативу, когда приложение x должно запрашивать приложение y просто для отображения значений декодирования.

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

Спасибо Иэн

ОТВЕТЫ

Ответ 1

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

Существует неизбежный аргумент, когда администраторы баз данных хотят смоделировать все отношения между объектами, чтобы данные 100% согласованы вообще раз. С другой стороны, у вас есть разработчики, предупреждающие администраторов баз данных о жесткой связи, которая возникает из монолитная архитектура и то, как приложения, привязанные к мастер-таблицам, не могут быть легко изменены.

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

В чем дело:

  • Совместная интеграция с базой данных, как правило, определяется "большим системным" взглядом на мир.
  • Интеграция на основе сообщений, как правило, определяется представлением "маленькой системы" в мире.

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

У всех этих систем, похоже, есть общее, что они очень дороги для изменения. И одна из причин этого, так как Джо R говорит в его ответ, плотное соединение.

Однако мы должны рассмотреть два типа связи.

Первая называется технологической связью, а это означает вертикальное соединение внутри технологического стека, обычно n-уровневое, между одним ярусом и другим уровнем.

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

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

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

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

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

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

Это "большая системная" картина мира, которая поддерживается и поощряется путем объединения разных областей вашего предприятия, используя огромные 500 таблиц баз данных.

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

Каждое приложение или услуга будет иметь свое собственное понимание того, что представляет собой данный объект, и который будет соответствовать определению этого объекта в соответствии с возможностями бизнеса, которые он поддерживает.

Примером этого является "Пользователь". CRM будет иметь совсем другое определение Пользователя, чем заказ или выполнение. Заказ только заботится о пользователе с точки зрения того, что пользователь покупает. CRM заботится о других вещах, таких как модели покупки клиентов, а выполнение заботится о имени, адресе и т.д. Это нелегко достичь с помощью одной таблицы пользователя в общей базе данных.

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

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

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

Что еще более важно, что, если CRM хочет знать, когда клиент что-то заказывает? Что делать, если заказы хотят знать, когда цены на продукты меняются, или когда товар отсутствует в запасе? Если эти услуги полностью разделены, то как они могут обмениваться данными?

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

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

В нашем примере с электронной коммерцией виды событий могут быть:

  • OrderPlaced
  • CustomerUpgradedToGold
  • ProductDiscounted
  • StockExhausted

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

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

Надеюсь, что это помогает и не слишком бессвязно.

Ответ 2

Вот один аргумент общей архитектуры базы данных, которого достаточно, чтобы этого избежать:

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

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

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

Ответ 3

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

Интеграция с базами данных

Pros

  • Единственный источник истины
  • Transactionality
  • Нет новых технологий или промежуточного программного обеспечения для управления
  • Уникальные клавиши легкие.

против

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

  • Распространение в широких пределах затруднено. Тем не менее многосайтовая архитектура.

  • Технология фиксирована и поставщик заблокирован в
  • Жесткая печать в базе данных (при условии, что SQL) заставляет системные обновления для небольших изменений, таких как изменение размера столбца.

Система сообщений

Pros

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

против

  • Новая система развертывания и управления производством.
  • Трансактивность затруднена.