Упражнение. Добавление проверок работоспособности веб-приложения

Завершено

Contoso Shoes требует способа проверить работоспособность веб-приложения на уровне API, а также его зависимостей. Вы хотите реализовать выделенную конечную точку проверки работоспособности в приложении, которая сообщает о состоянии работоспособности API через регулярные интервалы.

Текущее состояние и проблема

В текущей структуре приложение регистрирует ошибки при возникновении проблем со средой выполнения в коде API или вызовах зависимых служб, таких как неудачные запросы к базе данных. Этот подход полезен при устранении неполадок после возникновения инцидента.

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

Спецификация

Задача — создать выделенную службу работоспособности в качестве расширения для уже развернутого кода.

• Введите API проверки работоспособности в приложении. API должен проверить состояние работоспособности приложения и его зависимости и вернуть указание состояния. Например, API периодически должен проверять операции чтения и записи в Azure Cosmos DB. Реализуйте эти функции как отдельные пробы, чтобы операции чтения и записи проверялись независимо.

  Совет

  Расширьте проверку работоспособности на нефункциональную службу, например Azure Key Vault и Реестр контейнеров Azure. Этот шаг важен, так как если эти службы испытывают сбой, вы можете заметить влияние на возможность горизонтального масштабирования или противостоять перезапуску Служба приложений экземпляра.

• Конечная точка API проверки работоспособности часто вызывается несколькими источниками и не должна ухудшать производительность API. Например, план службы приложение Azure должен отправлять запросы в конечную точку дважды в минуту и принимать обоснованные решения о том, какие экземпляры Служба приложений для распределения трафика.

• Оптимизация производительности API проверки работоспособности путем кэширования приводит к памяти в течение 10 секунд. Не каждый запрос к конечной точке проверки работоспособности должен привести к внутреннему вызову. Некоторые из этих ответов можно обслуживать из кэша.

• Сделайте данные проверки работоспособности доступными в Azure Monitor для дальнейшего анализа.

Рекомендуемый подход

Чтобы приступить к работе с проектом, рекомендуется использовать следующий подход:

1– проверки работоспособности

Все запросы, отправляемые API проверки работоспособности, должны выполняться асинхронно и параллельно. Проверка работоспособности критически важных компонентов, таких как база данных. API должен периодически проверять операции чтения и записи. Реализуйте эти функции как отдельные пробы, чтобы операции чтения и записи проверялись независимо.

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

2–шаблон кэширования

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

Проверьте свою работу

Ниже приведен пример приложения служба работоспособности. Вы охватывали все аспекты в вашем дизайне?

• Совместима ли конечная точка проверки работоспособности с функцией проверки работоспособности службы приложение Azure?
• Вы включили проверки зависимостей среды выполнения? Что вы использовали в качестве прокси-сервера или теста?
  • Cosmos DB для чтения и записи
  • Сторонний API
• Вы кэшируете результаты проверки работоспособности, чтобы снизить нагрузку на производительность?
• Вы записывали события в проверки работоспособности? Обратите внимание на успехи и неудачи?
• Вы применили выборку журнала приложение Azure Insights к журналам проверки работоспособности?

Проверка знаний

1.

Почему кэширование реализовано в конечной точке работоспособности?

Чтобы сократить затраты на проверку работоспособности.

Чтобы повысить точность результатов проверки работоспособности.

Чтобы предотвратить подавляющие подчиненные компоненты.

2.

API защищен Служба приложений аутентификацией. Будет ли Служба приложений проверка работоспособности работает с конечной точкой API проверки работоспособности?

№ Проверка подлинности и работоспособности Служба приложений не может быть включена одновременно в службе.

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

Да. Службу приложение Azure можно настроить для получения необходимых маркеров доступа для отправки с помощью проб работоспособности.

Вы должны ответить на все вопросы перед проверкой.