Context
Я ищу способ сообщить своим пользователям, что одна из зависимостей моего Asp. Net основного сайта не работает и, следовательно, сайт в настоящее время недоступен. Желательно использовать страницу с ошибкой.
Asp. Net Ядро обеспечивает функциональность Проверка работоспособности для управления логами c проверки работоспособности зависимостей, но предоставляет только предназначенную конечную точку для балансировщиков нагрузки. Существует также своего рода функциональность панели мониторинга , доступная для проверок работоспособности, но она не предназначена для конечных пользователей как страница ошибок, она предназначена для администраторов.
Почему я смотрю на это функциональность?
Я использую Azure Front Door. Этот продукт работает как балансировщик нагрузки. Он может просматривать конечную точку состояния работоспособности, предоставленную Asp. Net Базовыми проверками работоспособности, и выводит из строя нездоровые внутренние узлы.
Однако не предлагает пользовательских страниц ошибок и в случае, если все внутренние узлы не работают, предполагается, что все узлы исправны . Одной из зависимостей моего сайта является внешняя служба, которая, если она не работает, будет недоступна для всех экземпляров моего сайта. Он содержит, например, учетные записи пользователей, необходимые пользователям для взаимодействия с моим сайтом. Поэтому я считаю, что мне нужно реализовать страницу ошибок на базовом сайте Asp. Net, которая будет отображать страницу ошибок при отключении этой внешней зависимости.
Предлагаемое решение
One из моих идей было бы иметь промежуточное программное обеспечение, которое, когда сайт ухудшается, всегда возвращает 503 Service Unavailable или выдает исключение. Функциональность Asp. Net Базовая страница состояния ядра может затем превратить это в соответствующую страницу ошибки.
Вопрос 1
Это лучшая архитектура? Как другие люди сделали это?
Вопрос 2
Какой самый практичный способ получить доступ к текущему состоянию здоровья?
Технически это можно назвать HealthCheckService.CheckHealthAsync(...) напрямую, но ожидание этого метода занимает некоторое время (особенно если одна из служб зависимостей не отвечает). Поэтому не стоит делать такую блокировку в конвейере запросов.
Я мог бы использовать Health Check Publisher для кэширования состояния работоспособности, опубликовав его в какой-либо пользовательской службе HealthStatusCache , но это немного похоже на обходной путь. Это как другие люди будут делать это?