Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Регистрация Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > PainKiller

Оценить эту запись

Поднимаем сервер в облаке (Jelastic + Java + Tomcat + MySQL + BlazeDS) Часть I

Запись от PainKiller размещена 27.02.2014 в 12:58
Обновил(-а) PainKiller 05.03.2014 в 12:19

У меня давно уже была идея одного «своего» клиент-серверного проекта (социального приложения), от реализации которого меня останавливала сложная серверная часть. Написать флеш/флекс клиента для меня проблемы не представляет, а вот к написанию сервера я решился приступить только совсем недавно, и в серии постов хочу поделиться своим опытом. Сразу скажу, что в них не будет подробных описаний со скриншотами о том, как создать проект в NetBeans, или таблицу в MySQL, скорее они ориентированы на флешера моего уровня, имеющего базовые представления о серверной яве и базах данных, но не имеющего опыта написания сервера. Надеюсь, что таким людям, мои посты подскажут направление движения, и сэкономят силы и время.
И так как это вводный пост, сперва поясню причины выбора заявленной конфигурации.

1. Почему Java?

Я одинаково плохо знаю и Java и PHP, и поэтому я долго колебался между этими языками, и на начальном этапе даже локально запустил две альтернативные тестовые конфигурации серверов одну на amfphp, другую на BlazeDS. Решил все-таки писать на яве, потому что мне комфортнее работать с типизированным языком, плюс навыки программирования на яве оплачиваются дороже (да, да помним, что флеш умирает и надо намечать пути отхода).

2. Почему Jelastic?

Соответственно встал вопрос выбора хостинга, желательно бесплатного, и в случае с явой выбор тут не очень богатый. Не хочу рекламировать Jelastic, но остановился на нем из-за простоты использования (любая конфигурация сервера/серверов с БД на любой вкус, разворачивается в считанные минуты и не надо ничего настраивать), отсутствием привязки к своему API (как например у Google App Engine), гибкой тарификации (платишь только за потребляемые ресурсы в виде клаудлетов, 3 клаудлета дается бесплатно). В этом облаке даже новичку достаточно просто разобраться, как собрать кластер серверов и настроить балансировщик, для этого предоставлен простой и удобный интерфейс, репликация сессий реализована в самом Jelastic. Насчет цены - моя конфигурация сервера, которую я использую только для разработки и тестирования, обходится мне 2 – 4 копейки в день, можно еще сэкономить если вырубать её, например, на выходные, но это совсем уже жлобство)). И при этом все можно быстро масштабировать в высоконагруженный сервер (или кластер серверов с балансировщиком), хотя конечно это будет значительно дороже. Из минусов сервиса хочется отметить, что ребята особо не парятся: есть косяки в документации, и даже плагин для NetBeans, они до сих пор не обновили до поддержки версии 7.4, мелочь, а неприятно.

3. Почему Tomcat?

Из явовских серверов я пробовал только Tomcat и Glassfish. Последний очень сложен (зацените объем доков, один только application-development-guide.pdf содержит 252 стр), иногда выкидывает непонятные «мистические» ошибки, и выгода от его использования не очевидна, тем более что некоторый его функционал и так уже реализован в Jelastic. Tomcat же простой и надежный, поэтому остановился на нем.

4. Почему MySQL?

Я до сих пор не уверен, правильно ли я сделал, что стал работать с реляционной БД, все-таки NoSQL значительно проще в разработке, и в Jelastic за такие же деньги можно использовать конфигурацию с MongoDB. Но хранится у меня будет в основном сложная статистика по пользователям, которая прекрасно укладывается в таблицы + хотелось освоить работу с реляционной БД.

5. Почему BlazeDS?

Ну то, что AMF для флеша является самым быстрым форматом общения с сервером, ни у кого не вызывает сомнений (кто не верит, может поиграться с этим приложением). Но помимо этого, я обнаружил, что работа с XML и JSON, на яве гораздо более геморная чем в ActionScript 3, и поэтому использование BlazeDS оказывается еще и самым ПРОСТЫМ И БЫСТРЫМ вариантом разработки, в дальнейшем вы это увидите сами.

Ну и напоследок, – какова скорость сервера такого типа? Я попробовал погуглить на эту тему и получил очень широкий разброс цифр, а зависимости от серверного железа и исполняемого кода он может держать от 20 до 20000 запросов в секунду. В нашем случае узким местом будет скорость запросов к MySQL, поэтому, наверное, мы будем ближе к нижнему пределу производительности. На чистой же JAVA + AMF, и хорошем железе, вполне реально достичь верхнего предела.
Всего комментариев 24

Комментарии

