Для критически важных рабочих нагрузок
В этом разделе рассматриваются проблемы разработки критически важных рабочих нагрузок в Azure. Руководство основано на уроках, извлеченных из изучения многочисленных клиентских приложений и решений сторонних производителей. В этом разделе приведены практические и авторитетные рекомендации, которые применяют рекомендации по хорошо архитекторам в качестве технической основы для создания и работы высоконадежного решения в Azure в масштабе.
Что такое критически важная рабочая нагрузка?
Термин "рабочая нагрузка" относится к коллекции ресурсов приложений, которые поддерживают общую бизнес-цель или выполнение общего бизнес-процесса, с несколькими службами, такими как API и хранилища данных, работая вместе для обеспечения конкретных комплексных функциональных возможностей.
Термин "критически важный" относится к шкале критической важности, которая охватывает значительные финансовые затраты (критически важные для бизнеса) или затраты человека (критически важные для безопасности), связанные с недоступностью или недостаточной производительностью.
Поэтому критически важная рабочая нагрузка описывает коллекцию ресурсов приложений, которые должны быть высоконадежными на платформе. Рабочая нагрузка всегда должна быть доступной, устойчивой к сбоям и операционной работе.
Видео: критически важные рабочие нагрузки в Azure
Каковы распространенные проблемы?
Microsoft Azure упрощает развертывание облачных решений и управление ими. Однако создание критически важных рабочих нагрузок, которые являются высоконадежными на платформе, остается проблемой по следующим основным причинам:
Проектирование надежного приложения в масштабе является сложным. Для этого требуются обширные знания платформы, чтобы выбрать правильные технологии и оптимально настроить их для обеспечения комплексных функций.
Сбой неизбежен в любой сложной распределенной системе, поэтому решение должно быть разработано для обработки сбоев с соответствующими или каскадными последствиями. Это изменение мышления для многих разработчиков и архитекторов, входящих в облако из локальной среды; Проектирование надежности больше не является предметом инфраструктуры, но должно быть первым классом в процессе разработки приложений.
Для выполнения критически важных рабочих нагрузок требуется высокая степень строгости и зрелости на протяжении комплексного жизненного цикла инженерии, а также возможность учиться на сбоях.
Критически важна ли задача только о надежности?
Хотя основной задачей критически важных рабочих нагрузок является надежность, но при создании и эксплуатации критически важных рабочих нагрузок в Azure важное значение имеют другие основные принципы архитектуры.
Безопасность: как рабочая нагрузка устраняет угрозы безопасности, такие как атаки типа "Распределенный отказ в обслуживании" (DDoS), будут иметь значительное влияние на общую надежность.
Операционное превосходство: как рабочая нагрузка может эффективно реагировать на операционные проблемы, будет иметь непосредственное влияние на доступность приложений.
Эффективность производительности. Доступность является более простой, но, скорее, согласованный уровень службы приложений и производительности относительно известного работоспособного состояния.
Достижение высокой надежности приводит к значительным компромиссам затрат, которые могут быть оправданы для каждого сценария рабочей нагрузки. Поэтому рекомендуется, чтобы решения по проектированию были основаны на бизнес-требованиях.
Каковы ключевые области проектирования?
Критически важное руководство в рамках этой серии состоит из архитектурных рекомендаций и рекомендаций, ориентированных на эти ключевые области проектирования.
Области проектирования связаны друг с другом, и решения, принятые в рамках одной области, могут повлиять на решения по всему дизайну или повлиять на них. Мы рекомендуем читателям ознакомиться с этими областями проектирования, рассмотреть предоставленные рекомендации и рекомендации, чтобы лучше понять последствия охватываемых решений. Например, чтобы определить целевую архитектуру, важно определить, как лучше всего отслеживать работоспособности приложений в ключевых компонентах. В этом случае читатель должен просмотреть область проектирования моделирования работоспособности, используя описанные рекомендации, чтобы помочь в принятии решений.
| Область проектирования | Итоги |
|---|---|
| Проектирование приложений | Использование архитектуры единиц масштабирования в контексте создания высоконадежного приложения. Также изучите шаблоны проектирования облачных приложений, которые позволяют масштабировать и обрабатывать ошибки. |
| Платформа приложений | Факторы принятия решений и рекомендации, связанные с выбором, проектированием и настройкой соответствующей платформы размещения приложений, зависимостей приложений, платформ и библиотек. |
| Платформа данных | Выбор в технологиях хранилища данных, информированный оценкой требуемого объема, скорости, разнообразия, достоверности. |
| Сеть и подключение | Концепции топологии сети на уровне приложения, учитывая необходимые возможности подключения и избыточное управление трафиком. Критически важные рекомендации, предназначенные для информирования о разработке безопасной и масштабируемой глобальной топологии сети. |
| Моделирование работоспособности и наблюдаемость | Процессы для определения надежной модели работоспособности, сопоставления квалитифицированных состояний работоспособности приложений с помощью наблюдаемости и операционных конструкций для достижения операционной зрелости. |
| Развертывание и тестирование | Искоренение простоя и обслуживание работоспособности приложений для операций развертывания, предоставляя ключевые рекомендации и рекомендации, предназначенные для информирования о разработке оптимальных конвейеров CI/CD для критически важных приложений. |
| Безопасность | Защита приложения от угроз, предназначенных для прямого или косвенного компрометации ее надежности. |
| Операционные процедуры | Внедрение DevOps и связанных методов развертывания используется для обеспечения эффективных и согласованных операционных процедур. |
Иллюстративные примеры
Рекомендации, приведенные в этой серии, основаны на подходе, ориентированном на решение, для иллюстрации ключевых рекомендаций и рекомендаций по проектированию. Существует несколько эталонных реализаций, которые можно использовать в качестве основы для дальнейшей разработки решений.
Базовая архитектура приложения, доступного к Интернету. Предоставляет основу для создания собственного облачного приложения с высоким уровнем масштабирования в Интернете в Microsoft Azure. Рабочая нагрузка осуществляется через общедоступную конечную точку и не требует подключения частной сети к окружающему техническому ресурсу организации.
Ознакомьтесь с реализацией: критически важный для миссии интернет
Базовая архитектура приложения с доступом к Интернету с сетевыми элементами управления— расширяет базовую архитектуру строгими сетевыми элементами управления, чтобы предотвратить несанкционированный общедоступный доступ из Интернета к любому из ресурсов рабочей нагрузки.
Базовая архитектура в целевой зоне Azure— предоставляет основу для создания корпоративного облачного приложения в Microsoft Azure с помощью существующей сетевой инфраструктуры и частных конечных точек. Рабочая нагрузка требует частного подключения к другим ресурсам организации и принимает зависимость от предварительно предоставленных виртуальная сеть для подключения к другим ресурсам организации. Этот вариант использования предназначен для сценариев, требующих интеграции с более широким техническими средствами организации для общедоступных или внутренних рабочих нагрузок.
Ознакомьтесь с реализацией: критически важные для миссии подключения
Следующий шаг
Начните с изучения методологии проектирования для сценариев критически важных приложений.