Какие критерии есть, чтобы начать рассматривать 3 уровня арки для публичного сайта - PullRequest
Новая
       20

Какие критерии есть, чтобы начать рассматривать 3 уровня арки для публичного сайта

1 голос
/ 31 января 2012

Существуют ли какие-либо критерии, которые необходимо знать / обдумать, прежде чем принять решение использовать 3T или 2T arch для общедоступного веб-сайта, чтобы избежать путаницы, я называю Tier автономным физическим сервером, а веб-браузер - не считается уровнем, так сказать 3T для:

  • T1 - веб-сервер: где вы размещаете общедоступный интерфейс пользователя, это могут быть MVC, JSF, веб-формы ASP.NET и т. Д.
  • T2- приложение: где вы размещаете свои бизнес-веб-сервисы SOAP, REST и т. Д ...
  • T3- БД: Ваш сервер БД, Oracle, SqlServer и т. Д ...

Где 2T означает только веб-сервер и БД, бизнес по-прежнему разделен, но выполняется в том же процессе, на котором работает веб-сервер.

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

Если stackoverflow не предназначен для этих типов вопросов, я не знаю, что осталось? int swapping?

Ответы [ 2 ]

1 голос
/ 07 февраля 2012

Существует аналогичный вопрос о стековом потоке: Адресация масштабируемости, производительности в веб-приложении .net . Большинство ответов на этот вопрос НЕ ДОПУСКАЮТСЯ для 3T ради достижения масштабируемости. По умолчанию учитывает два уровня , если только не возникает других факторов, кроме масштабируемости.

1 голос
/ 01 февраля 2012

Я нашел этот блог, в котором говорится об определенном продукте, я думаю, но тот же принцип верен, я верю http://www.ektron.com/billcavablog/your-questions-answered-3tier-or-2tier/

Автор перечислил пять критериев (атрибутов), которые помогут принять решение:

  • Безопасность. В некоторых организациях, таких как финансовые учреждения, действуют сетевые политики, в которых говорится, что сайт, работающий в прямом направлении, не может напрямую взаимодействовать с базой данных. Эти организации требуют, чтобы база данных находилась в сети, недоступной с веб-сайта, обращенного вперед. В подобных случаях требуется трехуровневая архитектура, поскольку она удовлетворяет этой сетевой политике, поскольку передний интерфейсный веб-сайт взаимодействует только со средним уровнем и не знает ни о какой базе данных.
  • Масштабируемость. Возможно, вы разрабатываете маркетинговый веб-сайт, который должен уметь обрабатывать скачки сезонного трафика. Чтобы удовлетворить это требование, вам может потребоваться сократить количество доступных передних машин в короткие сроки. Так как интерфейс имеет очень минимальную площадь Ektron (нет установки Ektron, мало DLL, нет рабочей области), горизонтальное масштабирование очень просто. Например, используя Amazon EC3, вы можете легко масштабировать по горизонтали, добавляя новые экземпляры машин вашего внешнего интерфейса.
  • Производительность. Чтобы минимизировать общение между интерфейсным и промежуточным серверами в 3-уровневой архитектуре, Ektron предоставляет уровень кэширования, который находится чуть ниже API-интерфейсов Framework и находится на внешнем интерфейсе. Этот слой управляет прозрачным хранением, извлечением и истечением срока действия его данных. Технически этот уровень кэширования также доступен в 2-уровневой архитектуре, но об этом следует помнить при работе, в частности, с 3-уровневым, учитывая его роль в минимизации сетевых запросов на промежуточном уровне и повышении производительности.
  • Доступность. Если у вас особенно высокие требования к времени безотказной работы, вы можете рассмотреть возможность использования трехуровневой системы для обслуживания кэшированных данных из интерфейсной памяти даже в тех случаях, когда промежуточный уровень или база данных недоступны.
  • Функциональная совместимость - использование 3-х уровней открывает возможность использования любой инфраструктуры веб-приложений на уровне доставки, например, ASP.NET Web Forms (веб-приложение), Web Forms (веб-сайт) или даже ASP.NET MVC. Уровень обслуживания также может использоваться любым интерфейсным приложением, которое может взаимодействовать с уровнем обслуживания WCF (Java и т. Д.).
...