Старый 27.02.2014 15:05 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
> Jelastic.
Есть ещё Heroku. Там можно собрать такую же конфигурацию забесплатно

> MySQL
Думал речь пойдёт почему именно MySQL =). Примерно во всех случаях я за Postgres, чем за MySQL.

> NoSQL
Они достаточно разные, чтобы не склоняться к одной из них. ИМХО, самый простой тест это спросить себя: "что важнее: данные или скорость?". Реляционные базы скопытяться под нагрузкой, но они гарантируют сохранность данных. Например, если дело имеется с деньгами – NoSQL я бы никогда не стал использовать.
NoSQL как правило шустрые как понос, но они вполне могут отказать на запись – мол, "иди покури, я запишу позже.. или не запишу. В конце концов я здесь главный!". Идеально для логирования чатиков, например. Когда одно сообщение на миллион не пишется с первой попытки – это не страшно.

> скорость запросов к MySQL
Верхний предел одной связки сервер-БД не так важен, как возможность горизонталього масштабирования.
Кластер серверов – Кластер БД. SQL базы "честно" не масштабируются, но самое безобидное master-slave чаще всего не является проблемой и может серьезно пропускную способность.

Кстати, когда 20к запросов в секунду – это такой успех, при котором инвесторы сами трясут деньгами перед лицом. Будет траффик – возможность и идеи масштабирования появятся сами.
Старый 27.02.2014 15:17 PainKiller вне форума
PainKiller
 
Аватар для PainKiller
Про Heroku не знал, спасибо посмотрю, тут в принципе тоже не сильно дорого.
NoSQL - сохранность данных для меня важна, но не критична, поэтому до сих пор в раздумьях.
Цитата:
Кстати, когда 20к запросов в секунду – это такой успех, при котором инвесторы сами трясут деньгами перед лицом.
Про это я тоже так подумал, поэтому насчет нагрузки особо не парюсь
Старый 02.03.2014 18:53 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Цитата:
Сообщение от Psycho Tiger
Реляционные базы скопытяться под нагрузкой, но они гарантируют сохранность данных.
Это кто тебе такую глупость сказал?
Я бы например не рискнул ставить носкуль там где нужна выборка и сортировка полутора тысяч записей из общей массы в три ляма.
Реляционные базы как раз своим скулем и хороши, страничная обработка, блаблабла. Очень всё бычтро и круто делают. Носкуль скопытится на этой задаче в разы быстрее.

Зато если нужен адресный доступ к заведомо известной ячейке - носкуль будет быстрее. Так как практически все они работают с адресным доступом к данным.

Насчет сохранности данных я хз. Мы ставим редис для динамик данных, то что надо быстро и прямо сейчас. И монго для бабла. Вполне норм и без скуля работает.

Но опять же - у нас игры. Игры не предполагают какой-то зверской аналитики и логирования. Практически все данные выгребаются по тегам или конкретному адресу. Если бы я делал учетную систему, в которой стопицот одинаковых документов. И таких типов документов тоже стопицот - я бы наверное брал скуль.
Старый 03.03.2014 03:38 in4core вне форума
in4core
 
Аватар для in4core
Цитата:
Но опять же - у нас игры. Игры не предполагают какой-то зверской аналитики и логирования. Практически все данные выгребаются по тегам или конкретному адресу. Если бы я делал учетную систему, в которой стопицот одинаковых документов. И таких типов документов тоже стопицот - я бы наверное брал скуль.
А вот это зря! Опять же у нас игры! А что еще на флеш КРУЧЕ чем игры есть?! Кто то пишет какие то зверски нагруженные приложения для общего пользования? Врядли. Игры - это уже потолок. Так, что игры по сути и являются тем звеном о котором стоит думать, все остльаное только пыль...
Старый 03.03.2014 03:53 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Сказал, как отрезал.
Старый 03.03.2014 03:53 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Только подумать забыл.
Старый 03.03.2014 10:24 PainKiller вне форума
PainKiller
 
Аватар для PainKiller
Ого, комменты за выходные появились, а я уж думал что эта тема здесь особо не интересна, все таки это не по тематике форума.
Старый 03.03.2014 13:59 in4core вне форума
in4core
 
Аватар для in4core
Dukobpa3 Тут правда вопрос, кто именно из нас двоих. Ибо ответа то от тебя нет, что кроме игр делают на флеше с *зверской аналитики и логирования* - обсмеяться.
Старый 03.03.2014 17:55 gloomyBrain вне форума
gloomyBrain
 
Аватар для gloomyBrain
Цитата:
Игры не предполагают какой-то зверской аналитики и логирования.
Не согласен. По крайней мере в моем идеальном мире прежде чем вводить что-то новое в игру (или удалять старое, или вообще что-то менять), необходимо скрупулезно изучить поведение пользователей (A/B-тестирование, анализ динамики поведения в ответ на изменения в игре). И вот тут действительно нужно работать с очень, прям Очень большим количеством данных за некоторый промежуток времени.

