Реализация отказоустойчивых приложений с API Gateway (Проверка здоровья)

Проверка работоспособности API 🩺

Мы знаем, что API-сервисы выходят из строя по разным причинам, таким как проблемы с сетью, проблемы с соединением (не удалось открыть соединение с источником данных, например, базой данных SQL Server) и производительностью API, невозможность аутентификации в зависимостях, отключение общей зависимости, крах из-за критических ошибок, утечки памяти и многое другое😬. В таких сценариях наши сервисы должны быть достаточно устойчивыми, чтобы справляться с предсказуемыми сбоями, когда они происходят, прежде чем они станут более значительной головной болью🤯, чем это необходимо. Сбои в работе одного сервера не требуют больших усилий, но по мере роста числа приложений вы сталкиваетесь с новыми проблемами при мониторинге состояния каждого микросервиса, чтобы понять, как поведет себя ваше приложение на базе микросервисов, когда какой-либо из них станет недоступным.

Как часть лучших практик мониторинга API, health check❤️ позволяет получать информацию о состоянии ваших API, контейнеров и микросервисов в режиме реального времени. Проверка работоспособности API способна проверить все, что может помешать API обслуживать входящие запросы😎.

Например, при использовании таких оркестров, как Kubernetes и Service Fabric, периодически выполняющих проверку здоровья и определяющих, что сервис/контейнер нездоров, он прекращает маршрутизацию запросов к этому экземпляру. Также обычно создается новый экземпляр этого контейнера.

Проверка работоспособности API с помощью шлюза API

Самый простой и стандартизированный способ проверки состояния сервиса — определить новую конечную точку проверки состояния, например /health или /status, как отдельный REST-сервис, реализованный в компоненте микросервиса. ASP.NET Core предлагает Health Checks Middleware и библиотеки для информирования о состоянии здоровья компонентов приложения.

Проверки здоровья предоставляются микросервисом в виде конечных точек HTTP/HTTPS 👉🏼.

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

Apache APISIX Upstream Health Check

Apache APISIX API Gateway поддерживает почти все современные модели отказоустойчивости, такие как таймауты, откат, повторные попытки и прерывание цепи, о которых я рассказывал в другой статье блога Реализация отказоустойчивых приложений с помощью API Gateway (прерывание цепи), которые также могут быть применены к вашим API микросервисов. Механизм проверки здоровья Apache APISIX регулярно выполняет проверку здоровья каждого целевого сервиса, помечая его как здоровый или нездоровый в зависимости от того, реагирует он или нет. Вы также можете в любое время получить информацию о состоянии здоровья определенных узлов, используя конечную точку проверки здоровья Control API-health check.

Активная и пассивная проверка здоровья

APISIX предоставляет два типа проверок состояния здоровья:

• ➕ Активные проверки — APISIX периодически запрашивает конечную точку API проверки состояния здоровья, открытую целевым узлом (бэкэнд-сервис), чтобы определить, доступен ли вышестоящий сервис для обслуживания запроса.

• ➖Пассивные проверки — APISIX действует как прокси для операций, которые могут завершиться неудачей. Прокси отслеживает количество недавних сбоев, которые произошли, и использует эту информацию, чтобы решить, разрешить ли операцию продолжить или просто вернуть исключение. Пассивная проверка работоспособности также известна как Circuit breaker. 

Как работает активная проверка здоровья в Upstream❓

💁В этой статье блога мы сосредоточимся в основном на активной проверке здоровья и на том, как ее использовать, подход пассивной проверки здоровья я более подробно рассмотрел здесь с помощью API Breaker Plugin.

Вы можете включить и управлять активной проверкой здоровья через конфигурацию восходящего потока, где определяются параметры конфигурации проверки здоровья.
Чтобы включить активную проверку здоровья для upstream, вам нужно указать такие элементы конфигурации, как счетчики, статусы или интервал (как часто определяется состояние здоровья API в секундах), и вот краткое описание различных сценариев, которые могут произойти:

🟢 Если восходящий поток возвращает здоровый код состояния HTTP, он увеличивает счетчик upstream.checks.active.healthy.successes для целевого узла. Если счетчик успехов достигнет предела, указанного в конфигурации, то узел восходящего потока будет помечен как здоровый. 
 
🔴 Если соединение не удалось, то увеличивается счетчик upstream.checks.active.unhealthy.http_failures для целевого узла. Если этот счетчик достигнет предела, указанного в конфигурации, то восходящий узел будет помечен как нездоровый соответственно.  

Существуют и другие свойства, такие как timeouts, и tcp_failures, подробнее о них вы можете узнать в документации. 

Демонстрация Apache APISIX Upstream Health Check

🙋🏼 После того, как мы получили небольшую информацию о том, как Apache APISIX обрабатывает проверку здоровья для своих вышестоящих сервисов, давайте перейдем к демонстрации реализации механизма оркестровки проверки здоровья для нашего существующего образца проекта ASP.NET Core WEB API с одной конечной точкой GET (получение списка всех продуктов).

Предварительные условия

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

Регистрация функции проверки работоспособности в бэкенде

