Кэширование шлюза API для ASP.NET Core WEB API

Повышение производительности с помощью кэширования

Когда вы создаете API, вы хотите, чтобы он был простым и быстрым. Когда количество одновременных запросов на чтение одних и тех же данных возрастет, вы столкнетесь с несколькими проблемами😐, когда вы, возможно, задумаетесь о внедрении кэширования:

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

В этом посте мы сосредоточимся в основном на обработке кэширования на уровне шлюза API с помощью Apache APISIX API Gateway, и вы узнаете, как использовать плагин proxy-caching для повышения эффективности отклика для ASP.NET Core WEB API.

Вот обзор того, что мы рассмотрим в этом руководстве:

✔️ Кэширование в API Gateway
✔️ О Apache APISIX API Gateway
✔️ Запуск демонстрационного проекта apisix-dotnet-docker
✔️ Настройте плагин Proxy Cache
✔️ Проверить кэширование прокси-сервера

Кэширование в API Gateway

Кэширование позволяет хранить и извлекать сетевые запросы и соответствующие им ответы. Кэширование происходит на разных уровнях в веб-приложении:

• Пограничное кэширование или CDN
• Кэширование базы данных
• Кэширование сервера (кэширование API)
• Кэширование браузера

Кэширование обратного прокси — это еще один механизм кэширования, который обычно реализуется в API Gateway. Он может уменьшить количество обращений к вашей конечной точке, а также улучшить задержку запросов к вашему API за счет кэширования ответа из восходящего потока. Если в кэше API Gateway есть свежая копия запрашиваемого ресурса, он использует эту копию для удовлетворения запроса напрямую, вместо того чтобы делать запрос к конечной точке. Если кэшированные данные не найдены, запрос направляется к предполагаемым сервисам восходящего потока (бэкенд-сервисам).

Apache APISIX API Gateway

Apache APISIX — это легкий, быстрый шлюз API с открытым исходным кодом. Он может выступать в качестве единой точки входа для всех запросов в вашу сервисную сеть. APISIX может быть расширен с помощью встроенных плагинов для управления сетевым трафиком путем обработки аутентификации, безопасности, наблюдаемости, преобразования и многого другого.

Кроме того, вы можете включить кэширование API с помощью плагина proxy-cache🔌 для кэширования ответов конечных точек API и повышения производительности. Он может использоваться вместе с другими плагинами и в настоящее время поддерживает кэширование на основе диска. Данные для кэширования можно фильтровать с помощью кодов ответов, режимов запроса или более сложных методов, используя атрибуты no_cache и cache_bypass. В конфигурации плагина также можно указать время истечения срока действия кэша или объем памяти. Пожалуйста, обратитесь к другим атрибутам плагина proxy-cache.

🙋🏼 Учитывая все это, далее мы рассмотрим пример использования плагина proxy-cache, предлагаемого Apache APISIX, и применим его для ASP.NET Core Web API с одной конечной точкой.

Необходимые условия

☝️ Если вы следили за предыдущей статьей блога об управлении .NET API микросервисами с помощью Apache APISIX API Gateway, убедитесь, что вы прочитали ее и выполнили шаги (Запуск APISIX, etcd и ASP.NET WEB API), прежде чем продолжить демонстрационную сессию.

💁 Для выполнения и настройки примера проекта в соответствии с вашими потребностями, показанными в этом посте, вот минимальные требования, которые необходимо установить в вашей системе:

➡️ .NET 6 SDK
➡️ Visual Studio 2022 с установленной рабочей нагрузкой Web Development и/или кроссплатформенной разработки .NET. Это включает по умолчанию средства разработки .NET 6. Или код Visual Studio. 
➡️ Docker Desktop — для выполнения этого руководства вам также понадобится локально установленный Docker desktop. Он доступен для Windows или macOS. Или установите Docker ACI Integration CLI для Linux.

Запустите демонстрационный проект

До этого момента я предполагаю, что у вас запущен демонстрационный проект apisix-dotnet-docker. Вы можете посмотреть полный исходный код на Github и инструкцию по сборке многоконтейнерного APISIX через Docker CLI.

В проекте ASP.NET Core есть простой API для получения списка всех продуктов из сервисного слоя в файле ProductsController.cs.

Предположим, что этот список продуктов обычно обновляется только раз в день, и конечная точка получает миллиарды запросов каждый день, чтобы получить список продуктов частично или полностью. В этом сценарии использование техники кэширования API с помощью плагина proxy-cache может быть действительно полезным🙌. Для демонстрации мы включим кэширование только для метода GET.

В идеале, запросы GET должны кэшироваться по умолчанию — до тех пор, пока не возникнут особые условия.

Настройка плагина Proxy Cache

Теперь начнем с добавления плагина proxy-cache в декларативный конфигурационный файл Apache APISIX config.yaml в проекте. Потому что в текущем проекте мы еще не зарегистрировали плагин, который будем использовать для этого демо. Мы добавили название плагина proxy-cache в конец списка плагинов:

