Стажёры Riot: Часть 2

Программа стажировки Riot помогает студентам технических специальностей получать профессиональные навыки. Стажёры работают и учатся в командах разработки, участвуют в значимых проектах и используют интересные технологии. Это продолжение статьи о стажировках 2020.

Стажёры Riot: Часть 2

Во второй части мы расскажем не о конкретных играх, а о работах с технологиями и инструментами, используемыми в Riot:

ОБЩИЕ ТЕХНОЛОГИИ

СИЛЬВИЯ ХУА

Роль: разработчик программного обеспечения
Команда коммерции

Привет, я Сильвия «Hide on Peanut» Хуа. Я изучаю информационные технологии в Политехническом институте Ренсселера. Этим летом я присоединилась к команде коммерции в качестве стажёра-разработчика. Команда коммерции разрабатывает инструменты, позволяющие игрокам покупать виртуальную валюту: RP, Coins и VALORANT Points.

Я сосредоточилась на улучшении UI и UX. Целью проекта было заинтересовать игроков в процессе покупки и обеспечить понятный визуальный язык. Очень важно, чтобы решения о покупке были простыми, и игроки точно знали, что они покупают. Я занималась улучшением покупки RP и интеграцией с API других команд на бэкенде

ЯСНОСТЬ ПОКУПАЕМОГО КОЛИЧЕСТВА

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

Для начала мне нужно было выяснить, где хранятся данные о виртуальной валюте. Ими управляет платформа доступа к контенту, и я получила API для доступа. Далее мне нужно было разработать вызов API на нашем бэкенде, передать значение на фронтенд и отобразить элементы на странице покупки. Сложность была в том, что для каждой игры и виртуальной валюты нужно было обращаться к разным URL и использовать уникальный ключ авторизации. Сейчас у нас много игр (а в будущем будет ещё больше), поэтому нужно сделать масштабируемую и настраиваемую систему. Для хранения всех свойств приложения я использовала JSON-файл. Фреймворк Spring может напрямую применить файл JSON к объектам в Java, что упрощает управление конфигурацией. Когда на бэкенде все готово, фронтенд получает данные о балансе игрока.

Это лето с Riot было очень весёлым и я наслаждалась каждой минутой работы с командой. Все были доброжелательны и оказывали поддержку. Я также пообщалась с работниками Riot из других команд и узнала о разных проектах. Я очень благодарна за возможность сотрудничать с Riot. Это было незабываемое лето.

КУМИЛ НАДЖИБ

Роль: разработчик программного обеспечения
Команда гильдии торговцев – рынок

Привет! Я Кумил «Eluminated» Наджиб. Летом я был стажёром-разработчиком ПО в команде гильдии торговцев Riot на платформе магазина. Мы занимались технической реализацией вещей, которые можно заработать или купить в League, TFT и мобильном приложении TFT. Этим летом я помогал создавать базу для применения купонов к покупкам в магазинах и сервис, который находит эти купоны в инвентаре игрока.

Команда рынка занимается той частью магазина, с которой взаимодействуют игроки. На фронтенде мы пользуемся Ember.js, а на бэкенде – в основном Java.

Моим самым масштабным проектом стало участие в разработке новых возможностей магазина.

Давайте по порядку. Когда игрок размещает заказ, фронтенд обращается к API на бэкенде, который управляет покупками. Потом вызывается сервис Merchant Dispatcher, который обрабатывает заказ. Merchant Dispatcher отвечает за то, какие «Торговцы» (держатели товара) выполнят заказ. На этом этапе игроки получают предложения по своим заказам.

Стажёры Riot: Часть 2

Здесь начиналась моя работа. Мне было поручено добавить возможность применять купоны к заказам, поступающим на бэкенд. В основном это было доказательством работоспособности этой идеи. Сервисы в основном написаны на Java с фреймворком Hermes. Я добавил классы, отвечающие за применение купона. Когда поступал заказ с новым полем для ID соответствующего купона, его можно было использовать для отдельных предложений в рамках заказа.

Также нужно было отслеживать наличие купонов у игрока. Я использовал небольшой сервис Hazelcast на Java и несколько эндпойнтов, на которых отслеживалось состояние инвентаря. Этот сервис проверял наличие купонов, историю покупок, историю купонов, получение и удаление купонов. Никакого кода и базы для этой работы ещё не было, поэтому я получил отличную возможность применить свои знания на практике и с нуля создать полноценный проект!

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

КЕН ЛЮ

Роль: разработчик программного обеспечения
Команда центра доступа к контенту

