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

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

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

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

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

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

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