Продвинутый проект: микросервис реального времени
Итоговый проект: спроектировать и построить один цельный сервис живой таблицы лидеров, который выдержит настоящий трафик и масштабируется за пределы одного процесса.
EventEmitter, асинхронный ввод-вывод, конфигурация через окружение, SQL и тестирование -- теперь соединяются в одну развёртываемую единицу. Мы построим микросервис таблицы лидеров реального времени: игроки отправляют очки по HTTP, сервис мгновенно их ранжирует, и каждый подключённый клиент видит обновление вершины таблицы вживую через WebSocket -- даже когда сервис работает как несколько контейнеров за балансировщиком нагрузки.
- нарисовать архитектуру сервиса реального времени и обосновать каждую его часть;
- использовать отсортированное множество Redis как быстрый кэш ранжирования перед надёжным источником истины в SQL;
- отправлять живые обновления в браузеры через шлюз WebSocket;
- разослать эти обновления по нескольким экземплярам с помощью Pub/Sub Redis;
- честно рассуждать о компромиссах -- волатильность, доставка не более одного раза, объединение обновлений;
- упаковать всю систему через Docker Compose и корректно её останавливать.
1. Что мы строим
Сервис таблицы лидеров для онлайн-игры. У него три задачи, и интересная инженерия -- сделать все три одновременно и правильно:
- Приём очков:
POST /scoresс игроком и значением. Это должно быть надёжно -- сбой не имеет права терять отправленные очки. - Ранжирование быстро: возвращать текущую десятку лидеров за постоянное, субмиллисекундное время независимо от числа игроков.
- Живая рассылка: каждый браузер, смотрящий на таблицу, видит новый рейтинг за доли секунды, без опроса (polling).
Слово "микросервис" просто означает, что это один сервис с одной чёткой ответственностью (таблица лидеров), общающийся со своими хранилищами данных и развёртываемый отдельно. Он не пытается быть ещё и сервером аутентификации или подбором игроков -- это отдельные единицы, которые он мог бы вызывать.
Почему не просто SQL-запрос? Вы могли бы ответить на "топ-10" через SELECT ... ORDER BY score DESC LIMIT 10. Это работает при низком трафике. Но при тысячах записей в секунду сортировка растущей таблицы на каждом чтении и отправка свежих результатов тысячам живых сокетов -- как раз то место, где наивная однопроцессная схема ломается. Остальная часть темы -- о том, как профессионалы этого избегают.