Архитектура для мультитенантного среднего уровня

Question

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

Мы пытаемся решить, следует ли иметь отдельный путь от клиентского приложения через веб-службу, бизнес-логику и доступ к данным к базе данных для каждого клиента или иметь один общий экземпляр каждой части. при этом уровень доступа к данным отвечает за получение данных из правильного экземпляра SQL Server или где-то между этими двумя.Благодаря единому общему пути для всего, если какой-либо элемент выйдет из строя, все клиенты, обращающиеся к нему, окажутся мертвыми.С другой стороны, с индивидуальными путями для каждого клиента (по-видимому) есть что-то еще, что нужно поддерживать, помимо, возможно, чрезмерной сложности?Вот ужасное художественное изображение ASCII двух вариантов, которые мы рассматриваем:

[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]
          |--> [Web Service] --> [Business Logic] --> [Data Access] ----|
[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]

Или это:

[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]

Какой из этих вариантов (или какой промежуточный вариант) будет лучше и почему?

Answer 1

Это довольно общий вопрос, поэтому я дам довольно общий ответ.Раньше я строил платформы на подобных принципах, и единственный совет, который я могу вам дать, — это тщательно подумать о разделении архитектуры на два уровня:

• Полностью универсальная структура, которая обрабатывает все распространенные универсальные операции.
• Настраиваемый уровень, специфичный для клиента, в котором вы можете содержать любые необычные функции, специфичные для клиента.

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

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

Надеюсь, это поможет.