Для начала нам необходимо использовать функцию HealthChecks в микросервисе ASP.NET нашего внутреннего продукта. С помощью встроенных API в .NET мы можем легко настроить службу проверки здоровья.

Следующий пример создает конечную точку проверки здоровья по пути /api/health. Нам нужно просто добавить этот код в метод Configure в файле Startup.cs.

app.UseHealthChecks("/api/health");

Далее нам нужно добавить простую логику для генерации случайных статусов здоровья при каждом запросе конечная точка выдает разные результаты, указывая здоровье как Healthy, Degraded, или Unhealthy. Конечно, вы можете добавить свою собственную логику для правильного определения состояния здоровья.

services.AddHealthChecks()
    .AddCheck("random-health-status", () =>
    {
        Random rnd = new();
        for (int j = 0; j < 100; j++)
        {
           var rndNum = rnd.Next();
            if (rndNum % 2 == 0)
            {
                return HealthCheckResult.Unhealthy();
            }
            else {
                return HealthCheckResult.Healthy();
            } 
        }
        return HealthCheckResult.Degraded();
    });

С помощью вышеописанных изменений мы добавили функциональность проверки состояния здоровья в наш API. Если вы используете команду curl cmd для выполнения HTTP-запроса к конечной точке проверки состояния здоровья или перейдете по следующему URL в браузере, вы увидите, что конечная точка проверки состояния здоровья отвечает.

Чтобы приблизить пример к реальности, вы также можете добавить еще один экземпляр микросервиса Product. Просто определите еще один сервис в файле docker-compose.yaml, работающий на разных портах, как показано ниже:

...
  productapi1:
    image: productapi
    build:
      context: ./productapi
      dockerfile: Dockerfile
    ports:
      - "5555:80"    
    networks:
      apisix:
  productapi2:
    image: productapi
    build:
      context: ./productapi
      dockerfile: Dockerfile
    ports:
      - "5556:80"    
    networks:
      apisix:
...

Создание конфигурации Upstream с проверкой здоровья

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

Следующий пример конфигурации Upstream отслеживает проверку здоровья двух узлов productapi1 и productapi2 путем запуска каждые 2 секунды /api/health конечной точки каждого из них, если какой-либо из них недоступен (нездоров), он перенаправляет запросы на здоровый узел или сообщает об ошибке service unavailable:

curl "http://127.0.0.1:9080/apisix/admin/upstreams/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
 "nodes": {
     "productapi1:80": 1,
     "productapi2:80": 1
 },
 "type": "roundrobin",
 "checks": {
     "active": {
         "type": "http",
         "http_path": "/api/health",
         "healthy": {
             "interval": 2,
             "successes": 1
         },
         "unhealthy": {
             "interval": 1,
             "http_failures": 2
         }
     }
   }
}'

☝️ Вы можете использовать поле the upstream.checks.active.type, чтобы указать, выполнять ли HTTP или HTTPS зондирование.

Создание маршрута для восходящего потока

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

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "name": "Route for health check",
    "methods": ["GET"], 
    "uri": "/api/products", 
    "plugins": {},
    "upstream_id": "1"
}'

Обратите внимание, что мы также можем достичь тех же результатов конфигурации, что и в Apache APISIX Dashboard, с помощью CLI. Вы можете узнать больше об использовании приборной панели в видеоуроке «Начало работы с Apache APISIX Dashboard».

Как проверить работоспособность🙎

Мы можем легко проверить, как Apache APISIX отслеживает проверку здоровья целей, остановив productapi1 или productapi1 контейнер из docker 🤪, что вызывает ошибку 503 Service Temporarily Unavailable, и когда одна цель нездорова, вы можете увидеть, что запросы перенаправляются на другой здоровый узел. Следующая команда curl cmd просто вызывает конечную точку /api/product:

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

Если внимательно изучить журналы обоих экземпляров службы productapi, то можно заметить, что конечная точка много раз получает от APISIX запросы на проверку состояния здоровья.

apisix-dotnet-docker-productapi1-1       | fail: Microsoft.Extensions.Diagnostics.HealthChecks.DefaultHealthCheckService[103]
apisix-dotnet-docker-productapi1-1       |       Health check random-health-status with status Unhealthy completed after 0.0081ms with message '(null)'

Что дальше ➡️

В этой статье мы рассмотрели использование API-шлюза Apache APISIX для обеспечения мониторинга здоровья API микросервисов. Существует множество аспектов использования конечных точек проверки работоспособности API для балансировки нагрузки на API, создания отчетов по метрикам и тестирования зависимостей API, таких как базы данных и конечные точки внешних сервисов, для подтверждения доступности. APISIX также может быть центральной точкой для всех типов (логирования, мониторинга и трассировки) API Observability и дальнейшего извлечения полезных данных в другие решения для мониторинга, аналитики и визуализации, такие как Prometheus, Grafana или Elasticsearch. Узнайте больше об API Observability с помощью Apache APISIX Plugins.

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

➔ Реализация отказоустойчивых приложений с API Gateway (Circuit breaker).

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

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

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

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

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

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

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

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

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

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

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