Каковы рекомендуемые шаги для создания масштабируемых веб-/корпоративных приложений на Java и .NET? Меня больше интересует, что нужно, чтобы перейти от приложения с небольшим объемом к приложению с большим объемом (при условии отсутствия серьезных ошибок в исходной архитектуре). Например, каковы параметры каждой платформы для кластеризации, балансировки нагрузки, управления сеансами, кэширования и т. д.
Сравнение масштабируемой архитектуры веб-приложений на Java и .NET
Ответы (4)
К сожалению, есть много аспектов вашего вопроса, которые будут зависеть от контекста. Масштабируемость может означать разные вещи в зависимости от ваших требований и приложения. Вопросы, на которые необходимо ответить, когда вы придумываете свою архитектуру (независимо от используемой технологии), включают:
- Например, вы хотите поддерживать пользователей, работающих с очень большими объемами данных, или вам просто нужно поддерживать большое количество пользователей, каждый из которых работает с относительно небольшими объемами данных?
- Делает ли ваше приложение больше операций чтения, чем записи, так как операции чтения дешевы, а записи дороги, приложение, интенсивное чтение, может быть проще масштабировать, чем приложение, интенсивное запись.
- Всегда ли данные в вашем приложении должны быть непротиворечивыми или будет достаточно согласованности в конечном итоге? Подумайте о размещении сообщения в социальной сети вместо снятия денег с банковского счета).
- Насколько доступным должно быть ваше приложение? Строгие требования к высокой доступности, вероятно, потребуют плавного переключения на другие серверы в случае сбоя одного сервера.
Есть много других подобных вопросов, на которые необходимо ответить о вашем конкретном приложении, прежде чем можно будет начать надлежащее обсуждение архитектуры вашего приложения.
Тем не менее, я не просто оставляю вам вопросы и не даю ни одного ответа. Вот что я считаю самым важным, что следует учитывать при разработке масштабируемого веб-приложения: Уменьшить (по возможности до нуля) количество общего состояния сеанса в вашем приложении (глобальные счетчики приложений, кэшированные блоки первичного ключа и т.п.). Репликация общего состояния в кластере требует очень больших затрат при масштабировании.
person
Tendayi Mawushe
schedule
17.01.2010
Возможно, вариантов так много, я не уверен, что кто-то рассмотрел все варианты в полном объеме. Обычно сначала идет выбор языка, а затем вы решаете, как добиться желаемых результатов.
Я предполагаю, что у вас есть хорошие варианты практически для любого основного языка общего назначения. Это было бы проблемой 10 лет назад, но не сегодня, ИМХО.
Хорошим сравнением доступных технологий с открытым исходным кодом в Java является http://java-sources.org/. углубившись в каждую категорию, вы можете увидеть, что это довольно обширно и даже рассматривает коммерческие продукты или C #
Для любой масштабируемой системы необходимо также учитывать аппаратные решения, такие как сетевые компоненты.
Мое предложение по превращению приложения с небольшим объемом в приложение с большим объемом — начать с чего-то довольно большого объема в первую очередь и ожидать его реинжиниринга по ходу работы.
О каких объемах идет речь? У всех разные ожидания от высокого и низкого объема. например Когда у Google объемы ниже среднего, они переключают целые центры обработки данных для экономии энергии. ;)
person
Peter Lawrey
schedule
17.01.2010
Только что наткнулся на это объяснение того, как вырос MySpace, действительно интересное и именно та информация, которая мне нужна. находясь в поиске. Тем не менее, нет обсуждения технологий, используемых для создания разделов или кэширования и так далее...
person
Abdullah Jibaly
schedule
05.02.2009
Краткий ответ - это зависит. Какие (если есть) бизнес-цели задействованы? Какой бюджет и сроки проекта? Какая отрасль (регулируется)?
person
Kris Krause
schedule
17.01.2010
