Всем привет! Решил запустить канал по .NET-разработке. Зачем мне это нужно? В процессе работы появляются удачные решения, которыми хочется поделиться, упаковать их в удобный формат и, возможно, обсудить дополнительно. Часто задают одни и те же вопросы, ответы на которые можно заранее тщательно подготовить, подробно расписать и затем просто давать на них ссылку.

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

Моя одна из любимых тем — это создание надёжных и отказоустойчивых приложений, поэтому я не мог не поделиться этим видео Антология технологий Яндекс Такси. Надёжность сервиса.

Основные моменты для разработчиков:

Изоляция точек отказа (1:53) — по этой теме я в ближайшее время напишу отдельный пост. Думаю, я ещё неоднократно буду освещать этот вопрос.
Фолбэк (13:15) и Деградация (14:14) — позволяет отключать дополнительные сервисы, чтобы снизить нагрузку на систему.
Дополнительная нагрузка "виртуальными заказами" прямо на проде (7:25) — казалось бы, мы тестируем систему в реальном окружении и можем её «положить», но, в отличие от реальных заказов, виртуальные заказы можно быстро отключить для восстановления нормальной работы.

Очень крутая практика — симуляция инцидентов (9:44) и тренировка навыков их решения. Она также позволяет понять, насколько хорошо у нас налажены мониторинг и логирование. В идеале логи и графики должны быть такими, чтобы дежурный специалист из отдела мониторинга, который никогда не видел наш код, смог понять логи и при необходимости отключить сломанный сервис, а также предпринять другие меры.

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

При разработке важно выделить ключевой и второстепенный функционал. Основная идея - дать пользователю возможность продолжать пользоваться нашим приложением, даже если наблюдаются проблемы с второстепенным функционалом.

Сегодня обсудим ситуацию с отказом внешнего сервиса (или наш микросервис к которому мы обращаемся например по REST).
Потенциально, любой внешний сервис - это точка отказа, и мы должны корректно обработать его сбой или недоступность.

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

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

Если не предпринять никаких мер, то при сбое внешнего сервиса или при отправке им некорректных данных могут возникнуть неприятные сценарии для пользователя, например «белый экран» из-за сломанного JS и невозможность оформить заказ.

Чтобы избежать таких ситуаций, делаем следующее:

1. Оборачиваем вызов сервиса в try-catch.

2. Устанавливаем минимальный таймаут. Из-за деградации второстепенного сервиса пользователь не должен долго ждать загрузки ключевого функционала.

3. Делаем возможность отключения вызова сервиса «на горячую» через appsettings.json с помощью IOptionsMonitor.
Например, если мы понимаем, что сервис стал долго отвечать или отправлять некорректные данные, мы можем вручную отключить его вызов, не дожидаясь срабатывания таймаута. Здесь можно применить шаблон «размыкания цепи» (circuit breaker), например, с помощью библиотеки Polly, но возможность ручного отключения должна быть сохранена.

Таким образом, при выбросе исключения, срабатывании таймаута или ручном отключении вызова мы возвращаем пустой список рекомендаций вместо ошибки.
На фронте мы ожидаем такой сценарий и просто скрываем блок «Рекомендации».

Опубликовал этот пост на английском в LinkedIn. Также включил возможность комментировать в канале. К сожалению, к предыдущим постам комментарии недоступны, но думаю, что обсудить их можно и в этом посте.