Привет! Я Кен «Chocoduk» Лю, изучаю информационные технологии в Мичиганском университете. Я проходил стажировку в качестве разработчика в команде доступа к контенту, которая отвечает за инфраструктуру покупок предметов: обликов, чемпионов и боевых пропусков.

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

Основной технологией проекта был сервис под названием New Relic Synthetics. Это платформа для синтетического мониторинга сервисов. Синтетический мониторинг – это вид тестирования, при котором разработчики симулируют действия игрока в реальном времени, чтобы получить наиболее полное представление о доступности или задержке. В случае ошибок он быстро отправлял ответ. Я написал скрипт для своего проекта, чтобы протестировать функционал API заказов и возвратов на узле доступа к контенту с позиции игрока. Также я создал инструмент мониторинга на New Relic. New Relic тоже хранит данные о каждой проверке, и я настроил запросы, чтобы получать статистику об успешных операциях и задержке и отправлять ее на нашу внутреннюю аналитическую платформу.

Интерфейс New Relic со статистикой доступности задержки
Интерфейс New Relic со статистикой доступности задержки

Самым сложным в проекте было переписать скрипт, чтобы внедрить Riot Messaging Service (RMS). С помощью RMS клиенты игроков получают информацию о статусе транзакции. Сначала я запрашивал только периодические обновления статуса заказа/возврата, но этот метод был менее точным. Для использования RMS мне нужно было получить RSO токен (Riot Sign On) и открыть сокет, чтобы асинхронно получать сообщения. Возникло много трудностей с получением обратного вызова и промисов javascript, потому что я хотел задействовать старый метод опроса, если RMS займет слишком много времени или не будет отвечать. Кроме того, Javascript однопоточен, но функции могут быть асинхронными, поэтому было сложно определить порядок проверок или дополнительных вызовов.

Ещё одной особенностью проекта было использование Terraform и управление инфраструктурой с помощью кода как скриптового языка. Этот интересный способ позволяет настраивать мониторинг в New Relic, каналы в Slack и т. п., используя командную строку и несколько файлов. Также я развернул скрипты Terraform на AWS, и члены команды смогли делиться состоянием инфраструктуры и удалённо вносить изменения.

Кроме того, я настроил управление аналитическими отчётами с помощью New Relic Query Language. Это особый язык запросов, похожий на SQL. Распределить запрашиваемые данные на разные элементы в зависимости от региона, сервера или игры было довольно сложно. К тому же я научился добавлять поля для данных в New Relic, чтобы в дальнейшем делать запросы и получать данные, отсутствующие в других полях.

Мне очень понравилось работать с командой над этим проектом. Работы было много, и я получил немало опыта. Я вырос как специалист, работая с командой в течение всего цикла проекта. Команда всегда поддерживала меня во всех начинаниях, и все готовы были помочь, когда возникали вопросы. А еще было интересно пообщаться с другими стажёрами и вместе поиграть в игры. Это был замечательный опыт!

КРИС БЕНСОН

Роль: разработчик программного обеспечения
Команда ИИ-ускорителя

Меня зовут Кристофер «Miss Militia» Бенсон, я студент магистратуры Университета Карнеги – Меллона. Этим летом я был стажёром-исследователем в команде ИИ-ускорителя. Это научно-исследовательский отдел, который занимается новейшими информационными технологиями.

Команда ускорителя ИИ берется за рискованные, но важные проекты, для эффективного применения которых иногда требуется несколько лет. Наша работа охватывает много областей, от разработки ИИ и процедурной генерации до генеративно-состязательных нейросетей (GAN), но в последнее время мы сосредоточились на обучении с подкреплением (RL) для создания агентов, которые играют в игры Riot на высоких уровнях. С помощью этих агентов можно тестировать наши игры и получать различные сведения: просто данные о ещё не вышедших обновлениях, балансные правки или выявление багов. Эта информация может заменить дорогие и медленно получаемые данные игровых тестов.

Мой проект был исключительно исследовательским и был посвящен игре стороннего разработчика. Я разрабатывал RL-агентов для игры NetHack, которая недавно вышла на популярной тематической платформе Gym от исследовательской лаборатории Facebook. Это очень сложный однопользовательский «рогалик». Она выглядит как ASCII-арт в терминале.

Пример геймплея Источник: <a href="https://api.dtf.ru/v2.8/redirect?to=https%3A%2F%2Farxiv.org%2Fpdf%2F2006.13760.pdf&postId=241023" rel="nofollow noreferrer noopener" target="_blank">arxiv</a>
Пример геймплея Источник: arxiv

