Лучшая практика для ограничения скорости пользователей REST API?

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

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

Есть ли какие-нибудь передовые практики для такого рода вещей? Реализация - Rails с mysql.


ruby-on-rails rest scaling capacity
person frankodwyer    schedule 05.03.2009    source источник

Ответы (3)


arrow_upward
18
arrow_downward

Все это делается с помощью внешнего веб-сервера, который слушает мир (я рекомендую nginx или lighttpd).

Что касается ограничений скорости, nginx может ограничивать, то есть 50 запросов в минуту на каждый IP-адрес, всего получает страницу 503, которую вы можете настроить.

Что касается ожидаемого временного отключения, в мире рельсов это делается через специальную страницу keepance.html. Существует какая-то автоматизация, которая создает или создает символические ссылки в этом файле, когда серверы приложений rails выходят из строя. Я бы рекомендовал полагаться не на наличие файла, а на фактическую доступность сервера приложений.

Но на самом деле вы можете запускать / останавливать службы, не теряя при этом никаких соединений. Т.е. вы можете запустить отдельный экземпляр сервера приложений на другом сокете / IP-порту UNIX, а также использовать этот новый экземпляр балансировщик (nginx / lighty / haproxy). Затем вы закрываете старый экземпляр, и все клиенты обслуживаются только новым. Связь не потеряна. Конечно, этот сценарий не всегда возможен, это зависит от типа изменений, которые вы внесли в новую версию.

haproxy - это решение, предназначенное только для балансировки. Он может чрезвычайно эффективно балансировать запросы к серверам приложений в вашей ферме.

Для довольно большой услуги вы получите что-то вроде:

  • разрешение api.domain в балансировщики с циклическим перебором N
  • Каждый балансировщик отправляет запросы к веб-серверам M для статического и P-серверов приложений для динамического содержимого. Ну что ж, в вашем REST API нет статических файлов, не так ли?

Для довольно небольшого сервиса (до 2K rps) вся балансировка выполняется внутри одного-двух веб-серверов.

person temoto    schedule 05.03.2009

arrow_upward
5
arrow_downward

Хорошие ответы уже есть - если вы не хотите устанавливать ограничитель самостоятельно, есть также решения, такие как 3scale (http://www.3scale.net), который ограничивает скорость, аналитику и т. Д. Для API. Он работает с использованием подключаемого модуля (см. Здесь подключаемый модуль ruby ​​api), который подключается к архитектуре 3scale. Вы также можете использовать его через лак, и лак будет действовать как прокси-сервер, ограничивающий скорость.

person steve    schedule 05.06.2012

arrow_upward
2
arrow_downward

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

person Denis Hennessy    schedule 05.03.2009
comment
Разве Apache не вышел из зоны высоких нагрузок? frankodwyer определенно нуждается в асинхронной сети для обработки большого количества одновременных подключений, а mpm_event еще не является стабильным в производственной среде. Конечно, apache можно было бы поставить на отдельные ящики ... есть ли смысл покупать их только для того, чтобы придерживаться apache? - person temoto; 05.03.2009
comment
Я предполагаю, что это зависит от вероятного объема запросов и стоимости каждого запроса к приложению. По моему опыту, apache может легко обрабатывать на порядки больше запросов, чем бэкэнд-приложение, которое отлично подходит для совмещенного прокси. - person Denis Hennessy; 05.03.2009