Архитектура хостинга superhub
Описание архитектуры хостинга и использованных решений в ходе ее реализации. Начнем от процесса написания кода и закончим деплойментом на продакшн.
начало
Весь стек хостинга написан на php с редким использованием сторонних ЯП. Я сейчас не говорю о js на сайте, css или html. Речь идет исключительно про большой пласт кода. Вот скриншот с нашего гитлаба, где видна эта информация: 
Все используемые нами ресурсы находятся во внутреннем периметре, который недоступен внешним пользователям. Это начинается с гитлаба и заканчивается системой управления куберкластером.
Не знаю, с чего именно стоит начать, поэтому пойдем с процесса деплоя
деплой
После написания кода и пуша его во внутренний гитлаб тригерится ci/cd. При пуше в мастер ветку собирается продакшн билд, при пуше в другие (dev) ветки собирается соответственно dev-билды.
Локальный ci/cd запускается на внутреннем раннере, который имеет доступ в локальный docker registry, который опять же не светится в интернете. Стоит сразу сказать, что весь *.hosting.superhub(за исключением панели) является микросервисной архитектурой, поэтому в его основе лежит docker.
Далее, как только соберется докер-образ в раннере он отправляется в том же пайплайне в registry. Следующим шагом пойдет пайплайн выкладки релиза в сентри, а далее пайплайн релиза во внутренний кубер-кластер.
Этим пунктом я абстрактно прошелся по верхушкам нашего релизного цикла, но поехали дальше, чуть-чуть вглубь
сентри
Для отслеживания ошибок панели и хостинга при релизах, деплое или других аномалиях мы используем sentry. Это очень удобная система с гибким, красивым, понятным и очень обширным интерфейсом. По нему сразу можно понять, когда, где и почему на хостинге случилась проблема.
С помощью сентри мы видим, когда пользователь не может авторизоваться и почему, когда он не может купить сервер и почему, какие ошибки в калькуляторе встречаются, почему не работает продление серверов и тд и тп. Каждую ошибку мы привязываем к соответствующему релизу, и резовлим ее, если на следующем релизе она не появилась опять
кубер
Раньше все сервисы, сайты и системы устанавливались на железные сервера. По мере роста их количества, падения, выключения создавались системы, которые повышают отказоустойчивость проектов. Одной из самых популярных систем в данный момент является kubernetes
В нашем случае ноды кубернетеса находятся во внутреннем периметре кластера superhub, в локации MSK-B (раньше в этой локации была нода fresh), сейчас она используется только для обхода блокировок. В случае с кубером это повышает отказоустойчивость проекта, уменьшает проблемы с деплойментом (ничего руками делать не надо, за всё отвечает ci/cd) и позволяет проводить работы на серверах без влияня для пользователей. В этом случае нужно просто заранее "очистить" ноду, а дальше шедулер поднимет контейнеры на других рабочих.
вспомогательные сервисы
ручки управления
Для управления списанием с баланса денег у нас существует определенная ручка, которая закрыта авторизацией, доступом с определенных ip-адресом и токеном (поэтому найти и взломать ее будет довольно сложно). С помощью нее осуществляется ежедневное списание средств на хостинге.
Для автоматизации мы записываем логи списания в базу. Для того чтобы не списывать деньги по несколько раз в день (с этим были связаны инциденты на ранних этапах создания хостинга) мы также проверяем наличие записи за день в бд, и если она существует - не списываем деньги вновь.
Для проверки списания существует внешний хелсчек, который тригерится при успешном списании средств. Если тригер не пришел, админу в телеграме приходит уведомление, что списание не произошло, и мы начинаем разбираться в причинах 
статистика по серверам
На сайте хостинга на главной существует статистика по запущенным серверам и по количеству игроков онлайн.
В основе этого лежит микросервис, который раз в 15 минут запускается по крону в кубер-кластере и в мультипоточном режиме обходит все сервера в панели. Далее он записывает эти данные в базу данных хостинга, а также отправляет метрику во внутренний prometheus (так наша команда имеет понимание, в какой момент времени сколько серверов было запущено). Каждый заход пользователя на страницу хостинга тригерит обращение в базу. Таким образом мы снимаем нагрузку на панель и не разрешаем пользователям положить ее, если одномоментно на хостинг зайдут 100 человек.
система фидбека
Для пользователей мы подняли систему фидбека, также на микросервисной архитектуре. Она сделана специально для сбора предложений и багов, а в ее основе лежит то же самое, что и для основного хостинга (раздел про кубернетес)
Этим кратким и скомканным обзором мы пытались показать, что то, что вы видите на хостинге - только верхушка айсберга. На самом деле внутри всего этого лежит большая и сложная система, которая работает слаженно друг с другом. Если вам понравилась эта часть про обзор архитектуры - можешь поставить лайк под записью и попросить в комментариях рассказать о чем-либо подробнее. Мы выложим в следующих частях больше подробностей по каждому пункту