Выбор средств для разработки высоконагруженного веб приложения?

Question

[prizrak39]

Здравствуйте.
На сегодня на нулевом уровне приступил к разработке системы (веб сервис), которая должна выдерживать высокие нагрузки и быть масштабируемой. На первоначальном этапе нагрузки будут небольшие, так как запускаться проект будет с минимальным функционалом, но достаточно быстро функционал и следовательно посещаемость (по прогнозам - я за это не отвечаю, предо мной просто ставят такую задачу) буду увеличиваться.
Сейчас исходя из требований стоит выбор средств для разработки.
Примечание - опыт разработки на Java около 3-х лет. На PHP год.
Варианты:
1) Использование Drupal. На первоначальном уровне при минимальном функционале и нагрузке может быть хорошим решением, но далее на мой взгляд могу возникнуть проблемы с расширением функционала. И время потраченное на доработку под свои требование не уверен что будет меньше чем писать с нуля.
2) С нуля. PHP+Laravel+Bootsrap+jQuery. База данных MySQL (возможно использование PostgreSQL). Быстрой разработка не будет, но нет ограничения по функционалу.
3) С нуля. Основой должен стать веб-сервис написанный на JAVA - он будет отдавать сервису всю информацию. Возможно ли будет в клиентской части обойтись малым применением PHP? То есть большая часть будет в виду AJAX запрос и построение страницы с помощью JavaScript. Насколько такой вариант будет выдерживать высокие нагрузки? Веб-сервис тогда будет универсальным и работать в будущем с мобильным приложением.
4) С нуля. Более экзотический вариант - Grails + Groovy. Вопрос насколько будет быстро работать, учитывая динамическую типизацию.....

Прошу помочь выбрать оптимальный вариант исходя из Вашего опыта.
Заранее спасибо.

Answer 1

[Viktor Vsk]

системы (веб сервис), которая должна выдерживать высокие нагрузки и быть масштабируемой.

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

Насколько такой вариант будет выдерживать высокие нагрузки?

насколько будет быстро работать, учитывая динамическую типизацию

Это называется преждевременной оптимизацией

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

Узнать, что будет производительным, а что нет - нужно с помощью профайлера, в крайнем случае - по бенчмаркам. Но никак не задавая вопросы на форумах - просто никто не имеет физической возможности дать объективный ответ на абстрактный вопрос.

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

Если у вас есть опыт с джавой в вебе - делайте на джаве.

Есть опыт с джаваскриптом - делайте на основе веб-сервисов.

У каждого подхода есть плюсы и минусы и обычно они субъективны.

Лучше потратить 2 месяца на прототип и потом - месяц на переписывание, чем сначала 3 месяца думать и делать - а потом понять, что нужно было двигаться в другую сторону.

Описаны ~80% случаев и ваш с вероятностью > 90% попадает именно в эту область.

Comments

[prizrak39]

Большое спасибо. Про прототип возможно Вы правы, спроектировать приложение с минимальных функционалом и понять подходит ли данный вариант реализации или нет.

Answer 2

[Леша Киселев]

Главная фишка высоконагруженных приложений не в выборе технологий, а в архитектуре. Зачастую, узким местом приложения является база данных. Первое, что нужно сделать - это научиться масштабировать данные. Ищем по ключевым словам "шардирование", "репликация".
После того, как данные масштабируются, можно думать о включении кэширующего слоя. Ищем "memcached", "redis".
Если начинает не справляться фронтенд (фронтенд бэкэнда), подключаем балансировщик нагрузки. Как на уровне DNS, так и на уровне отдельных инстансов фронтенда.
Раздаете много статики? CDN вам в помощь.
Много сложных и ресурсоемких вычислений, результат выполнения которых не требует моментального отображения клиенту? Разворачиваем очереди задач и считаем это в фоне.
А уж какую технологию выбрать java или php это Вам виднее. То, что лучше знаете и сможете поддерживать.

Советую почитать ruhighload.com/scale

Comments

[prizrak39]

Спасибо за наводку. А выбор СУБД играет большую роль чем выбор языка реализации? Например MySQL или PostgreSQL?

Answer 3

[Philipp]

Из представленной вами информации я бы рекомендовал Java приложение, способное к горизонтальному масштабированию. В общем случае архитектура будет выглядеть примерно так: запросы поступают на балансировщик, который будет разбрасывать их на несколько серверов, на которых запущено Java приложение.
Так как ваш проект по большей части веб-сервис, то генерировать множество seo-оптимизированных страниц не требуется. Значит разумнее всего использовать подход, типичный для веб-приложений. Т.е. строить JavaScript приложение, которое будет взаимодействовать с API. Правда необходимо учесть один фактор - бизнес-логика все же должна быть сохранена внутри API.
В качестве БД я бы рекомендовал использовать современные NoSQL решения, вроде MongoDB. Они легко масштабируются, что чрезвычайно важно при разработке систем с высокой нагрузкой.
Плюс при масштабировании нужно учитывать один интересный фактор, о котором мало упоминают или вообще считают спорным. Но правильное масштабирование выглядит примерно так - сначала вертикальное, затем горизонтальное. Т.е. вначале лучше масштабировать выбирая более быструю машину, но когда зайдет речь о спец решениях вроде кластера, то начинать горизонтальное масштабирование. Но здесь опять все зависит от вида затыков в вашей системе.
На вашем месте выбрал бы следующий стек: Java+MongoDB+AngularJS. В качестве балансировщика можно либо nginx (бюджетный вариант), либо размещать все внутри AWS и использовать ELB. Для доставки клиентской части нужно использовать CDN. Например Cloudflare.

Comments

[prizrak39]

Спасибо за подробный ответ. Правильно ли я понял - с помощью Java реализовать веб-сервис который будет обеспечивать API (например взаимодействие по JSON). На стороне фронтэнда будет работать AngularJS. В качестве СУБД использовать MongoDB.

[Philipp]

prizrak39: все верно. На Java реализуете API, который будет принимать и отдавать JSON.

Answer 4

[Super User]

Использование Drupal. На первоначальном уровне при минимальном функционале и нагрузке может быть хорошим решением, но далее на мой взгляд могу возникнуть проблемы с расширением функционала.

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

С нуля. Основой должен стать веб-сервис написанный на JAVA

Java тоже нехило так кушает оперативку, но в плане производительности конечно шустрее пхп.

Comments

[prizrak39]

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

[Леша Киселев]

>> "Вообще PHP это плохой выбор для высоконагруженного проекта"
Не согласен c этим. Посмотрите мой ответ.

[Super User]

Леша Киселев: Ну вот вы там говорите про очереди задач, это уже по сути костыль. И memcached это тоже костыль. вы по сути скрываете недостатки технологии этими костылями.

[Леша Киселев]

Super User: Опять не согласен. Бывают сложные вычисления, о результате которых юзеру не имеет смысла знать. Их выгоднее делать в фоне. Можно использовать очереди, можно открывать отдельный тред и считать там. Очередь надежнее, если требуется гарантировано выполнить эти вычисления.
Я говорил не конкретно о memcached/redis, а о кэширующем слое. Хотите локальный кэш каждого приложения? Пожалуйста.

[Super User]

Леша Киселев: Ну в чем-то вы наверно правы, но в данном конкретном случае челу лучше использовать Java. Тем более он его скорее всего лучше знает.

Answer 5

[bromzh]

Groovy тормоз, судьба Grails неизвестна. Тут уж тогда лучше Scala + какой-то фреймворк. Java и её серверы быстрые, но всякие ORM, EJB и друшие штуки эту скорость поглощают.
Просто научиться разрабатывать веб на яве достаточно непросто.