Кстати, Dukobpa3, если не секрет - чем вызван выбор MongoDB для платежей? Неужто postgres (ну или что там?) не выдерживает напора? Не верю! =)
Старый 03.03.2014 18:18 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Цитата:
в моем идеальном мире прежде чем вводить что-то новое в игру
Всё верно. Только на текущем месте у нас этим занимается отдельно стоящий хадуп. Это не относится к игровой логике никоим образом.

Цитата:
чем вызван выбор MongoDB для платежей? Неужто postgres (ну или что там?) не выдерживает напора?
Я же не ставил монго как пример производительности для денег.
Просто взяли такой же носкуль на котором всё остальное крутится. Но в отличии от редиса - монго на диске. А редис в памяти с возможностью дампов. Вот и свесь выбор. Монго я упоминал как аргумент к заявлению тигры: "для денег носкуль не стал бы использовать из-за надежности". Всё норм там с надежностью. Не было никаких коллизий.
Старый 03.03.2014 20:02 gloomyBrain вне форума
gloomyBrain
 
Аватар для gloomyBrain
Цитата:
Всё верно. Только на текущем месте у нас этим занимается отдельно стоящий хадуп. Это не относится к игровой логике никоим образом.
Итого, сжато, наш с Вами диалог:
D: в играх нет анализа большого количества данных
g: Не согласен. Есть.
D: Все верно. Но это не относится к игровой логике

Цитата:
Просто взяли такой же носкуль на котором всё остальное крутится.
Прикольно, молодцы что экспериментируете =) Правда, честно скажу, что платежи - это последнее где я бы стал вводить что-то новое =)
Старый 03.03.2014 20:02 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
Цитата:
Всё норм там с надежностью. Не было никаких коллизий.
Ну, например
Цитата:
Write failure
MongoDB allows very fast writes and updates by default. The tradeoff is that you are not explicitly notified of failures. By default most drivers do asynchronous, ‘unsafe’ writes - this means that the driver does not return an error directly, similar to INSERT DELAYED with MySQL. If you want to know if something succeeded, you have to manually check for errors using getLastError.
Резюмируя, если что-то пойдёт не так – никто не узнает, что что-то пошло не так. Решая проблему безопасности записи уменьшается потенциальная скорость записи (там далее по тексту). Смею предположить, что безопасная монга куда тормозней, чем, например, мускул.
Старый 03.03.2014 22:48 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Цитата:
Итого, сжато, наш с Вами диалог:
Итого каждый понял как хотел.
Я сказал что аналитика - отдельный инструмент с отдельной базой. К самому конкретному проекту мало относится. И для этого есть специально обученные инструменты типа хадупа или как минимум гуглоаналитикса, которые умеют это делать хорошо.

Цитата:
безопасная монга куда тормозней, чем, например, мускул.
В плане платежей я конечно хз, может это только я отстал и в таких печальных проектах участие принимал, но, по опыту(да и по логике) - это самая ненагруженная часть всего проекта.

З.Ы.
Цитата:
Ну, например
Ссылочка 2012 года....
Старый 03.03.2014 23:38 gloomyBrain вне форума
gloomyBrain
 
Аватар для gloomyBrain
Цитата:
Я сказал что аналитика - отдельный инструмент с отдельной базой. К самому конкретному проекту мало относится.
Ну как же так? Я серьезно! Что же вы анализируете в конечном итоге?

Могу рассказать как вижу анализ со своей стороны:
1) - анализ изменений
2) - анализ состояний

То есть фактически у нас есть 2 БД, одна хранить только "события", вторая хранит только данные.

Вот та, что хранит данные - это прям настоящая боевая БД, где лежат все данные юзеров. И мы таки прогоняем по ней наши аналитические скрипты и знаем все, что сейчас творится в игровом мире среднего (и/или каждого) пользователя. Кстати, там же (и так же, с использованием скриптов и критериев) можем что-то менять для каждого пользователя.
Та БД, что хранит события - хранит их за некий отчетный период, за который отслеживается поведение пользователей в ответ на поведение гейм-дизайнеров. Мы им А, они нам Б. Все просто.

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

PS
В описанной мной схеме No-SQL хранилища не используются. Иногда коенчно хочется, но все равно пришли к выводу что универсальностью и скоростью доступа можно пожертвовать в угоду надежности и отказоустойчивости. Хотя я вполне допускаю что через некоторое время мы будем использовать redis/mongo для ускорения прогона анализирующих скриптов по БД.
Старый 03.03.2014 23:52 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Теперь понял в чем непонимание получилось.

