Давайте обсуждать.
Мне кажется, что в нонешнем году нужно обеспечить следующие возможности:
1. работа с БД, миграции
2. http-сервер и клиент, socket-сервер и бинарный протокол
3. in-memory БД для кэшей и конфигов
4. общение между узлами серверов
5. мониторинг нагрузки и мб сбор статистики
6. внутренние задачи по расписанию
7. тесты
8. деплой и обновление отдельных подсистем
Здравствуйте, neFormal, Вы писали:
F>Давайте обсуждать. F>Мне кажется, что в нонешнем году нужно обеспечить следующие возможности:
F>1. работа с БД, миграции
Spring, Liquibase
F>2. http-сервер и клиент, socket-сервер и бинарный протокол
Spring при помощи Jetty, Netty, Tomcat etc
F>3. in-memory БД для кэшей и конфигов F>4. общение между узлами серверов
Мало конкретики.
F>5. мониторинг нагрузки и мб сбор статистики
Jmx, Actuator
F>6. внутренние задачи по расписанию
Spring
F>7. тесты
Junut, Selenium, Jmeter
F>8. деплой и обновление отдельных подсистем
Docker, Jenkins
F>На чём это получается лучше всего?
Здравствуйте, GarryIV, Вы писали:
F>>1. работа с БД, миграции GIV>Spring, Liquibase
не, ну всё понятно. но зачем в 2017м году использовать Spring?
F>>2. http-сервер и клиент, socket-сервер и бинарный протокол GIV>Spring при помощи Jetty, Netty, Tomcat etc
да, неплохая связка. netty много чего поддерживает.
правда, некоторые вещи уже многие годы сделаны не очень. например, protobuf через netty использовать неудобно.
F>>3. in-memory БД для кэшей и конфигов F>>4. общение между узлами серверов GIV>Мало конкретики.
3. чтобы не лезть каждый раз в базу, объекты хранят в кэше.
многие жявщики зачастую делают самописный кэш. остальные используют h2/redis/чтотоещё
4. если действия юзеров между собой связаны, если мир общий, то будут существовать какие-то объекты, которые находятся физически на другой железке.
и к этим объектам нужен удобный доступ с других железок.
для сервисов а ля "веб-приложение без общего состояния" это не критично.
F>>5. мониторинг нагрузки и мб сбор статистики GIV>Jmx, Actuator
любопытно, спасибо. jmx не доводилось трогать.
что с ним можно снять с запущенной системы?
F>>На чём это получается лучше всего? GIV>У меня все это лучше всего на java получается.
как это всё масштабировать в случае типичного "убийцы WoW"?
Здравствуйте, neFormal, Вы писали:
F>>>1. работа с БД, миграции GIV>>Spring, Liquibase
F>не, ну всё понятно. но зачем в 2017м году использовать Spring?
Потому что удобно.
F>>>2. http-сервер и клиент, socket-сервер и бинарный протокол GIV>>Spring при помощи Jetty, Netty, Tomcat etc
F>да, неплохая связка. netty много чего поддерживает. F>правда, некоторые вещи уже многие годы сделаны не очень. например, protobuf через netty использовать неудобно.
F>>>3. in-memory БД для кэшей и конфигов F>>>4. общение между узлами серверов GIV>>Мало конкретики.
F>3. чтобы не лезть каждый раз в базу, объекты хранят в кэше. F>многие жявщики зачастую делают самописный кэш. остальные используют h2/redis/чтотоещё
Это не конкретика. Конкретика это количество элементов, размер, количество нод и все такое прочее. Впрочем пусть будет redis, можно так же ehcache, hazelcast, memcached, caffeine etc.
F>4. если действия юзеров между собой связаны, если мир общий, то будут существовать какие-то объекты, которые находятся физически на другой железке. F>и к этим объектам нужен удобный доступ с других железок. F>для сервисов а ля "веб-приложение без общего состояния" это не критично.
"веб-приложение без общего состояния" это миф, как единороги.
F>>>5. мониторинг нагрузки и мб сбор статистики GIV>>Jmx, Actuator
F>любопытно, спасибо. jmx не доводилось трогать. F>что с ним можно снять с запущенной системы?
Jmx это спека, снять обычно можно все про jvm плюс что там дополнительно зарегали (для мониторинга нетти например).
F>>>На чём это получается лучше всего? GIV>>У меня все это лучше всего на java получается.
F>как это всё масштабировать в случае типичного "убийцы WoW"?
Как маштабировать сферического коня в вакууме? Горизонтально! Запустим наши докеры в ecs пусть оно само маштабирует.
Здравствуйте, GarryIV, Вы писали:
F>>3. чтобы не лезть каждый раз в базу, объекты хранят в кэше. F>>многие жявщики зачастую делают самописный кэш. остальные используют h2/redis/чтотоещё GIV>Это не конкретика. Конкретика это количество элементов, размер, количество нод и все такое прочее. Впрочем пусть будет redis, можно так же ehcache, hazelcast, memcached, caffeine etc.
50+ нод, общая система конфигов типа etcd(только желательно типизированная), сотни тысяч элементов, размер до 1.5кБ.
F>>4. если действия юзеров между собой связаны, если мир общий, то будут существовать какие-то объекты, которые находятся физически на другой железке. F>>и к этим объектам нужен удобный доступ с других железок. F>>для сервисов а ля "веб-приложение без общего состояния" это не критично. GIV>"веб-приложение без общего состояния" это миф, как единороги.
похоже на деформацию в сторону микросервисов.
а веб без общего состояния существует. всё зависит от задач.
F>>как это всё масштабировать в случае типичного "убийцы WoW"? GIV>Как маштабировать сферического коня в вакууме? Горизонтально! Запустим наши докеры в ecs пусть оно само маштабирует.
Здравствуйте, neFormal, Вы писали:
F>На чём это получается лучше всего?
Именно в десктоповых играх лидером является C++, это и клиент, и сервер. Скрипты к нему прикручивают на Lua, лучшего пока что тоже не придумали. Если поставить GNU/Linux, тот же Debian, то настройка мониторинга нагрузки операционной системы и баз данных грамотному админу не составит труда, для каждой задачи уже есть готовые программы.
Или что такое внутренние задачи по расписанию? Если внутри приложения, то программистам игры виднее. А если что-то в общем плане, то можно взять тот же cron. Если нужна клиент-серверная база данных, которая может работать в кластере, кэшироваться в оперативной памяти и тому подобное, то можно рассмотреть Postgres.
Управление конфигурациями, ну например, ansible. Конечно, если бы эта тема лежала в другом разделе, то всё написанное здесь мною можно забыть. Опять же выше упомянули систему непрерывной интеграции Jenkins для разработки программ о которой лучше бы периодически посматривать в гугле на предмет уязвимостей и критических в том числе.
Здравствуйте, velkin, Вы писали:
F>>На чём это получается лучше всего? V>Именно в десктоповых играх лидером является C++, это и клиент, и сервер. Скрипты к нему прикручивают на Lua, лучшего пока что тоже не придумали. Если поставить GNU/Linux, тот же Debian, то настройка мониторинга нагрузки операционной системы и баз данных грамотному админу не составит труда, для каждой задачи уже есть готовые программы.
бэкендики пишут на чём угодно, кроме плюсов.
не, я знаю одну контору, где как раз плюсы с луа, но это не ориентир для остальных.
V>Или что такое внутренние задачи по расписанию? Если внутри приложения, то программистам игры виднее. А если что-то в общем плане, то можно взять тот же cron.
а чем "внутри приложения" отличается от "в общем плане"?
крон снаружи неудобен. его поддерживать утомительно.
V>Если нужна клиент-серверная база данных, которая может работать в кластере, кэшироваться в оперативной памяти и тому подобное, то можно рассмотреть Postgres.
да, альтернатив всё равно не густо.
V>Управление конфигурациями, ну например, ansible. Конечно, если бы эта тема лежала в другом разделе, то всё написанное здесь мною можно забыть. Опять же выше упомянули систему непрерывной интеграции Jenkins для разработки программ о которой лучше бы периодически посматривать в гугле на предмет уязвимостей и критических в том числе.
ну, если она наружу не торчит, то нехай хоть решетом будет.
Здравствуйте, velkin, Вы писали:
V>Именно в десктоповых играх лидером является C++, это и клиент, и сервер. Скрипты к нему прикручивают на Lua, лучшего пока что тоже не придумали. Если поставить GNU/Linux, тот же Debian, то настройка мониторинга нагрузки операционной системы и баз данных грамотному админу не составит труда, для каждой задачи уже есть готовые программы.
Нет, не для бэкенда игр. Кроме того, лучше сделанный бэкенд, чем идеальный и незаконченный
V>Или что такое внутренние задачи по расписанию? Если внутри приложения, то программистам игры виднее. А если что-то в общем плане, то можно взять тот же cron. Если нужна клиент-серверная база данных, которая может работать в кластере, кэшироваться в оперативной памяти и тому подобное, то можно рассмотреть Postgres.
V>Управление конфигурациями, ну например, ansible. Конечно, если бы эта тема лежала в другом разделе, то всё написанное здесь мною можно забыть. Опять же выше упомянули систему непрерывной интеграции Jenkins для разработки программ о которой лучше бы периодически посматривать в гугле на предмет уязвимостей и критических в том числе.