plugins:
 - http-logger
 - ip-restriction
 …
 - proxy-cache

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

proxy_cache:
 cache_ttl: 10s # default caching time if the upstream doesn't specify the caching time
 zones:
 - name: disk_cache_one # name of the cache. Admin can specify which cache to use in the Admin API by name
 memory_size: 50m # size of shared memory, used to store the cache index
 disk_size: 1G # size of disk, used to store the cache data
 disk_path: "/tmp/disk_cache_one" # path to store the cache data
 cache_levels: "1:2" # hierarchy levels of the cache

Далее, мы можем напрямую выполнить команду apisix reload для перезагрузки последнего кода плагина без перезапуска Apache APISIX. Смотрите команду для перезагрузки недавно добавленного плагина:

curl http://127.0.0.1:9080/apisix/admin/plugins/reload -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT

Затем мы выполняем еще две команды curl для настройки Upstream и Route для конечной точки /api/products. Следующая команда создает образец Upstream (это наш сервер API):

curl "http://127.0.0.1:9080/apisix/admin/upstreams/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
 "type": "roundrobin",
 "nodes": {
 "productapi:80": 1
 }
}'

Далее мы добавим новый маршрут с возможностью кэширования, установив плагин proxy-cache в свойстве plugins и указав ссылку на сервис upstream по его уникальному id для перенаправления запросов на сервер API:

curl "http://127.0.0.1:9080/apisix/admin/routes/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d ' 
{
 "name": "Route for API Caching",
 "methods": ["GET"], 
 "uri": "/api/products", 
 "plugins": {
 "proxy-cache": {
 "cache_key": ["$uri", "-cache-id"],
 "cache_bypass": ["$arg_bypass"],
 "cache_method": ["GET"],
 "cache_http_status": [200],
 "hide_cache_headers": true,
 "no_cache": ["$arg_test"]
 }
 }, 
 "upstream_id": 1
}'

Как вы можете видеть в приведенной выше конфигурации, мы определили некоторые атрибуты плагина, которые мы хотим кэшировать только успешные ответы от метода GET API.

Проверка кэширования прокси🙎

Наконец, мы можем проверить, работает ли прокси-кэширование так, как ожидается.

Мы отправим несколько запросов по пути /api/products и каждый раз должны получать ответ HTTP 200 OK. Однако Apisix-Cache-Status в ответе показывает MISS, что означает, что ответ еще не был кэширован, когда запрос попал на маршрут в первый раз. Теперь, если вы сделаете еще один запрос, вы увидите, что получите кэшированный ответ с индикатором кэширования HIT.

Теперь мы можем сделать первый запрос:

curl http://localhost:9080/api/products -i

Ответ выглядит так, как показано ниже:

HTTP/1.1 200 OK
…
Apisix-Cache-Status: MISS

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

HTTP/1.1 200 OK
…
Apisix-Cache-Status: HIT

Или если вы снова попытаетесь обратиться к конечной точке после окончания периода времени жизни (TTL) для кэша, вы получите:

HTTP/1.1 200 OK
…
Apisix-Cache-Status: EXPIRED

Отлично! Мы включили кэширование для нашей конечной точки API😎

Дополнительный тестовый пример

💁🏼 Как вариант, вы также можете добавить некоторую задержку в код контроллера продукта и измерить время отклика с кэшем и без него:

 [HttpGet]
 public IActionResult GetAll()
 {
 Console.Write("The delay starts.n");
 System.Threading.Thread.Sleep(5000);
 Console.Write("The delay ends.");
 return Ok(_productsService.GetAll());
 }

Команда curl для проверки времени отклика будет выглядеть следующим образом:

curl -i 'http://localhost:9080/api/products' -s -o /dev/null -w "Response time: %{time_starttransfer} secondsn"

Что дальше

Как мы узнали, с помощью Apache APISIX можно легко и быстро настроить кэширование ответов API для нашего ASP.NET Core WEB API. Это может значительно сократить количество обращений к вашей конечной точке, а также улучшить латентность запросов к вашему API. В Apache APISIX есть и другие многочисленные встроенные плагины, вы можете ознакомиться с ними на странице Plugin Hub и использовать их в соответствии с вашими потребностями.

Связанные ресурсы

➔ Управление API микросервисов .NET с помощью шлюза API Apache APISIX

Рекомендуемый контент 💁

➔ Посмотрите видеоурок «Начало работы с Apache APISIX».

➔ Прочитайте статью в блоге Обзор плагинов шлюза API Apache APISIX.

➔ Читайте запись в блоге Запуск Apache APISIX на Microsoft Azure Container Instance.

➔ Читайте запись в блоге Безопасность API с OIDC с помощью Apache APISIX и Microsoft Azure AD.

➔ Читайте запись в блоге Наблюдаемость API с помощью плагинов Apache APISIX.

Сообщество⤵️

🙋 Присоединяйтесь к сообществу Apache APISIX
🐦 Следите за нами в Twitter
📝 Найдите нас в Slack
📧 Пишите нам со своими вопросами.