Масштабирование MVC против масштабирования многоуровневых приложений

Question

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

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

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

Поскольку многоуровневые приложения, по сути, являются компонентами, которые взаимодействуют друг с другом посредством промежуточного программного обеспечения, такого как SOAP, Sockets, .Net Remoting или RMI, было бы довольно легко масштабировать приложение путем дальнейшего распределения его компонентов.

Вопрос в том, что насчет приложения, которое разработано с использованием архитектуры MVC вместо архитектуры N-Tier? Насколько я знаю, модели, представления и контроллеры находятся на одной машине, так как кто-то может распространять веб-приложение с архитектурой MVC ??

С уважением,

Answer 1

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

Answer 2

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

Answer 3

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

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

Хотя данные хранятся немного меняется.Я использую MySQL в качестве хранилища ключей / значений, и я не использую объединения, аналогичные , что делал FriendFeed .

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