Обзор

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

Тестирование производительности

Процесс тестирования

1. Параметры измерения давления
   1. запросы 20 Вт
   2. 1000 потоков
2. сопоставление маршрутов
   1. Элемент конфигурации одного маршрута: настройте только 5 полностью совпадающих маршрутов.
   2. Несколько элементов конфигурации маршрутизации: прежде чем сопоставление будет успешным, существует 1000 несовпадающих маршрутов.

Результаты испытаний

1. Количество запросов в секунду

• Совпало 5 маршрутов:
  

  5 маршрутов совпадают
• 1000 совпадений маршрута:
  

  1000 матчей по маршруту

2. Использование ресурсов

1. CPU

CPU

2. GC

GC

2. STW

STW

в заключение

• Количество совпадений маршрутов сильно влияет на QPS.
• Влияние на ЦП, сборщик мусора и STW также велико.

Место проблемы

1. Сравнение производительности

5 маршрутов (хорошая производительность)

Как видно из рисунка ниже, общее распределение времени ЦП относительно нормальное, три части времени относительно равномерны, и все они потребляются такими компонентами, как сеть и React, поэтому общая нагрузка ЦП находится в относительно здоровое состояние.

fire_5_routes

1000 маршрутов (плохая производительность)

Как видно из рисунка ниже, очевидно, что загрузка ЦП в Части 1 ненормально пропорциональна всей пропорции, поэтому основная проблема с производительностью связана с Частью 1.

fire_1000_routes

два、Место проблемы

fire_reason

• Из рисунка видно, что место с высокой загрузкой ЦП происходит из org/springframework/cloud/gateway/handler/predicate/HostRoutePredicateFactory$1.test.
• HostRoutePredicateFactory используется для проверки соответствия имени домена
• Построенные 1000 тестовых маршрутов и URL-адреса запросов не совпадают из-за несогласованных доменных имен. Здесь показатели производительности соответствуют построенной тестовой модели.

Оптимизация производительности

Причина проблемы

Каждый запрос будет проходить через цепочку маршрутов, а временная сложность равна O(n). Поскольку шлюз продолжает использоваться, маршрут будет продолжать увеличиваться. Таким образом, производительность будет продолжать снижаться.

решение

• Идея: Самая интуитивная идея — кэшировать маршрут, и доменное имя оказывается наиболее подходящим измерением.
• Причины, по которым доменные имена подходят для кэширования измерений：
  • Прежде всего, доменное имя стабильно и не изменится при изменении пути запроса.
  • Во-вторых, Маршруты под доменным именем не будут расти бесконечно, а обычно их количество ограничено.

Решите результат

Модификация кода

Расширьте функциональность шлюза за счет следующих двух аспектов

• Загрузка маршрута
  • В процессе загрузки анализируется элемент конфигурации Host Маршрута.
  • При использовании хоста в качестве ключа связанный список маршрутов является наиболее ценным, а маршрут кэшируется на основе измерения доменного имени.
• Маршрутизация
  • Измените селектор маршрута SpringCloudGateway.
  • Запрошенный хост точно соответствует цепочке маршрутов, и операция маршрутизации выполняется.

Оптимизированный стресс-тест HTTP на 1000 маршрутах.

QPS_1000_After

Видно, что для тех же 1000 маршрутов QPS и время ответа пришли в норму.

Продолжительность вызова HostRoutePredicateFactory

• До оптимизации
  
• После оптимизации
  

  fire_host_route_after

результат

Использование org/springframework/cloud/gateway/handler/predicate/HostRoutePredicateFactory$1.test здесь уже очень мало, и программа возвращается в нормальное состояние.

пример кода

Обратитесь к следующему коду:

spring-cloud-gateway-domain-routers

Если вы решили свою проблему, вы можете нажать звездочку на Github. В Github есть и другие платформы с открытым исходным кодом. Заинтересованные студенты могут использовать их и задавать вопросы.