Обработка временных сбоев (создание облачных приложений Real-World с помощью Azure)

  • Статья

Рик Андерсон(Rick Anderson),Том Дайкстра (Tom Dykstra)

Скачать проект fix it или скачать электронную книгу

Электронная книга Building Real World Cloud Apps with Azure (Создание реальных облачных приложений с помощью Azure ) основана на презентации, разработанной Скоттом Гатри. В ней описано 13 шаблонов и методик, которые помогут вам успешно разрабатывать веб-приложения для облака. Сведения об электронной книге см. в первой главе.

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

Причины временных сбоев

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

Использование интеллектуальной логики повторных попыток и откатов для устранения последствий временных сбоев

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

Существует несколько способов реализации интеллектуальной логики повторных попыток.

  • В группе Microsoft Patterns & Practices есть блок приложения для обработки временных сбоев, который выполняет все действия, если вы используете ADO.NET для доступа к База данных SQL (не через Entity Framework). Вы просто задали политику для повторных попыток ( сколько раз следует повторить запрос или команду и сколько времени ожидания между попытками) и заключите код SQL в блок using .

    public void HandleTransients()
{
    var connStr = "some database";
    var _policy = RetryPolicy.Create < SqlAzureTransientErrorDetectionStrategy(
        retryCount: 3,
        retryInterval: TimeSpan.FromSeconds(5));

    using (var conn = new ReliableSqlConnection(connStr, _policy))
    {
        // Do SQL stuff here.
    }
}

    TFH также поддерживает кэш In-Role Azure и служебную шину.

  • При использовании Entity Framework вы обычно не работаете напрямую с подключениями SQL, поэтому не можете использовать этот пакет Шаблонов и методик, но Entity Framework 6 создает такую логику повторных попыток прямо в платформу. Аналогичным образом вы указываете стратегию повторных попыток, а затем EF использует эту стратегию при каждом обращении к базе данных.

    Чтобы использовать эту функцию в приложении Fix It, достаточно добавить класс, производный от DbConfiguration , и включить логику повторных попыток.

    // EF follows a Code based Configuration model and will look for a class that
// derives from DbConfiguration for executing any Connection Resiliency strategies
public class EFConfiguration : DbConfiguration
{
    public EFConfiguration()
    {
        AddExecutionStrategy(() => new SqlAzureExecutionStrategy());
    }
}

    Для База данных SQL исключений, которые платформа определяет как обычно временные ошибки, показанный код указывает EF повторить операцию до 3 раз с экспоненциальной задержкой отката между повторными попытками и максимальной задержкой в 5 секунд. Экспоненциальное отката означает, что после каждой неудачной попытки он будет ожидать более длительный период времени, прежде чем повторить попытку. Если три попытки в строке завершаются ошибкой, создается исключение. В следующем разделе, посвященном выключателям, объясняется, почему требуется экспоненциальная отката и ограниченное количество повторных попыток.

    При использовании службы хранилища Azure могут возникнуть аналогичные проблемы, как в приложении "Исправить" для BLOB-объектов, а в API клиента хранилища .NET уже реализована такая же логика. Вы просто указываете политику повторных попыток или даже не нужно делать это, если вы удовлетворены параметрами по умолчанию.

Выключатели

Существует несколько причин, по которым вы не хотите повторять слишком много раз в течение слишком длительного периода.

  • Слишком много пользователей постоянно повторяют неудачные запросы, что может понизить работу других пользователей. Если миллионы пользователей выполняют повторяющиеся запросы, вы можете привязывать очереди диспетчеризации IIS и запрещать приложению обслуживать запросы, которые в противном случае могли бы успешно обрабатываться.
  • Если все пользователи повторяют попытку из-за сбоя службы, в очереди может оказаться так много запросов, что служба будет переполнена, когда начнет восстанавливаться.
  • Если ошибка связана с регулированием и существует период времени, который служба использует для регулирования, то дальнейшие повторные попытки могут вывести это окно наружу и привести к продолжению регулирования.
  • Возможно, пользователь ожидает отрисовки веб-страницы. Заставляя людей ждать слишком долго может быть более раздражает, что относительно быстро советую им повторить попытку позже.

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

  • Пользовательский резервный вариант. Если вы не можете получить цену акций от Reuters, может быть, вы можете получить его от Bloomberg; Или, если вы не можете получить данные из базы данных, возможно, вы можете получить их из кэша.
  • Сбой без уведомления. Если то, что вам нужно от службы, не является "все или ничего" для вашего приложения, просто верните значение NULL, если вы не можете получить данные. Если вы отображаете задачу "Исправить", а служба BLOB-объектов не отвечает, вы можете отобразить сведения о задаче без изображения.
  • Быстрый сбой. Ошибка пользователя, чтобы избежать переполнения службы повторными запросами, которые могут привести к нарушению работы службы для других пользователей или расширению окна регулирования. Вы можете отобразить понятное сообщение "Повторите попытку позже".

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

Примеры политик повтора

Инструкции по База данных SQL политике повторных попыток см. в статье Устранение временных ошибок и ошибок подключения к База данных SQL.

Сводка

Стратегия повтора и отката может помочь сделать временные ошибки невидимыми для клиента большую часть времени, а корпорация Майкрософт предоставляет платформы, которые можно использовать для минимизации работы по реализации стратегии независимо от того, используете ли вы ADO.NET, Entity Framework или службу хранилища Azure.

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

Ресурсы

Дополнительные сведения см. в следующих ресурсах:

Документация

Видеоролики

Пример кода

НазадВперед