Реальные даннные тоже анализировали, но на производительности аналитики не заморачивались.
Там вплоть до того что запустил скрипт на ночь. С ограничениями, чтоб не сильно влияло на работу пользователей, а то если в полную силу выборку и сортировку с группировками запустить то пользователи будут лагать. А потом утром результаты.

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

Изначально я имел в виду вариант в котором клиент просто что-то отправляет на сервер статистики.
Почему не учел анализ боевой базы вроде понятно выше описал.
Старый 06.03.2014 14:45 PainKiller вне форума
PainKiller
 
Аватар для PainKiller
Удалил замечание про медленную тех. поддержку jelastic - недавно пришлось с ней пообщаться, отвечают быстро и вежливо, так что это скорее плюс.
Старый 12.03.2014 19:54 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Сижу вот, пилю сервер на java с MySQL.
Код не мой, просто пару плюшек прикрутить надо.
База пестрит конвертацией скуля в носкуль путем запихивания в стринговые поля жсон-строк.
Ненуаче, норм решение. Предварительно подумать о том что в игре 90% данных имеют документную структуру - не срослось. Адекватная сериализация-десериализация в табличный вид тоже долго и дорого для базы, потому что один юзерсейв это строк 10-50 в базе на каждого пользователя.

Вот таким вот путем чуваки пошли. И спрашивается зачем? Я не думаю что они со скуля в этом проекте сильно много профита поимели.
Старый 13.03.2014 10:47 PainKiller вне форума
PainKiller
 
Аватар для PainKiller
Цитата:
База пестрит конвертацией скуля в носкуль путем запихивания в стринговые поля жсон-строк.
Это кстати нормальное решение для пхпшников. У меня в отделе сидит пхпшник с 10 летним стажем работы, и он мне так и говорит NoSQL нахрен не нужен, можно хранить JSON в MySQL. Но наверное это все таки медленнее будет чем нормальный NoSQL
Старый 13.03.2014 10:53 PainKiller вне форума
PainKiller
 
Аватар для PainKiller
С другой стороны иногда это может быть спасительным костылем. У меня "висит" один проект - мобильное эйр приложение, данные в него приходят с сервера в JSON, и их много и они обновляются, возникла проблема как их кешировать. Т.к. это JSON проще и логичнее было бы хранить их в NoSQL но на андроиде с этим проблема, а тянуть с собой couchDB стремно. Поэтому решать я её видимо буду именно таким образом, хранить JSON в SQLite
Старый 13.03.2014 16:11 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Ну так и носкуль 10 лет назад и сейчас это разный носкуль.
10 лет назад я бы с твоим пхпшником согласился. А сейчас появились другие инструменты. Это всё-равно что писать код в блокноте при том что есть куча ИДЕ. Ну просто потому что привык и 10 лет писал в блокноте. Не заметил что можно иначе.
Старый 18.03.2014 16:38 Babylon вне форума
Babylon
 
Аватар для Babylon
NoSQL избыточен, но подходит для разнородных данных коротких таблиц. Ваш PHP дока прав JSON можно и нужно поднимать из SQL баз и туда же их серилизовать. JSON удобнее и компактнее XML. Единственное неудобство для меня. что сложно писать прототипы структур данных. Возможно просто не привык. Тем не менее написал ArrayToJSON
Старый 18.03.2014 16:50 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Цитата:
сложно писать прототипы структур данных.
Код AS3:
//*****************
class Struct {
 
  var first:int;
  var second:String;
  var third:Array;
}
 
//*****************
var struct:Struct = new Struct();
struct.first = 1;
struct.second = "second";
struct.third = [1, 1.1, "1"];
 
var encoded:String = JSON.stringify(struct);
Сложно, да.
Старый 18.03.2014 18:32 Babylon вне форума
Babylon
 
Аватар для Babylon
Позабавил. Так их пишет наверно еще in4core :)
Старый 18.03.2014 21:46 alexcon314 вне форума
alexcon314
Цитата:
NoSQL избыточен, но подходит для разнородных данных коротких таблиц.
Это мнение тянет на уровень эксперта. По сему вопрос: в чем избыточность и почему не подходит для однородных больших таблиц?
Только не надо кидаться пруфами.
Цитата:
Так их пишет наверно еще in4core
И не надо нам тут стеба с замером МПХ. Следите за выражениями. Покажите как пишете вы, если есть, что показать и хотите обсудить это прилюдно. Плюс за флуд.
Обновил(-а) alexcon314 19.03.2014 в 00:09
 

 


Часовой пояс GMT +4, время: 23:29.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2020, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.