Выбор сценариев развертывания для составных веб-приложений .NET - PullRequest
0 голосов
/ 07 декабря 2010

У меня есть приложение .NET v4, состоящее из веб-приложения (ASP.NET MVC2) и нескольких веб-служб (WCF).Во время разработки я развернул приложение на IIS 7.5, используя / app1 / для веб-приложения и /app1/services/serviceXX.svc для веб-служб ... Однако для производственного развертывания я хотел бы узнать, будет ли лучше развертыватьЭти приложения делятся на отдельные веб-сайты и размещают каждое из них из корневого контекста.

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

Сценарий 1 (приложение на веб-сайт)

Развертывание каждого приложения на отдельном веб-сайте в IIS 7.5 с использованием корневого контекста (/).Затем я могу назначить отдельные пулы приложений для каждого сайта.Например:

http://app1.domain.com/         <-- ASP.NET MVC2 app #1
http://app1svc.domain.com/      <-- WCF services related to app #1
http://app2.domain.com/         <-- ASP.NET MVC2 app #2
http://app2svc.domain.com/      <-- WCF services related to app #2
...

Сценарий 2 (веб-приложение для каждого веб-сайта, все службы для всех приложений на одном веб-сайте)

В этом сценарии каждое веб-приложение развертывается так же, как в сценарии1, но все веб-службы для всех приложений развернуты на одном веб-сайте iis 7.5.Я предполагаю, что преимущество в этом случае состоит в том, что только 1 веб-сайт должен иметь привязки WCF. Например:

http://app1.domain.com/         <-- ASP.NET MVC2 app #1
http://app2.domain.com/         <-- ASP.NET MVC2 app #2
http://services.domain.com/app1/    <-- WCF services related to app #1
http://services.domain.com/app2/    <-- WCF services related to app #2
...

Сценарий 3 (один веб-сайт IIS с субконтекстом для каждого приложения)

В этом сценарии есть только 1 веб-сайт IIS, и каждое приложение развертывается в подконтексте (это то, что я использую во время разработки).Этот подход (кажется?) Прост и проще в администрировании, чем другие 2, но я не уверен ... Например:

http://apps.domain.com/app1/                <-- ASP.NET MVC2 app #1
http://apps.domain.com/app1/services/svc1/      <-- WCF service #1 related to app #1
http://apps.domain.com/app1/services/svc2/      <-- WCF service #2 related to app #1
http://apps.domain.com/app2/                <-- ASP.NET MVC2 app #2
http://apps.domain.com/app2/services/svc1/      <-- WCF service #1 related to app #2
http://apps.domain.com/app2/services/svc2/      <-- WCF service #2 related to app #2
...

Я думаю, что сценарий № 1, хотя и более сложный,максимально гибкий, поскольку я могу контролировать привязки, ограничения и другие свойства, которые доступны только на уровне веб-сайта.Что думают другие?

1 Ответ

0 голосов
/ 08 декабря 2010

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

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

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


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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...