Перейти к основному содержимому

Ограничение скорости в Spring Cloud Netflix Zuul

· 5 мин. чтения

Задача: Сумма двух

Дано массив целых чисел и целая сумма. Нужно найти индексы двух чисел, сумма которых равна заданной ...

ANDROMEDA

1. Введение

Spring Cloud Netflix Zuul — это шлюз с открытым исходным кодом, обертывающий Netflix Zuul . Он добавляет некоторые специальные функции для приложений Spring Boot. К сожалению, ограничение скорости не предусмотрено из коробки.

В этом руководстве мы рассмотрим Spring Cloud Zuul RateLimit , который добавляет поддержку запросов на ограничение скорости.

2. Конфигурация Maven

В дополнение к зависимости Spring Cloud Netflix Zuul нам нужно добавить Spring Cloud Zuul RateLimit в pom.xml нашего приложения :

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>
<dependency>
<groupId>com.marcosbarbero.cloud</groupId>
<artifactId>spring-cloud-zuul-ratelimit</artifactId>
<version>2.2.0.RELEASE</version>
</dependency>

3. Пример контроллера

Во-первых, давайте создадим пару конечных точек REST, к которым мы применим ограничения скорости.

Ниже представлен простой класс Spring Controller с двумя конечными точками:

@Controller
@RequestMapping("/greeting")
public class GreetingController {

@GetMapping("/simple")
public ResponseEntity<String> getSimple() {
return ResponseEntity.ok("Hi!");
}

@GetMapping("/advanced")
public ResponseEntity<String> getAdvanced() {
return ResponseEntity.ok("Hello, how you doing?");
}
}

Как мы видим, нет специального кода для ограничения скорости конечных точек. Это потому, что мы настроим это в наших свойствах Zuul в файле application.yml . Таким образом, сохраняя наш код несвязанным.

4. Зуул Свойства

Во-вторых, давайте добавим следующие свойства Zuul в наш файл application.yml :

zuul:
routes:
serviceSimple:
path: /greeting/simple
url: forward:/
serviceAdvanced:
path: /greeting/advanced
url: forward:/
ratelimit:
enabled: true
repository: JPA
policy-list:
serviceSimple:
- limit: 5
refresh-interval: 60
type:
- origin
serviceAdvanced:
- limit: 1
refresh-interval: 2
type:
- origin
strip-prefix: true

В разделе zuul.routes мы предоставляем сведения о конечной точке. И в zuul.ratelimit.policy-list мы предоставляем конфигурации ограничения скорости для наших конечных точек. Свойство limit указывает, сколько раз конечная точка может быть вызвана в течение интервала обновления .

Как мы видим, мы добавили ограничение скорости в 5 запросов за 60 секунд для конечной точки serviceSimple . Напротив, serviceAdvanced имеет ограничение скорости 1 запрос в 2 секунды.

Конфигурация типа указывает, какой подход к ограничению скорости мы хотим использовать. Вот возможные значения:

  • origin — ограничение скорости на основе запроса источника пользователя
  • url — ограничение скорости на основе пути запроса нисходящего сервиса
  • пользователь — ограничение скорости на основе аутентифицированного имени пользователя или «анонимного»
  • Нет значения — действует как глобальная конфигурация для каждой службы. Чтобы использовать этот подход, просто не устанавливайте параметр «тип»

5. Тестирование ограничения скорости

5.1. Запрос в пределах лимита скорости

Далее, давайте проверим ограничение скорости:

@Test
public void whenRequestNotExceedingCapacity_thenReturnOkResponse() {
ResponseEntity<String> response = restTemplate.getForEntity(SIMPLE_GREETING, String.class);
assertEquals(OK, response.getStatusCode());

HttpHeaders headers = response.getHeaders();
String key = "rate-limit-application_serviceSimple_127.0.0.1";

assertEquals("5", headers.getFirst(HEADER_LIMIT + key));
assertEquals("4", headers.getFirst(HEADER_REMAINING + key));
assertThat(
parseInt(headers.getFirst(HEADER_RESET + key)),
is(both(greaterThanOrEqualTo(0)).and(lessThanOrEqualTo(60000)))
);
}

Здесь мы делаем единственный вызов конечной точки /greeting/simple . Запрос выполнен успешно, поскольку он находится в пределах ограничения скорости.

Еще один ключевой момент заключается в том, что с каждым ответом мы получаем заголовки, содержащие дополнительную информацию об ограничении скорости. Для вышеуказанного запроса мы получим следующие заголовки:

X-RateLimit-Limit-rate-limit-application_serviceSimple_127.0.0.1: 5
X-RateLimit-Remaining-rate-limit-application_serviceSimple_127.0.0.1: 4
X-RateLimit-Reset-rate-limit-application_serviceSimple_127.0.0.1: 60000

