Мы создаем веб-платформу, которая включает в себя несколько сервисов, каждый из которых имеет свои собственные базовые данные. Эти сервисы создаются независимо от принципов Сервис-ориентированной архитектуры , но они взаимодействуют с потенциально связанными данными. Мы рассматриваем, должны ли эти службы совместно использовать одну большую базу данных или у каждой есть своя собственная база данных. (Мы планируем использовать SQL Server 2008 Enterprise в кластере Windows 2008).

Некоторые из преимуществ каждого подхода, который мы уже рассмотрели, включают:

Единая база данных

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

Несколько баз данных

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

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

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

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

Я бы порекомендовал почитать сайты, такие как HighScalability.com, которые используют архитектуру, принятую на веб- сайтах с постоянным доступом Одной из моих любимых в последнее время была история с обезьяной Netflix Chaos Monkey, которая упоминалась в « Кодирующем ужасе» .

Обращаясь к нескольким пунктам в вашем вопросе:

В случае аварии восстановить платформу до согласованного состояния проще.

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

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

Решения по распределенному кешу (memcached и др.) Могут здесь помочь, но вы нарушите принципы независимости сервиса. Это было бы сравнимо с наличием двух сервисов, напрямую взаимодействующих друг с другом, или, что еще хуже, с доступом к хранилищу данных другого сервиса, полностью обходя интерфейс сервиса. Данные неизбежно будут связаны и будут передаваться между службами вызывающей платформой; сложные решения, как правило, касаются того, какой службе будут принадлежать какие фрагменты данных. Возможно, сайты StackOverflow или Programmers лучше подходят для решения более общих проблем с SOA.

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

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

Если это не SOA, и у вас просто есть случай, когда компонентные сервисы этой платформы создаются различными командами / поставщиками по логистическим причинам, придерживайтесь единой базы данных и полностью игнорируйте все вышеперечисленное! :)