Также я давал агентам сторонние корпусы текста, например, обширную вики по NetHack, для обучения обработке естественного языка (NLP).

Мы натренировали модель с помощью архитектуры, показанной внизу. Там была статистика игроков, весь видимый уровень и ближайшее окружение агента. Позже мы добавили возможность появления сообщения в игре и планировали в дальнейшем внедрить более продвинутые технологии NLP. Все это было пропущено через блок долгой краткосрочной памяти (long short-term memory, LSTM), с помощью которой агент хранит сведения о различных состояниях. В конце выводы LSTM пропускались через многослойный перцептрон, чтобы получить пространство действия и выбрать следующее движение.

Изначальная базовая модель Источник: <a href="https://api.dtf.ru/v2.8/redirect?to=https%3A%2F%2Farxiv.org%2Fpdf%2F2006.13760.pdf&postId=241023" rel="nofollow noreferrer noopener" target="_blank">arxiv</a>
Изначальная базовая модель Источник: arxiv

Модель была сделана с помощью Tensorflow и тренировалась на AWS с помощью разработанной нами платформы глубокого обучения с использованием Kubernetes. Мы настроили систему так, что функцию вознаграждения агента было легко менять, чтобы мотивировать различное поведение в игре: собирать золото, исследовать нижние уровни, есть пищу и т. д. Более того, мы настроили шаблоны, чтобы в дальнейшем можно было добавить дополнительные сигналы о награде и мотивировать более комплексную игру.

К сожалению, стажировка была удалённой из-за COVID. Несмотря на это, я получил замечательный опыт, работая с Riot. Я очень многому научился. В начале лета у меня было очень мало опыта с RL, но команда проделала огромную работу и помогла мне получить ценные знания и почувствовать себя частью Riot с первого дня.

ИНСТРУМЕНТЫ И ИНФРАСТРУКТУРА

ДЖАСТИН ВАН

Роль: разработчик программного обеспечения
Команда социальной инфраструктуры

Привет! Меня зовут Джастин Ван, я студент Калифорнийского университета в Беркли. Этим летом я был стажёром-разработчиком в команде социальной инфраструктуры (SI). Эта команда отвечает за многие социальные сервисы: списки друзей, текстовый чат, голосовой чат и т. д. Также SI разрабатывает новые сервисы для существующих и будущих игр.

В SI в основном используют Erlang. Это довольно нишевый язык программирования, который хорош своей универсальностью и надёжностью. Большинство людей, в том числе и я до стажировки, совсем не знакомы с Erlang. Поэтому этим летом мне пришлось много учиться. Вместо традиционного независимого учебного проекта мне удалось напрямую поработать с командой и принять участие в решении существующих и новых проблем. Ниже я расскажу про некоторые из них.

ВНУТРЕННИЙ СОЦИАЛЬНЫЙ ГРАФ

Одной из задач, над которыми я работал, было перемещение изменений внутреннего социального графа игроков Riot на аналитическую платформу. Изменения в кодовой базе были настраиваемыми и переключаемыми. Благодаря этому проекту я познакомился с командой SI и другими разработчиками Riot и узнал много нового о социальном графе и конфигурации сервисов в режиме реального времени. Помимо написания кода, я смог поучаствовать в деплое, и мои изменения прошли внутреннее тестирование и были внесены в рабочее приложение. Они действуют и сейчас. Еще я сделал инструмент для командной строки на Go, чтобы взаимодействовать с сервисом социальных графов, о котором я говорил выше. Изначально этот инструмент создавался для упрощения тестовых HTTP-запросов, но он также использовался командой поддержки для решения проблем со списком друзей и чёрными списками.

ВСПЛЫВАЮЩИЕ УВЕДОМЛЕНИЯ

Также я участвовал в разработке нового сервиса пуш-уведомлений для мобильных приложений Riot. Этот сервис служит для максимально эффективного использования пушей. Популярность мобильных игр и процесс регистрации игроков породили проблему: пользователи (пере)регистрируются после установки приложения, и повторные установки приводят к созданию дублирующих записей для одного и того же пользователя. Простым решением было бы удалять предыдущие записи после новой регистрации, но большое количество запросов перегрузило бы базу данных. Мы решили, что каждый новый пользователь будет добавляться в очередь с определенной возможностью конфигурации. Для записей в очереди запрашивалась регистрация, и при превышении верхнего порога конфигурации записи удалялись. Зависимость от конфигурации позволяет вносить изменения в уже работающий сервис: если выяснится, что мало пользователей достигают верхнего порога, возможность добавления в очередь можно снизить, чтобы уменьшить потребление ресурсов. Если количество пользователей с нескольких устройств будет в пределах нормы, можно настроить верхний предел, чтобы не удалить подлинные записи. Я был очень рад поработать над уже существующими системами и проектами, ведь такие проблемы редко встречаются где-то ещё.

