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

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

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

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

Ответы

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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