Если Health Checks вызывает другие приложения Health Checks

Question

У меня есть два API-интерфейса A и B, которые я контролирую, и оба проверяют готовность и работоспособность.A имеет зависимость от B.

A
/foo - This endpoint makes a call to /bar in B
/status/live
/status/ready

B
/bar
/status/live
/status/ready

Должна ли проверка работоспособности готовности A вызывать проверку работоспособности для API B из-за зависимости?

Answer 1

Есть Готовность и Живость.и я не думаю, что есть очевидный ответ.только руководство -
Живой означает, что услуга просто отзывчива.например, может ответить 200 / ОК.Готово означает функционирование на том, что от него ожидают.(это наиболее часто используемый API)

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

Answer 2

Нет, вам не нужно проверять Healthchek на других микросервисах.Единый микросервис должен работать независимо от других микросервисов (согласно определению микросервиса).Если один микросервис зависит от другого, то вы можете использовать fallBack, схемы автоматического выключателя для других микросервисов, чтобы он мог работать без сбоев.

Answer 3

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

Однако веб-приложение MVC eShopOnContainers имеет несколько зависимостей от остальных микросервисов.Таким образом, он вызывает один метод AddUrlCheck для каждого микросервиса, как показано в следующем примере:

// Startup.cs from the MVC web app
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
        services.Configure<AppSettings>(Configuration);
        services.AddHealthChecks(checks =>
        {
            checks.AddUrlCheck(Configuration["CatalogUrl"]);
            checks.AddUrlCheck(Configuration["OrderingUrl"]);
            checks.AddUrlCheck(Configuration["BasketUrl"]);
            checks.AddUrlCheck(Configuration["IdentityUrl"]);
        });
    }
}

Таким образом, микросервис не будет предоставлять «исправный» статусдо тех пор, пока все его проверки не будут здоровы.

выделение мое

Так что более прямо ответить на ваш вопрос о

Должна ли проверка работоспособности для A выполнить вызов проверки работоспособности для API B из-за зависимости?

Я бы сказал, что да, так и должно быть.Особенно если здоровье зависимости B напрямую влияет на стабильность A.

Answer 4

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

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

Answer 5

Сервис А готов, если он может обслуживать бизнес-запросы.Таким образом, если возможность достичь B является частью того, что ему нужно для выполнения (что, по-видимому, так и есть), он должен проверить B.

Преимущество наличия проверки A для B заключается в том, что выможет быстро потерпеть неудачу при плохом непрерывном обновлении .Скажем, ваш A неправильно настроен, так что в обновлении указана неверная информация о соединении для B - возможно, имя службы B введено как переменная среды, а новая версия содержит опечатку.Если ваши экземпляры A проверяются на Bs при запуске, вы можете легче гарантировать, что обновление завершится неудачно и что трафик не поступит на новые неправильно сконфигурированные блоки.Подробнее об этом см. https://medium.com/spire-labs/utilizing-kubernetes-liveness-and-readiness-probes-to-automatically-recover-from-failure-2fe0314f2b2e

. Обычно A достаточно для проверки конечной точки живучести B или любой конечной точки минимальной доступности, а не конечной точки готовности B.Это потому, что kubernetes будет проверять проверку готовности B для вас в любом случае , поэтому любой экземпляр B, к которому может обратиться A, будет готов.Вызов конечной точки жизнеспособности B, а не готовности, может иметь значение, если конечная точка готовности B выполняет больше проверок, чем контрольная точка .Имейте в виду, что kubernetes будет регулярно вызывать эти зонды - готовность, а также жизнеспособность - у них обоих есть период .Разница заключается в том, был ли модуль снят с обслуживающего трафика (если не удается подготовиться) или перезапущен (если не удалось обеспечить работоспособность).Вы не пытаетесь выполнить сквозные проверки транзакций , вы хотите, чтобы эти проверки содержали минимальную логику и не использовали слишком большую нагрузку.

Предпочтительно, если код внутриРеализация готовности A выполняет проверку, а не проверку на уровне k8s (в самой спецификации Pod).На втором месте лучше всего делать это на уровне k8s, так как в идеале вы хотите знать, что код, работающий в контейнере, действительно соединяется.

Другой способ проверить, доступны ли зависимые сервисы - это проверкав initContainer .Использование initContainers позволяет избежать многократного перезапуска во время запуска (путем обеспечения правильного упорядочения), но выполнение проверок зависимостей с помощью проб может пойти глубже (если это реализовано в коде приложения), и пробники будут продолжать периодически запускаться после запуска.Так что может быть выгодно использовать оба.

Будьте внимательны при проверке готовности других служб к чрезмерной готовности, поскольку это может привести к каскадной недоступности.Например, если бэкэнд ненадолго отключается, а внешний интерфейс проверяет его, то внешний интерфейс также станет недоступным и не сможет отображать хорошее сообщение об ошибке.Возможно, вы захотите начать с простых проб и осторожно добавлять сложность по ходу работы.