ЗАКЛЮЧЕНИЕ

Помимо работы, стажёры участвовали в разных мероприятиях. Больше всего мне понравились Lunch and Learns, где мы узнали о проектах Riot от тех, кто воплощал их в жизнь. Особенно интересно было соотносить понимание проблемы со стороны игрока или фаната игры с тем, что на самом деле стоит за этими проектами. Также мне понравилось, что работники Riot всегда открыты для диалога. Это проявилось как в общении с руководителями, так и с другими сотрудниками из разных команд. Хочу отдельно поблагодарить за поддержку и доверие своего менеджера, Кайла Бёртона, и всю команду разработки SI.

УИЛЛ КИТИНГЕ

Роль: разработчик программного обеспечения
Команда Riot Developer Experience (RDX) обеспечения работоспособности

Привет! Я Уилл Китинге, изучаю информационные технологии в Политехническом институте Ренсселера. Этим летом я был стажёром-разработчиком в команде RDX обеспечения работоспособности. Эта команда облегчает создание и мониторинг сервисов для разработчиков.

Я написал сервис на Go, который берёт данные из разных надежных источников Riot для API, который определяет команды, исполнителей, продукты и репозитории, связанные с выбранным сервисом. Например, League of Legends работает на сотнях разных микросервисов. Если один из них будет работать некорректно, очень сложно будет определить функцию этого сервиса и какая команда может решить проблему.

После создания API я интегрировал сервис в Console – инструмент проверки работающих сервисов в Riot. Теперь разработчики могут найти сервис и сразу увидеть репозитории кода, команды, продукты и исполнителей, которые имеют отношение к сервису.

Чтобы установить, кому принадлежит сервис, нужно взять данные из всевозможных систем Riot. Мой сервис осуществляет поиск репозиториев в Github, проверяет артефакты деплоя, ищет в Riot Data Model GraphQL API (там содержится информация о каждом работнике и продукте в Riot) и сетевых эскизах (это файлы конфигурации, содержащие информацию о сервисах, которые могут взаимодействовать друг с другом). Каждый из этих источников информации даёт лишь небольшую часть общей картины, а мой сервис собирает всё в одном удобном и простом API.

Самой сложной частью проекта стала оптимизация. Поиск информации об обладателе сервиса требует большого количества вызовов API, многие из которых не могут исполняться параллельно. Поэтому я выбрал кэширование. Вместо того, чтобы искать сервисы по требованию, каждый сервис искался дважды в день, и результат кэшировался. Таким образом, вместо ожидания выполнения запроса по 10–20 секунд результаты почти мгновенно выгружались из кэша.

Мне очень понравилось в Riot, это был интересный и полезный опыт. Создать новый сервис от идеи до рабочего проекта – это сложно, но я многое узнал о том, как происходит деплой, конфигурация и управление сервисами в Riot. У меня бы ничего не получилось без поддержки моей команды на каждом этапе.

РОБЕРТ ТАН

Роль: разработчик программного обеспечения
Команда IT-дизайна и разработки

Привет! Я Роберт «Ragekid» Тан, студент магистратуры информационных технологий в Университете Торонто. Этим летом я был разработчиком в команде дизайна и разработки Riot. Это довольно новая команда, которая отвечает за многие внутренние продукты Riot, например, за ботов для Slack и за другие рабочие инструменты.

AMUMUBOT

Этим летом я работал над AmumuBot. Это бот для Slack, который рекомендует сотрудникам Riot каналы Slack на основе их предпочтений. Один из лучших аспектов Riot – это чувство общности. Работая из дома, мы осознали важность ментального здоровья каждого из нас. Отличный способ поднять настроение – это сообщества в Slack для сотрудников Riot со схожими интересами.

