Хороший подход, согласен с ним, но например если находишься в путешествии или в чужой стране, то покупать каждый раз транспорт может выйти крайне накладно.
Эх, жаль не смогу побывать на митапе. Сам недавно сделал такой же переход fullstack -> DE. С автором соглашусь, что действительно начинаешь смотреть на дизайн бекенда с другой стороны, ну и сразу учишься проектировать бд и внутренние структуру микросервисов с оглядкой на то, как это будет использовано в ETL/BI.
Что использовали в качестве сервера приложений, на чем писалась логика, какие хранилища использовали? Какой онлайн держит ваш кластер? Хотелось бы это услышать
Извиняюсь, немного вас обманул, была она в конце прошлого года — https://c-user-group-russia.timepad.ru/event/262787/.
А по поводу того, что не можете найти контакты с сообществом — тут все просто. Как такого сообщества нет. Есть несколько компаний на Урале, их крайне мало, которые разрабатывают на крестах. В той или иной степени все друг друга знают, но создавать комьюнити никто не собирается пока.
Причин всему этому несколько.
1) Чтобы писать на с++ в 2016 году небольшой компании (а скорее всего компания с Урала небольшая) необходимо иметь веские причины, так как разработка обычно медленная, с точки зрения бизнеса, часто неоправданная (для маленьких компаний).
2) Люди есть, но их мало. Чтобы стать хорошим с++ разработчиком нужно время и опыт, а все хотят брать на работу сразу хороших разработчиков. Т.е. новичкам проще работать с другими инструментами, где ниже порог входа, не нужен большой background. Как итог — притока людей нет, хотя бывают исключения, когда человек по неведомым причинам как то, да наработал background. А вот отток есть, писать на с++ приходится много и тяжело, а вот зп обычно так не растут, как например объемы работы, ну и скилл людей, поэтому частенько люди уезжают в Питер, Москву, любо заграницу.
Вообще обстановка по с++ на Урале, по крайней мере с мой точки зрения, выглядит так. В Челябинске на крестах пишут:
Интересная статья. Хотелось бы больше статей на тему архитектуры серверных решений для гейм дева.
Интересно было бы узнать про коммуникацию узлов между собой: как узнают друг о друге, как происходит балансировка нагрузки. Вообще хотелось бы побольше узнать про изнанку BigWorld.
Есть мнение, что реалтаймовые игры будут трендом нескольких ближайших лет. Т.е. топ гроссинг будут покорять игры, требовательные к хорошей модели синхронизации клиент-сервера (Шутеры, RTS, ...). Причем стоит ожидать их не только от крупных компаний, но и от небольших компаний-разработчиков игр, от инди разработчиков в том числе. Сейчас самое дешевое решение — использовать синхронизацию типа мастер-клиент в связке с каким-нибудь облачным решением вроде Unity Photon. Что собственно и делают маленькие студии. У такого решения есть недостатки, учитывая, что часто реал-тайм игры — соревновательные игры, требовательные к наличию авторитарной стороны.
По сути для студии, которая решит выпускать подобные игры будет несколько путей: покупка лицензии на готовый движок (например BigWorld), либо разработка своего решения. Вот тут самое интересное, ведь для того, чтобы начать работать с большим закрытым движком требуется время, да и куча денег, которых часто у студий нет. В итоге они начинают делать свои решения.
Я как раз работаю в одной из таких студий. Правда у них в свое время получилось наработать неплохую кодовую серверную базу, которая покрывает пока что все потребности, но это ненадолго. Понятно, что в процессе жизни студии принимались решения, позволяющие дешево добиваться цели, в итоге получился монолитный C++ сервер, работающий на мощных железках. Из плюсов: весь онлайн (относительно WoT мизерный) можно обслуживать в одном сервере, все работает шустро и оптимизировано. Из минусов: никакого масштабирования, вся бизнес-логика на C++ (с трудом можно найти толковых спецов, а даже если найдешь, то они будут долго пилить свои задачи).
Мне кажется можно сформировать какой то пул best practice, или может даже доступных для многих решений, которыми смогут пользоваться разработчики.
Извиняюсь за оффтоп, но как давно вы используете CLion? С удовольствием использую IDE от Jetbrains для Java и Ruby. Есть огромное желание использовать CLion для работы, но без удаленной сборки и дебага это просто нереально. Приходится работать с NetBeans. Как вы решили эту проблему?
Да, я как раз об этом и говорю, что при большом количестве запросов будет срабатывать метод async_accept, при этом он сразу же будет вызывать s.async_write, и мы будем терять сигналы-обработчики. Клиенты будут просто висеть на подключении и не получат файл политики.
Насчет Boost.Asio возможно, надо поглядеть. Как вернусь из поездки сразу гляну.
В libev есть асинхронный вызов async. Вопрос в том, что произойдет, если будет много одновременных запросов? Нам в любом случае надо аггрегировать клиентов, и ни в коем случае не терять их. Причем в документации даже написано, что очереди в async никакой нет, поэтому делать ее самим — ссылка.
Да, вы правы, использовать nginx c модулем — неплохое решение. В свое время, когда встретился с задачей не особо над этим задумывался и написал свое решение за 30 минут на Java+Netty. Позже поделился с коллегами из других студий. Они попросили сделать демон на C++.
Плюс, по первой ссылке в гугле народ ругается на модуль для nginx.
1. Необходим менеджмент очереди, т.е. если использовать только libev, то надо писать какой то балансировщик который правильно распределит между обработчиками нагрузку. Использование же блокирующей очереди является вполне классическим решением для подобной задачи.
2. Да nginx можно использовать, об этом написали в комментарии ниже.
По-поводу тестов, делал несколько замеров тем, что есть. Цифры выложил те, которые получились, безусловно есть вероятность, что где то может быть косяк.
Хороший подход, согласен с ним, но например если находишься в путешествии или в чужой стране, то покупать каждый раз транспорт может выйти крайне накладно.
А по поводу того, что не можете найти контакты с сообществом — тут все просто. Как такого сообщества нет. Есть несколько компаний на Урале, их крайне мало, которые разрабатывают на крестах. В той или иной степени все друг друга знают, но создавать комьюнити никто не собирается пока.
Причин всему этому несколько.
1) Чтобы писать на с++ в 2016 году небольшой компании (а скорее всего компания с Урала небольшая) необходимо иметь веские причины, так как разработка обычно медленная, с точки зрения бизнеса, часто неоправданная (для маленьких компаний).
2) Люди есть, но их мало. Чтобы стать хорошим с++ разработчиком нужно время и опыт, а все хотят брать на работу сразу хороших разработчиков. Т.е. новичкам проще работать с другими инструментами, где ниже порог входа, не нужен большой background. Как итог — притока людей нет, хотя бывают исключения, когда человек по неведомым причинам как то, да наработал background. А вот отток есть, писать на с++ приходится много и тяжело, а вот зп обычно так не растут, как например объемы работы, ну и скилл людей, поэтому частенько люди уезжают в Питер, Москву, любо заграницу.
Вообще обстановка по с++ на Урале, по крайней мере с мой точки зрения, выглядит так. В Челябинске на крестах пишут:
Есть в Екатеринбурге компании, хотя про него меньше знаю:
Интересно было бы узнать про коммуникацию узлов между собой: как узнают друг о друге, как происходит балансировка нагрузки. Вообще хотелось бы побольше узнать про изнанку BigWorld.
Есть мнение, что реалтаймовые игры будут трендом нескольких ближайших лет. Т.е. топ гроссинг будут покорять игры, требовательные к хорошей модели синхронизации клиент-сервера (Шутеры, RTS, ...). Причем стоит ожидать их не только от крупных компаний, но и от небольших компаний-разработчиков игр, от инди разработчиков в том числе. Сейчас самое дешевое решение — использовать синхронизацию типа мастер-клиент в связке с каким-нибудь облачным решением вроде Unity Photon. Что собственно и делают маленькие студии. У такого решения есть недостатки, учитывая, что часто реал-тайм игры — соревновательные игры, требовательные к наличию авторитарной стороны.
По сути для студии, которая решит выпускать подобные игры будет несколько путей: покупка лицензии на готовый движок (например BigWorld), либо разработка своего решения. Вот тут самое интересное, ведь для того, чтобы начать работать с большим закрытым движком требуется время, да и куча денег, которых часто у студий нет. В итоге они начинают делать свои решения.
Я как раз работаю в одной из таких студий. Правда у них в свое время получилось наработать неплохую кодовую серверную базу, которая покрывает пока что все потребности, но это ненадолго. Понятно, что в процессе жизни студии принимались решения, позволяющие дешево добиваться цели, в итоге получился монолитный C++ сервер, работающий на мощных железках. Из плюсов: весь онлайн (относительно WoT мизерный) можно обслуживать в одном сервере, все работает шустро и оптимизировано. Из минусов: никакого масштабирования, вся бизнес-логика на C++ (с трудом можно найти толковых спецов, а даже если найдешь, то они будут долго пилить свои задачи).
Мне кажется можно сформировать какой то пул best practice, или может даже доступных для многих решений, которыми смогут пользоваться разработчики.
Насчет Boost.Asio возможно, надо поглядеть. Как вернусь из поездки сразу гляну.
Плюс, по первой ссылке в гугле народ ругается на модуль для nginx.
2. Да nginx можно использовать, об этом написали в комментарии ниже.
По-поводу тестов, делал несколько замеров тем, что есть. Цифры выложил те, которые получились, безусловно есть вероятность, что где то может быть косяк.