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

У меня есть два API-интерфейса 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 из-за зависимости?

Источник

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 позволяет избежать многократного перезапуска во время запуска (путем обеспечения правильного упорядочения), но выполнение проверок зависимостей с помощью проб может пойти глубже (если это реализовано в коде приложения), и пробники будут продолжать периодически запускаться после запуска. Так что может быть выгодно использовать оба.

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

Источник

Ссылки на учебники 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,

Источник

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

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

Источник

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

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

Источник

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

Источник
Другие вопросы по тегам