Другими словами:

  • X-RateLimit-Limit-[ключ]: ограничение , настроенное для конечной точки.
  • X-RateLimit-Remaining-[key]: оставшееся количество попыток дозвониться до конечной точки
  • X-RateLimit-Reset-[key]: оставшееся количество миллисекунд интервала обновления, настроенного для конечной точки.

Кроме того, если мы немедленно снова запустим ту же конечную точку, мы можем получить:

X-RateLimit-Limit-rate-limit-application_serviceSimple_127.0.0.1: 5
X-RateLimit-Remaining-rate-limit-application_serviceSimple_127.0.0.1: 3
X-RateLimit-Reset-rate-limit-application_serviceSimple_127.0.0.1: 57031

Обратите внимание на уменьшение оставшегося количества попыток и оставшегося количества миллисекунд.

5.2. Запрос на превышение лимита скорости

Давайте посмотрим, что происходит, когда мы превышаем лимит скорости:

@Test
public void whenRequestExceedingCapacity_thenReturnTooManyRequestsResponse() throws InterruptedException {
ResponseEntity<String> response = this.restTemplate.getForEntity(ADVANCED_GREETING, String.class);
assertEquals(OK, response.getStatusCode());

for (int i = 0; i < 2; i++) {
response = this.restTemplate.getForEntity(ADVANCED_GREETING, String.class);
}

assertEquals(TOO_MANY_REQUESTS, response.getStatusCode());

HttpHeaders headers = response.getHeaders();
String key = "rate-limit-application_serviceAdvanced_127.0.0.1";

assertEquals("1", headers.getFirst(HEADER_LIMIT + key));
assertEquals("0", headers.getFirst(HEADER_REMAINING + key));
assertNotEquals("2000", headers.getFirst(HEADER_RESET + key));

TimeUnit.SECONDS.sleep(2);

response = this.restTemplate.getForEntity(ADVANCED_GREETING, String.class);
assertEquals(OK, response.getStatusCode());
}

Здесь мы дважды быстро вызываем конечную точку /greeting/advanced . Поскольку мы настроили ограничение скорости как один запрос в 2 секунды, второй вызов не будет выполнен . В результате клиенту возвращается код ошибки 429 ( Too Many Requests) .

Ниже приведены заголовки, возвращаемые при достижении ограничения скорости:

X-RateLimit-Limit-rate-limit-application_serviceAdvanced_127.0.0.1: 1
X-RateLimit-Remaining-rate-limit-application_serviceAdvanced_127.0.0.1: 0
X-RateLimit-Reset-rate-limit-application_serviceAdvanced_127.0.0.1: 268

После этого спим 2 секунды. Это интервал обновления, настроенный для конечной точки. Наконец, мы снова запускаем конечную точку и получаем успешный ответ.

6. Генератор пользовательских ключей

Мы можем настроить ключи, отправляемые в заголовке ответа, с помощью собственного генератора ключей. Это полезно, потому что приложению может потребоваться управлять ключевой стратегией помимо опций, предлагаемых свойством type .

Например, это можно сделать, создав собственную реализацию RateLimitKeyGenerator . Мы можем добавить дополнительные квалификаторы или что-то совершенно другое:

@Bean
public RateLimitKeyGenerator rateLimitKeyGenerator(RateLimitProperties properties,
RateLimitUtils rateLimitUtils) {
return new DefaultRateLimitKeyGenerator(properties, rateLimitUtils) {
@Override
public String key(HttpServletRequest request, Route route,
RateLimitProperties.Policy policy) {
return super.key(request, route, policy) + "_" + request.getMethod();
}
};
}

Приведенный выше код добавляет имя метода REST к ключу. Например:

X-RateLimit-Limit-rate-limit-application_serviceSimple_127.0.0.1_GET: 5

Еще одним ключевым моментом является то, что bean-компонент RateLimitKeyGenerator будет автоматически настроен с помощью spring-cloud-zuul-ratelimit .

7. Пользовательская обработка ошибок

Платформа поддерживает различные реализации для хранения данных с ограничением скорости. Например, предоставляются Spring Data JPA и Redis. По умолчанию сбои просто регистрируются как ошибки с использованием класса DefaultRateLimiterErrorHandler .

Когда нам нужно обрабатывать ошибки по-другому, мы можем определить собственный bean-компонент RateLimiterErrorHandler :

@Bean
public RateLimiterErrorHandler rateLimitErrorHandler() {
return new DefaultRateLimiterErrorHandler() {
@Override
public void handleSaveError(String key, Exception e) {
// implementation
}

@Override
public void handleFetchError(String key, Exception e) {
// implementation
}

@Override
public void handleError(String msg, Exception e) {
// implementation
}
};
}

Подобно bean -компоненту RateLimitKeyGenerator , bean-компонент RateLimiterErrorHandler также будет настроен автоматически.

8. Заключение

В этой статье мы увидели, как ограничить API-интерфейсы с помощью Spring Cloud Netflix Zuul и Spring Cloud Zuul RateLimit.

Как всегда, полный код для этой статьи можно найти на GitHub .