Перед тем, как написать бота, нужно было кое-что подготовить. Во-первых, нужно было сделать ETL (извлечение, преобразование, загрузку), чтобы регулярно собирать данные о каналах Slack в нашу базу данных. Далее я спроектировал и реализовал графовую базу данных (мы пользовались Neo4J), чтобы хранить связи между каналами в Slack, темами и сотрудниками Riot. На этом этапе также пришлось изменить способ хранения интересов работников. Когда все было готово, мне нужно было установить актуальные связи между темами и каналами в Slack. Из-за временных ограничений я использовал модифицированное сопоставление ключевых слов вместе с ETL. Далее мне потребовалась платформа разработки Slack (я пользовался Bolt), чтобы создать бота, отправляющего сотрудникам информацию по определенному расписанию на основании установленных связей из базы данных.

Основной сложностью была сама графовая база данных. Наша команда использует Neo4J для отображения связей между всеми типами данных в виде вершин и ребер. В итоге я сделал примерно такую базу:

Стажёры Riot: Часть 2

Рёбра обозначены стрелками, а вершины – блоками. Каждая вершина также содержит поля, где хранится релевантная информация. Теперь задача найти канал, который предположительно интересен сотруднику, сводилась к тому, чтобы найти пути от вершины "slack_channel" (канал Slack) до вершины "worker" (работник), если не учитывать направление векторов.

Над алгоритмом, с помощью которого каналы Slack ассоциировались с темами, пришлось хорошенько подумать. Изначально идея была в том, чтобы на основе регулярных выражений сделать простой поиск совпадений тем и названия/описания канала. Но этот метод не сработал, потому что короткие темы ошибочно соотносились с некоторыми описаниями каналов. Например, темы «C» или «Art» (искусство) совпадали с любыми описаниями, где есть буква «С» или слова вроде «part» (часть). Я попробовал соотносить только слова целиком, но такой способ тоже не подошел, потому что мы хотели, чтобы «Team Fight Tactics» соотносилось с «Teamfight Tactics» и т.д. Окончательный алгоритм учитывал несколько факторов, чтобы уменьшить ложноположительные и ложноотрицательные соответствия. Среди этих факторов было соотношение длины темы и длины описания, число вхождений темы в описании, а также темы из нескольких слов.

Работая над проектом, я также смог поучаствовать в создании других интересных технологий, связанных с инфраструктурой. Инфраструктура и деплой – это темы, которые почти не изучаются в университете. Чтобы развернуть бота, я просто написал YML-файл с конфигурациями и развернул их на AWS с помощью единственной команды Terraform. Еще одна интересная технология, которая применялась при развёртывании бота – AWS Lambda. Кратко говоря, она вызывает функцию, исполняет и завершает её без использования серверов. Обработчик событий вызывается HTTP-запросами, которые Slack отправляет в зависимости от различных событий. Такая конфигурация требовала минимальных усилий по развёртыванию и созданию инфраструктуры, если установить автоматический сбор данных.

МИНИ-ХАКАТОН

По итогам проекта наша команда организовала небольшой хакатон, на котором я сделал игру в стиле гасяпон (фигурки в капсулах из автомата) с персонажами League of Legends в Slack, чтобы закрепить полученные знания.

СЯСЮАНЬ ТАНЬ

Роль: разработчик программного обеспечения
Команда интеграции облачных сервисов

Привет, я Сясюань Тань, студент магистратуры в Университете Южной Калифорнии. Изучаю информационные технологии. Я стажировался в качестве разработчика ПО в команде RDX интеграции облачных сервисов. Она обеспечивает разработчикам легкий и универсальный доступ к облачным сервисам.

Облачные сервисы позволяют пользователям создавать, обновлять и удалять облачные ресурсы вроде баз данных MySQL или кластеров Kafka, указывая эти ресурсы в файле спецификации и развёртывая с помощью командной строки. Мой проект был посвящен улучшению существующих инструментов и возможности удобно загружать и настраивать базы данных MySQL. Таким образом разработчики Riot могли определить, какие схемы и каких пользователей создавать для базы данных в одном файле спецификации.

Перед проектом разработчики Riot по-разному создавали базы данных, и они могли сильно различаться в зависимости от команды. С помощью загрузочной конфигурации в виде нескольких строк YAML наш облачный сервис мог управлять созданием схем и пользователей.

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

Лето в Riot было плодотворным: создание проекта, его деплой, анализ отзывов и исправление ошибок. Мне очень понравилось, как люди в Riot помогают друг другу и развиваются вместе. Я научился не только писать программы, но и прокачал soft skills: общение с коллегами, командную работу и внимание к пользователям

АШВИН ПАТИ

Роль: разработчик программного обеспечения
Команда RDX жизненного цикла сервисов

