Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java: Общие вопросы > развернуть высоконагруженное серверное java-прилож


Автор: tmlder 13.12.2011, 16:57
Привет!

Задача развернуть высоконагруженное серверное java-приложение. 
1) Что лучше, арендовать выделенные сервера или поставить свои, сделав свой мини-дата центр?
2) Какие стойки, какие серверы, какие цены, какое оборудование лучше закупить?
3) Какую литературу почитать на темы начиная от написания java сервера, выбора субд и т.п. заканчивая жедезными серверами и их настройкой?

Вопросы туманные от непонимания, не судите строго.
Хотелось бы иметь хотя бы примерное понимание по перечисленным вопросам и понимание в какую-сторону копать.

Ссылки и летаратура привествуется.

Автор: LSD 13.12.2011, 17:12
1), 2) Вопросы преждевременны, пока у вас не готова архитектура приложения. 3) тут все сложно, литература конечно есть, но опыт важней. Почитайте как устроены другие высоконагруженные сервисы (в сети полно рассказов на эту тему), чтобы получить общее представление. Это для начала, потом будет виднее.

Автор: tmlder 13.12.2011, 19:31
Архитектура приложения готова. Обычное web java (hibernate, spring mvc) приложение на tomcat.

Автор: priam220 13.12.2011, 22:49
аренда дешевле будет. поможет определится какие мощности вам нужны.

Автор: Stolzen 14.12.2011, 00:42
Вот есть такое - http://jelastic.com/

А вообще смотря на сколько высоконагруженное. Может одного томката под прикрытием nginx для разради статики хватит. Не хватает - разворачиваете еще один инстанс томката, nginx как балансировщик запросов (и так, пока не будет нужной производительности). Для начала, я думаю, хватит арендованного сервера.

Автор: LSD 14.12.2011, 10:18
Цитата(tmlder @  13.12.2011,  20:31 Найти цитируемый пост)
Архитектура приложения готова. Обычное web java (hibernate, spring mvc) приложение на tomcat. 

1. хибер и спринг это не то, что обычно используется в высоконагруженных приложениях.
2. Не вижу в этой схеме кешей, вообще.
3. Как будет реализовываться распаралеливание работы?

Автор: tmlder 14.12.2011, 10:49
Цитата(LSD @ 14.12.2011,  10:18)
Цитата(tmlder @  13.12.2011,  20:31 Найти цитируемый пост)
Архитектура приложения готова. Обычное web java (hibernate, spring mvc) приложение на tomcat. 

1. хибер и спринг это не то, что обычно используется в высоконагруженных приложениях.
2. Не вижу в этой схеме кешей, вообще.
3. Как будет реализовываться распаралеливание работы?

1) Это так, но мы готовы переплатить за железо.
2) Про какой кэш вы говорите? Посоветуйте, пожалуйста.
3) Ну описали же, что будут репликации web части на другие сервера.

Правильно ли я понимаю?
Посоветуйте, КНИГУ.

Добавлено через 1 минуту и 34 секунды
Цитата(priam220 @ 13.12.2011,  22:49)
аренда дешевле будет. поможет определится какие мощности вам нужны.

Ну как дешевле?
Аредна сервера, который стоит 60 000 р. будет составлять в месяц 5000 р. То есть на 12 месяцев.

Купить выгоднее, очевидно же.

Автор: Stolzen 14.12.2011, 11:07
Цитата(LSD @  14.12.2011,  11:18 Найти цитируемый пост)
1. хибер и спринг это не то, что обычно используется в высоконагруженных приложениях.

Ну почему, LinkedIn используют Spring. Правда у них ORM нет. 

Автор: LSD 14.12.2011, 12:16
Цитата(tmlder @  14.12.2011,  11:49 Найти цитируемый пост)
Это так, но мы готовы переплатить за железо.

Тут есть недопонимание. Если вас устроит пара мощных серверов, то в моем понимании это не высоконагруженный проект. Вот что я понимаю под http://www.insight-it.ru/highload/.


Цитата(tmlder @  14.12.2011,  11:49 Найти цитируемый пост)
Про какой кэш вы говорите? Посоветуйте, пожалуйста.

Не могу. Я не знаю ни объемов, ни нужно ли распределенный кластер или хватит пары серверов, каждый из которых содержит независимую реплику.


Цитата(tmlder @  14.12.2011,  11:49 Найти цитируемый пост)
Ну описали же, что будут репликации web части на другие сервера.

Репликация чего, чтения, записи? У сервера есть состояние или он stateless? Fault tolerance нужен? Что с базой?
У вас есть диаграмма как будут балансироваться запросы от клиентов, как будут вести себя сервера в случае выхода одного из строя, что будет в случае отказа СУБД?


Цитата(Stolzen @  14.12.2011,  12:07 Найти цитируемый пост)
Ну почему, LinkedIn используют Spring. Правда у них ORM нет.  

Они оттуда используют только Spring context и все. Ни Spring JDBC, ни Spring MVC, ни кеширование, ничего такого они не используют.

Автор: tmlder 14.12.2011, 12:47
Цитата(LSD @ 14.12.2011,  12:16)
Цитата(tmlder @  14.12.2011,  11:49 Найти цитируемый пост)
Это так, но мы готовы переплатить за железо.

Тут есть недопонимание. Если вас устроит пара мощных серверов, то в моем понимании это не высоконагруженный проект. Вот что я понимаю под http://www.insight-it.ru/highload/.


Цитата(tmlder @  14.12.2011,  11:49 Найти цитируемый пост)
Про какой кэш вы говорите? Посоветуйте, пожалуйста.

Не могу. Я не знаю ни объемов, ни нужно ли распределенный кластер или хватит пары серверов, каждый из которых содержит независимую реплику.


Цитата(tmlder @  14.12.2011,  11:49 Найти цитируемый пост)
Ну описали же, что будут репликации web части на другие сервера.

Репликация чего, чтения, записи? У сервера есть состояние или он stateless? Fault tolerance нужен? Что с базой?
У вас есть диаграмма как будут балансироваться запросы от клиентов, как будут вести себя сервера в случае выхода одного из строя, что будет в случае отказа СУБД?


Цитата(Stolzen @  14.12.2011,  12:07 Найти цитируемый пост)
Ну почему, LinkedIn используют Spring. Правда у них ORM нет.  

Они оттуда используют только Spring context и все. Ни Spring JDBC, ни Spring MVC, ни кеширование, ничего такого они не используют.

Я не знаю ответы на эти вопросы.
Что читать чтобы разобраться?

Автор: LSD 14.12.2011, 15:07
Цитата(tmlder @  14.12.2011,  13:47 Найти цитируемый пост)
Я не знаю ответы на эти вопросы.

И книги тоже не знают, никто кроме вас объем данных оценить не сможет. Вам надо самим искать ответы.


Цитата(tmlder @  14.12.2011,  13:47 Найти цитируемый пост)
Что читать чтобы разобраться? 

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)