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

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

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

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

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

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

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