От 0 до 200 000 000 игроков - об эволюции бэкенда за 40 мин / Андрей Михеев (Pixonic)

[@sergeiostrovskiy3828]

По привью подумал что это с канал диджитализируй Но доклад хорош

[@igorm.9845]

Было интересно, отличный доклад, спасибо!

[@FDsagizi]

Спасибо, полезно про выключатели фичь, удаление кода. Остальное приятная вода😁

[@maximvorobyev3041]

Вполне адекватный доклад и докладчик, мало тех информации - которую я люблю, но всё равно спасибо

[@shvez]

Очень хорошо знаю фотон. Довольно странно слышать про проблемы многопоточности в системе, которая на сквозь многопоточна. Было бы интересно узнать про действительные проблемы. А не общие фразы. Есть тайтлы, которые имеют до 1 000 000 CCU (одновременно играющих игроков) и всё у них хорошо и с многопоточностью и Матч мэйкингом. Плюс заявление, что нельзя писать серверный код, тоже не соответствует действительности. Можно использовать плагины в своём облаке. Другой вопрос, что вам это не подошло. Ну так так и надо говорить.

[@BumatuHe]

Архитектор для архитекторов! Кайф!

[@P7Vagrant]

Жаль что не ответил на первый вопрос про выключатель фич. Тоже считаю что есть проблема с тестированием самих фич, если приходится прибегать к таким мерам.

[@elcolex777]

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

[@P7Vagrant]

@@elcolex777 при таком подходе, тестирование, фактически происходит на бою и проблема тестирования переносится на бой) А при отключении функционала, бизнес несёт убытки, так что, вряд ли такой подход можно назвать хорошим)

[@elcolex777]

@@P7Vagrant не, ну само собой совсем без тестирования не обойтись) я к тому что возможность выключения функционала онлайн добавляет гибкости. Какое бы тестирование не проводилось все равно будут баги на проде. А вот если у нас есть возможность быстро отключить функционал без передеплоя - ведь круто же? Иногда должна быть возможность быстро выключить фичу или наоборот включить. Это развязывает руки - можно задеплоить приложение в любое время и включить когда надо (по отмашке от бизнеса).

[@nurikn2537]

Не особо полезный доклад получился. На тег "я пиарюсь" - годится. Смущает наличие схем с деталями и технологиями, но при этом отсутствует описание нагрузки по сервисам. Миграция данных сама по себе сложная штука, но слайд запилить можно было бы простой для примера. Поэтому вопрос был вполне валидный .Еще смутило что в финальной схеме была упомянута kafka, и там же grpc. Но никак не сказано зачем оба нужны одновременно в схеме. А еще zookeeper. В такой схеме мне понятна ситуация его использования для исключения split brain. Но хотелось бы услышать хотя бы поверхностно про его использование в распределенной системе под нагрузкой. Доклад получился типа: "Вот какие мы молодцы - держим большую нагрузку, а про остальное мы не расскажем, потому что лень и потому что нам дали 10 мин на доклад"

[@olegprog]

первоначальная архитектура это совсем жесть какая-то, вроде же изначально понятно, что хранить все состояние на клиенте это много боли в будущем

[@SYMBAT.K.E]

очень интересно

[@radlibek]

Отличный доклад, спасибо! Но вот не понимаю, наверное это к организатором больше. Зачем устраевать вопрос ответ в конце, если все равно не получишь ответа? Как же раздражает это: ой это такой большой вопрос, давайте после доклада. Ну нельзя чтоли ответить хотя бы коротко. Если видно что тянется или нет уже времени перебить и попросить дальше после доклада. Или если не знаете что ответить так и скажите, это нормально.

[@HarryHoudiny]

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

[@PurpleDaemon_]

Уверен, что уже слышал этот доклад, но от другого человека

[@ilyapro4991]

какие-то классические грабли :)

[@goodwaysarts]

подбомбануло конечно про ред панду)) интересно с чего у них вообще должен был стоять выбор между кафкой и ред пандой. Ред панда малоизвестный продукт, мало где используется на продакшене если брать общую статистику

[@NikitaVelikanin]

поэтому я не люблю rust разработчиков kzbin.info/www/bejne/h4C4maiklquAhbs

[@denwerxampp4035]

свидетели rust'а ))

[@aiwprton805]

Только не говорите ему, что Redpanda на C++ написана, а то уйдёт писать ещё одну кафку на расте. Нужно же что-то делать с производительностью, C++ - это не дело! И касандру заодно на ерланге перепишем, выпустим под проприетарной лицензией, предоставим платную подписку в собственном облаке и на конференциях будем спрашивать почему вы её не используете?

[@HideDJeker]

Линейная масштабируемость касандры это при consistency level one ? (hehe classic) Если сильно хочется транзакции над касандрой можно посмотреть доклад одноклассников про C*One, типа надстройка над касандрой для acid. Конечно было бы очень интересно посмотреть архитектуру подробнее, далекому от геймдева мне очень сложно представить как касандру используют для подобного

[@Tom910ru]

Допустим если consistency level 3 и локал кворум на чтение и запись. В чем возникают проблемы в этой схеме?

[@2korzhik]

Какой то капитанский доклад. Банальщина в перемешку с бесполезной инфой. Что дала слушателям информация о том что в пятой версии вашей архитектуры появилась кафка?

[@millkiway3682]

Не согласен. Доклад очень жизненный без выебонов про микросервисы и ошуенность.

[@anatoly-k]

ни о чём