Привет! Я Ашвин «LaG 4G LTE», учусь в магистратуре Университета Виргинии. Этим летом я стажировался в качестве разработчика в команде RDX жизненного цикла сервисов. Её главная задача – сделать развёртывание микросервисов в глобальном пространстве дата-центров Riot легче, быстрее и стабильнее.

У команды жизненного цикла есть сервис Riot’s deployment service – сборник инструментов и сервисов, которые оптимизируют процесс развёртывания микросистем в различных дата-центрах. Мой проект касался оптимизации ready checks (проверок готовности) – важной части процесса деплоя. Нужно было сделать новый микросервис и внести изменения в кодовую базу нашего сервиса развертывания. Все это в основном было написано на Golang.

Сейчас мы определяем успешное развёртывание с помощью ready checks. Эти инструменты опрашивают конкретные эндпойнты развёртываемых сервисов и выясняют, какие из них успешно запустились.

Сначала наш сервис деплоя отвечал за проверку готовности каждого сервиса-кандидата напрямую. Но этот способ может стать слишком затратным из-за многочисленных сетевых соединений между сервисами развертывания и кандидатами. Чтобы уменьшить этот фактор, мне было поручено сделать отдельный сервис проверки готовности, который будет отправлять запросы от нашего сервиса деплоя каждому развёрнутому сервису и который будет представлен в каждом дата-центре. Когда сервис делал запрос в разные дата-центры, этот запрос проксировался через соответствующий сервис проверки готовности в каждом дата-центре. Таким образом сетевая нагрузка ложилась на сервис проверки готовности, а не на сервис развёртывания, и общее число затратных сетевых соединений, за которыми надо было следить, уменьшалось. До изменения сетевые соединения выглядели так:

Стажёры Riot: Часть 2

Но с добавлением сервиса Ready Check они уже выглядели так:

Стажёры Riot: Часть 2

Так как нужно было исключить прямой контакт сервиса развертывания с межкластерным сервисом, я использовал обратный прокси-сервер. Я создал объект в Golang с соответствующим названием ReverseProxy, который отвечает за весь маршрут от клиента до точки назначения и обратно. Что интересно, обратный прокси-сервер на Golang имеет возможность расширения. В прокси можно сделать несколько промежуточных уровней, которые функционируют как методы, последовательно обрабатывающие входящий запрос. Уровни моего сервиса были довольно очевидными: один для аутентификации, другой для преобразования запроса, а последний для отслеживания ошибок. Сам прокси-сервер был связан с API на моём сервисе, поэтому любой корректный запрос к моему сервису автоматически проходил через прокси.

Во время этого проекта мне удалось напрямую поработать с сервисом деплоя Riot и внести в него изменения. Нужно было добавить новые сетевые соединения и написать код для формирования и отправки запроса к нужному сервису проверки готовности. Поскольку сервис Ready Check – это обратный прокси-сервер, сделать запрос было очень просто, и менять код для запросов было не нужно. Ведь запрос был точно таким же, как если бы его сделал сервис деплоя.

Самым сложным было архитектурное проектирование этих решений, чтобы они без проблем работали с существующей инфраструктурой Riot, а еще привыкнуть к работе с Golang. Много времени ушло на обдумывание лучшего способа решения проблемы, прототипирования разных вариантов и на понимание того, как происходит управление микросервисами в Riot. Я очень много узнал о Golang и организации сетей, и это было не зря, ведь в результате я сделал свой первый рабочий проект на Golang и он принесёт пользу.

Было нелегко, но очень интересно! Мне понравилась стажировка в Riot, и немалую роль в этом сыграли люди, с которыми я работал. Все были приветливы и готовы помочь. Коллеги играли со мной в игры, помогали работать над кодом и просто болтали о разных вещах. Лето прошло просто замечательно!

Спасибо всем стажёрам за их старания и отличные проекты!

Первая часть рассказов стажёров: о разработке игр

2020
14 комментариев

Судя по скрину я недостаточно азиат, чтобы быть достойным Риотов

5
Ответить

Все ещё не понимаю, что риот геймс делают на данном сайте

3
Ответить

Это, конечно, интересная статья, но с такой рекламой стажировки ее отсутствие в СНГ выглядит как помахать конфетой перед лицом младенца :(

2
Ответить

Выглядит как антиреклама.

2
Ответить

Мечтаю попасть на работу к вам, но без опыта в геймдеве кажется это невозможно.

1
Ответить

Зависит от того, кем вы хотите работать.

2
Ответить

@Riot Games а это правда что Эло полиция существует? ( ͡° ͜ʖ ͡°)

Ответить