Проектирование для обеспечения устойчивости
Рабочая нагрузка должна продолжать функционировать с полной или сокращенной функциональностью. |
|---|
Следует ожидать, что сбои компонентов, сбои платформы, снижение производительности и другие ошибки возникают. Создайте устойчивость в системе, чтобы она была устойчива к сбоям и могла корректно справляться с ухудшениями.
пример сценария
Contoso Air — это коммерческая авиакомпания, которая имеет собственный отдел разработки. Основное бизнес-приложение — это решение для бронирования, которое позволяет клиентам непосредственно бронировать авиарейсы через Contoso Air. Приложение встроено в Azure и использует службу приложений Azure, Cosmos DB, Функции Azure, Azure Logic Apps и служебную шину Azure.
Определение рисков сбоя
определить потенциальные точки сбоя в системе, особенно для критически важных компонентов, и определить влияние на потоки пользователей и системы.
Анализ случая сбоя, радиуса взрыва и интенсивности сбоя для каждой потенциальной точки сбоя. Случаи сбоя и их интенсивность могут варьироваться от относительно низких сценариев, таких как временная потеря внутреннего процесса до полномасштабных сбоев, вызванных авариями. Выполнение этого анализа помогает определить возможности обработки ошибок на уровне компонента.
проблема компании Contoso
- Приложение LOB предоставляет множество ключевых функций, начиная от маркетинга и до коммерции. Поток пользователя покупки билетов был определен как наиболее критически важный поток. Группа рабочей нагрузки определила, что следует реализовать более надежные меры, чтобы обеспечить оптимизацию потока для обеспечения устойчивости.
- Команда заложила время в бюджет на улучшения, такие как разъединение компонентов и перепроектирование потоков, но хочет убедиться, что они используют это время, чтобы сосредоточиться на улучшениях, приносящих наибольшую ценность.
Применение подхода и результатов
- Команда определяет внешний шлюз платежей как потенциальную точку сбоя. Шлюз имеет высокий уровень доступности, но существует потенциал для пользователей, испытывающих случайные временные ошибки, вызванные проблемами сети или всплесками чрезвычайно высоких запросов. Шлюз может отклонять некоторые запросы при перегрузке несколькими одновременными запросами.
- Команда определяет, что пользователи должны повторно отправить запросы, когда шлюз отклоняет свои первоначальные запросы, что приводит к отрицательному интерфейсу пользователя.
Реализация механизмов самосохранения
Развивайте способности к самосохранению, правильно используя шаблоны проектирования и модуляризуя проектирование для изоляции сбоев.
Создав возможности самосохранения в системе, вы сможете предотвратить проблему, влияющую на подчиненные компоненты. Система сможет устранить временные и постоянные сбои, узкие места производительности и другие проблемы, которые могут повлиять на надежность. Вы также сможете свести к минимуму радиус взрыва.
вызов Contoso
- Команда хочет свести к минимуму риск временных сбоев, из-за чего запросы пользователей будут отклонены шлюзом платежей. Из-за временного характера некоторых условий ошибки существует высокая вероятность, что один и тот же запрос будет успешно выполнен при повторной отправке.
Применение подхода и результатов
- Команда разрабатывает пользовательскую логику в рабочем процессе, чтобы повторить транзакцию после короткой задержки, когда обнаружен сбой, который можно повторить.
- Проект решения будет изменен, чтобы включить шаблон повторных попыток, немного увеличивая время ожидания между повторными попытками до тех пор, пока запрос не будет успешно обработан или достигнуто максимальное количество сбоев.
- Команда также решает разделить взаимодействие пользователей и функции внутренней обработки платежей этого потока с помощью подхода на основе событий с служебной шиной Azure. Если при обработке сообщения возникают неустранимые сбои (после максимального количества повторных попыток), серверный обработчик отказывается от обработки этого запроса, оставляя сообщение в очереди, чтобы его можно было повторно обработать позже.
Создание комплексной избыточности и устойчивости
Создавайте избыточность на различных уровнях и устойчивость на разных уровнях приложения.
Стремитесь к избыточности в физических ресурсах и немедленной репликации данных. Стремитесь к избыточности на функциональном уровне, охватывающем службы, операции и персонал. Избыточность помогает свести к минимуму отдельные точки сбоя. Например, если возникает сбой, влияющий на один или несколько компонентов, зону доступности или весь регион, избыточное (активно-активное или активно-пассивное) развертывание позволяет выполнять целевые показатели бесперебойной работы.
Добавление посредников предотвращает прямую зависимость между компонентами и улучшает буферизацию. Оба из этих преимуществ укрепляют живучесть системы.
вызов Contoso
- Реализация повторных попыток и отмена вызовов шлюза платежей из пользовательского интерфейса с помощью служебной шины значительно увеличила надежность этого потока, но заинтересованные лица бизнеса по-прежнему беспокоятся о потере данных, которые могут произойти из-за катастрофического сбоя в основном регионе.
Применение подхода и результатов
- Команда решает перейти на уровень "Премиум" служебной шины. Таким образом, они могут воспользоваться функциями поддержки зон доступности этого уровня. Благодаря этой функции несколько копий данных хранятся в трех физически разделенных объектах (зонах доступности), а служба имеет достаточно резервов емкости, чтобы мгновенно справиться с полной, катастрофической потерей центра обработки данных.
- Кроме того, команда настраивает аварийное восстановление Azure Service Bus Geo-Disaster для непрерывной репликации данных во вторичный регион, который будет использован в маловероятном случае полного отказа основного региона.