Сравнение масштабируемой архитектуры веб-приложений на Java и .NET

Question

Каковы рекомендуемые шаги для создания масштабируемых веб / корпоративных приложений на Java и .NET? Меня больше интересует, что нужно, чтобы перейти от приложения с низким уровнем громкости к приложениям с большим объемом (при условии отсутствия серьезных сбоев в исходной архитектуре). Например, каковы параметры на каждой платформе для кластеризации, балансировки нагрузки, управления сеансами, кэширования и т. Д.

Answer 1

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

• Например, хотите ли вы поддерживать пользователей, работающих с очень большими объемами данных, или вам просто нужно поддерживать большое количество пользователей, каждый из которых работает с относительно небольшими объемами данных?
• Делает ли ваше приложение больше чтения, чем записи, так как чтение дешево, а запись дорого, приложение с большим объемом чтения может быть проще масштабируемым, чем приложение с большим объемом записи.
• Являются ли данные в вашем приложении всегда согласованными или будет достаточной согласованность? Подумайте, отправив сообщение на сайт социальной сети вместо того, чтобы снимать деньги с банковского счета).
• Насколько доступным должно быть ваше приложение? Строгие требования высокой доступности, вероятно, потребуют от вас плавного переключения на другие серверы при сбое одного сервера.

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

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

Answer 2

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

Полагаю, у вас есть хорошие варианты практически для любого основного языка общего назначения. Это было бы проблемой 10 лет назад, но не сегодня ИМХО.

Хорошее сравнение доступных технологий с открытым исходным кодом в Java: http://java -sources.org / Когда вы углубляетесь в каждую категорию, вы можете увидеть, что она довольно обширная и даже рассматривает коммерческие продукты. или C #

Для любой масштабируемой системы необходимо учитывать также аппаратные решения, такие как сетевые компоненты.

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

О каких объемах вы говорите? У каждого разные ожидания от высокого и низкого объема. например Когда у Google объемы ниже среднего, они переключают целые центры обработки данных для экономии энергии. ;)

Answer 3

Краткий ответ - это зависит. Какие (если таковые имеются) бизнес-цели связаны? Каков бюджет проекта и сроки? Какая отрасль (регулируется)?

Answer 4

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