Нова технологія змінює eve online кардинальним чином. Представлена платформа quasar

13

Минулого місяця команда ccp games зробила прорив в основах роботи серверів mmorpg eve online, який ознаменує початок нової епохи. Студії вдалося впровадити сучасні технології, що дозволяють не тільки знизити навантаження, але і відкрити величезні можливості для поліпшення всесвіту нового едему.

Останній раз мережевий рівень кардинально змінювався в 2011 році, коли компанія ccp представила реалізацію iocp під назвою carbonio, яка в кінцевому підсумку стала основою сумнозвісного уповільнення часу. Пізніше розробники приступили до створення чорнового варіанту project sanguine для вирішення проблем середовища carbonio. Кожна оптимізація в eve online зводиться до ретельного узгодження з python global interpreter lock (gil). Просто python може робити тільки одну річ за раз. Прийняття eve stackless python, реалізація iocp через stacklessio, потім carbonio і спільне проектування з урахуванням уповільнення часу-все це підтримує неймовірну ілюзію про те, що новий едем живий. Але що, якби gil не доводилося використовувати для кожної виникаючої ідеї? як можна отримати вигоду з стрімкого зростання числа ядер в галузі в порівнянні з тактовою частотою окремих процесорів?

В цьому відношенні було проведено безліч експериментів, що мають безпосереднє відношення до project sanguine, найбільш публічним з яких є eve: aether wars. Мета полягала не в тому, щоб докорінно змінити модель комунікації в eve online, а замість цього змінити симуляційну модель. Project sanguine ж сконцентрувався на вирішенні нудних елементів, які представляють собою набір функцій eve. Симуляція майже 9 000 гравців в одному просторі могла б бути швидшою, якщо новий едем не займався обслуговуванням величезної кількості інших речей. Таким чином, project sanguine переслідував дві мети: обійти gil і створити умови для нових можливостей.

Перша форма project sanguine з’явилася з esi і презентацією eve portal в кінці 2016 року. Завдяки цим проектам в серверній архітектурі eve online була створена нова парадигма-сервісна шина. З її допомогою заново були виявлені слабкі місця gil, але з більш чіткою картиною, включаючи маршрутизацію повідомлень, серіалізацію і передачу даних. Якщо один корабель запускає один лазер серед 1000 кораблів, це 1000 повідомлень, які необхідно негайно відправити по всьому світу. Симуляція повинна адресувати це повідомлення 1000 адресатам як копію (маршрутизація повідомлень), перетворити ці дані в провідний формат (серіалізація), а потім відправити їх (передача). У більшості випадків carbonio вирішує кожну з цих проблем, але в рамках повноважень gil. Carbonio вже досить довгий час добре обслуговує eve online, але з 2011 року багато чого змінилося в бурхливих морях інтернету.

Побачивши еволюцію шаблонів у цій новій екосистемі стало ясно, що для використання парадигми необхідний більш стандартизований протокол. Завдяки інтеграції віддаленого виклику процедур (grpc) розробники змогли об’єднати можливості маршрутизації повідомлень сервісної шини з миттєвою серіалізацією буферів протоколу (стандарт повідомлень grpc). Як і раніше необхідно планувати дані за допомогою gil для передачі, але тепер вони буферизуються на більш високому рівні в окремому потоці. Це означає, що вся передача, сериализация і маршрутизація повідомлень відбуваються поза gil, за винятком копії пам’яті, яка повинна відбуватися між ними. Швидше цього бути не може.

Тепер новий едем може обробляти значно більше даних. Коли почалося створення esi, ccp games приступили до впровадження більшої кількості хмарних технологій, таких як kubernetes. У міру того, як стала очевидною потреба в простих примітивах синхронізації для обробки цієї інформації, був зроблений великий крок у бік мови go. З часом ці технології накопичувалися в окрему екосистему і почалася робота по створенню функцій, що дозволяють використовувати переваги нової здатності працювати з новим едемом відповідно до сучасних стандартів. Багато з них вже доступні гравцям.

Першим став трекер активності. Він дозволяє відстежувати всю вашу активність. Існує також його варіація з системою можливостей, яка намагається передбачити траєкторію капсулера і виділити більш цікаві частини нового едему. Крім того, сервісна шина використовувалася для списків лідерів арени безодні. Величезний обсяг роботи був зроблений для надання командам розробників екосистеми, що дозволяє використовувати міць архітектури обміну повідомленнями з цими функціями. Однак кожна з функцій обмежена можливостями клієнта гри.

Перед випуском планів навичок кожна функція передавала дані на сервер через carbonio. Тепер це працює інакше, оскільки операції плану навичок не тільки передаються через grpc, але і зовсім не взаємодіють з tranquility або його базами даних.

Чому так важливий обхід tranquility і бази даних? щоб зрозуміти це, необхідно поговорити про невдачі. Частина шляху привела до появи безлічі нових технік і інструментів, за допомогою яких можна побачити новий едем. Одна з концепцій-розподілена трасування з використанням нової улюбленої іграшки: honeycomb.io. Озброївшись усіма новими інструментами стало ясно, що саме відбувається з планами навичок, коли вони були запущені на основному сервері:

Незважаючи на існування безлічі можливостей для поліпшення в цілому з продуктивністю все було в порядку:

Але вже наступного ранку ситуація почала виходити з під контролю:

Так, це 500 тисяч мілісекунд або 8 хвилин 20 секунд, щоб відправити повідомлення. Tranquility продовжував працювати і більшість гравців не постраждали. Це тому, що розробники не взаємодіють з tranquility в традиційному сенсі цього слова. Більше немає carbonio для традиційних проксі, які потім відправляються на серверний вузол, а потім в базу даних. Натомість tranquility зосереджується на тому, що важливіше, а клієнт eve обмінюється даними через grpc з новою екосистемою, де сервіс планування навичок живе зі своєю власною базою даних.

Одна з найсильніших сторін нової екосистеми-відсутність простоїв. Щоб врятувати механіку планування навичок, не потрібно перезавантажувати сервер. Також немає необхідності випускати патч для сервера або клієнта гри. Таким чином project sanguine еволюціонував в нову технологічну платформу під назвою eve: quasar. Не дарма розробники називали поточний квадрант gateway, оскільки він віщує пряме використання шлюзів grpc.

Команда ccp продовжить вирішувати проблему застарілих сервісів шляхом розвитку quasar і оптимізації древніх систем, прискорюючи їх роботу. Для звичайних гравців це означає появу нових потужних функцій для різних частин eve online. Розробники також думають про публікацію даних моделювання через quasar, але це займе деякий час для цього.