3-уровневая архитектура v. Архитектура с 3 серверами

Question

Я создаю традиционный сайт .NET MVC, поэтому у меня есть естественная трехуровневая программная архитектура (представление в виде представлений, бизнес-уровня в контроллере , и уровень данных в моделях и уровень доступа к данным).

Когда я развертывал такие сайты, он обычно идет либо на одном сервере (где веб-сайт и db live), либо на двух серверах (веб-сервере и отдельном сервере db).

Как идти о архитектуре с 3 серверами (WEB, APP и DB)? Будет ли веб-сервер иметь только презентацию (например, физические страницы View/aspx), сервер приложений будет содержать файл конфигурации и папку bin, а сервер db останется таким, как есть?

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

Answer 1

В некоторых кругах я рассматривал это обсуждение как различие между n-ярусом и n-слоем, где «слой» в этом контексте потенциально представляет собой другую машину. Чтобы иметь средний уровень, используя это определение, он должен быть размещен. Например, если у вас был сервисный уровень, на котором слой представления вызывал, чтобы получить свои данные, тогда уровень сервиса может быть на другой машине, чем презентация или база данных. Однако этот уровень обслуживания размещен либо как служба Windows, либо как веб-служба. I.e., есть процесс прослушивания запросов на этой машине. Таким образом, вы не можете просто переместить папку bin на другую машину и надеяться на эту работу. Я бы посмотрел на WCF (Windows Communication Foundation) для создания этих типов сервисов.

Answer 2

Следующая логическая шкала вверх будет двумя веб-серверами и одним сервером базы данных.

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

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

Answer 3

ASP.NET MVC не поможет вам в создании системы 3tier. Это действительно только шаблон интерфейса.

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

Есть причины иметь отдельный сервер приложений: у вас может быть логика, в которой требуется другое приложение, или у приложения-сервера могут быть разные разрешения, чем веб-сервер. Но трудно представить себе сайт с высоким трафиком, где все запросы ведут к вызову на удаленный сервер приложений.

Answer 4

Так что ваши вопросы, кажется ...

«вы можете просто переместить/бункер и все приложения логики на отдельный сервер с мнением презентации?»

Если я правильно понимаю, я считаю, что файлы в папке bin будут скомпилированными кодами для ваших страниц asp.net. Если это так, то нет, я считаю, что они должны быть на той же машине, что и страницы asp.

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

Answer 5

MVC не 3-уровневая архитектура. Не каждое решение нуждается в, чтобы быть 3-ярусным или n-ярусным, но по-прежнему важно понимать различие. MVC случается, есть 3 основных элементов, но эти элементы не работают в «многоуровневую» моде, они взаимозависимы:

Model <----- Controller 
     \  | 
      \  v 
      ---- View 

The View зависит от модели. Контроллер зависит от модели и. Таким образом, эти множественные пути зависимостей не функционируют как уровни.

Обычно 3-х уровневая решение выглядит следующим образом:

Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI 

Presenter/Controller несколько опционально - в Windows Forms развития, например, вы обычно не видите его, вместо того, чтобы у вас есть «умный клиент «UI, и это тоже нормально.

Это трехуровневая архитектура, потому что каждый из трех основных уровней (Data, Domain, UI) имеет только одну зависимость. Классически пользовательский интерфейс зависит от модели домена (или модели «Бизнес»), а модель домена зависит от DAL. В более современных реализациях модель домена не зависит от DAL; вместо этого взаимосвязь инвертируется, а абстрактный слой Mapping вводится позже с использованием контейнера IoC. В любом случае каждый уровень зависит только от предыдущего уровня.

В архитектуре MVC C является контроллером, V является пользовательским интерфейсом (Views), а M является моделью домена. Поэтому MVC - это архитектура представления, а не системная архитектура. Он не инкапсулирует доступ к данным. Это может не обязательно полностью инкапсулировать модель домена, которая может рассматриваться как внешняя зависимость. Он не многоуровневый.

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

архитектура сервера отражает схему 3-го уровня выше:

Database Server <----- Web Services <----- Application 

«приложение» это приложение MVC, которая разделяет модели предметной области с веб-службами (через SOAP или REST). Веб-службы запускаются на выделенном сервере (или серверах), и база данных, очевидно, размещена на собственном сервере. Это трехуровневая 3-серверная архитектура.