1. Проектный фон

В эпоху мобильных игр при проектировании бэкенда для игровых систем часто возникают следующие сценарии:

• Требования: во время проведения мероприятий типа «Мгновенная распродажа» в бэкенд системы поступает огромный объём трафика, что создаёт нагрузку на систему. Этот мгновенный трафик может превышать прогнозируемый пиковый трафик в 7–8 раз, а иногда и более чем в 10 раз.
• Бэкенд-архитектура: бэкенд широко использует микросервисную архитектуру, структура топологии системы сложна, и трудно оценить общую нагрузку безопасности системы. Кроме того, устойчивость к нагрузкам у разных сервисов внутри системы неодинакова: некоторые модули демонстрируют линейное снижение производительности с увеличением трафика, вызывая эффект «лавины», который может привести к сбою всей системы.
• Уровень эксплуатации: независимая развёртывание каждого бизнес-модуля приводит к низкой эффективности использования машинных ресурсов, а смешанное развёртывание может влиять на трафик между разными бизнес-процессами.

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

2. Дизайн решения

Дизайн решения должен соответствовать следующим основным принципам:

• Механизм защиты от нагрузки не должен существенно увеличивать существующую нагрузку на систему, он должен быть незаметным в нормальных условиях трафика и обеспечивать защиту системы во время пиковых нагрузок.
• Поддержка гетерогенного машинного развёртывания и удобство динамического масштабирования системы.
• Сам сервис управления трафиком должен быть нечувствительным к изменениям трафика, чтобы избежать частого масштабирования при резких изменениях трафика.
• Возможность контролировать как трафик отдельных машин, так и общий трафик системы.
• Способность управлять как трафиком на уровне бизнеса, так и трафиком на уровне ресурсов, обеспечивая безопасное совместное использование машин различными бизнес-процессами и повышая эффективность использования ресурсов.
• Обеспечение эффективного взаимодействия между восходящими и нисходящими потоками, позволяя восходящим потокам эффективно управлять входящим трафиком, а нисходящим — оказывать «обратное давление», позволяя восходящим потокам активно ограничивать доступ к нисходящим и при необходимости «отключать».
• Наличие хорошей способности к восстановлению после сбоев, минимизируя влияние на бизнес при временном отказе сервиса управления трафиком.
• Простота механизма управления трафиком для удобства эксплуатации, без значительного увеличения сложности системы.

Исходя из этих принципов, система защиты от нагрузки разрабатывается на трёх уровнях:

• Управление входящим трафиком в реальном времени через сервис квотирования.
• Периодический мониторинг потребления аппаратных ресурсов отдельными машинами.
• Мониторинг качества услуг нисходящих потоков в режиме реального времени.

Архитектура системы

3. Каталог

1.1 CPPAPI

— C++ версия библиотеки API управления трафиком, подробности использования см. в (docs/wiki/API-C++.md).

3.2 PHPAPI

— Версия библиотеки API управления трафиком PHP, подробности использования см. в (docs/wiki/API-php.md).

3.3 Protocol

— Протокол Pb.

3.4 QuaAgent

— Агент с небольшим квотированием, предназначенный для балансировки нагрузки для действий с низким QPS. Зависимости среды: среда Linux x64, рекомендуется CentOS 7.x; Golang 1.0 или выше. Компиляция: перейдите в QuaAgent/src/flux и выполните sh huild.sh. Запустите ./qagent.

3.5 QuaServer

— Сервер расчёта квот, собирает статистику и распределяет квоты по узлам. Компиляция: войдите в каталог QuaServer и выполните make.

4. Примеры эффектов

5. Лицензия

ModernFlux основан на лицензии BSD3, подробнее см. LICENSE.