Правила разработки облачных решений
Архитекторы разрабатывают рабочие нагрузки путем объединения служб платформы, функциональности и кода для выполнения функциональных и нефункциональных требований в рабочих нагрузках. Проектирование рабочих нагрузок требует понимания этих требований к рабочей нагрузке, а затем выбора топологий и подходов к решению проблем, представленных ограничениями рабочей нагрузки. Шаблоны облачной разработки, которые устраняют многие распространенные проблемы.
Проектирование систем тесно связано с шаблонами проектирования. Инфраструктура, код и распределенные системы предназначены для сочетания шаблонов проектирования. Эти шаблоны проектирования полезны для создания надежных, безопасных, экономичных, стабильных в эксплуатации и эффективных приложений в облаке.
Эти шаблоны проектирования не относятся к какой-либо технологии и относятся к какой-либо распределенной системе, независимо от того, размещена ли в Azure, других облачных платформах и некоторые могут даже распространяться на локальные или гибридные рабочие нагрузки.
Шаблоны проектирования облака помогают процессу разработки
Облачные рабочие нагрузки подвержены ошибкам распределенных вычислений. Ниже приведены некоторые примеры ошибки облачного дизайна:
- Сеть надежна
- Задержка равна нулю
- Пропускная способность ограничена
- Сеть безопасна
- Топология не изменяется
- Есть один администратор
- Управление версиями компонентов просто
- Реализация наблюдаемости может быть отложена
Шаблоны проектирования не устраняют такие понятия, как эти, но могут помочь повысить осведомленность, компенсации и устранение рисков. Каждый шаблон облака имеет собственные компромиссы. Вам нужно обратить внимание больше на то, почему вы выбираете определенный шаблон, чем как реализовать его.
Хорошо продуманная рабочая нагрузка учитывает, как эти отраслевые шаблоны проектирования должны использоваться в качестве основных строительных блоков для её проектирования. Каждый столп Azure Well-Architected представлен в этих шаблонах проектирования, часто приводя к компромиссам с целями других столпов.
Каталог шаблонов
Каждый шаблон в этом каталоге описывает проблему, с которыми обращается шаблон, рекомендации по применению шаблона и пример на основе Microsoft Azure. Некоторые шаблоны включают примеры кода или фрагменты кода, демонстрирующие реализацию шаблона в Azure.
Расписание | Итоги | Основные принципы платформы Azure Well-Architected Framework |
---|---|---|
Посредник | Создайте службы поддержки, которые отправляют сетевые запросы от имени службы обслуживания клиентов или приложения. |
|
Уровень защиты от повреждений | Реализуйте интерфейс или уровень адаптера между современным приложением и устаревшей системой. |
|
Асинхронные запросы и ответы | Выполняйте серверную обработку не на внешнем узле, где серверная обработка должна быть асинхронной и когда интерфейс требует четкого ответа. |
|
Отдельные серверные части для каждого интерфейса | Создайте отдельные бэкенд-сервисы, которые будут использоваться определёнными фронтенд-приложениями или интерфейсами. |
|
Распределительный блок | Изолируйте элементы приложения в пулы, чтобы при сбое один из них продолжал функционировать. |
|
Отдельно от кэша | Загрузите данные по запросу в кэш из хранилища данных. |
|
Хореография | Позвольте каждой службе самостоятельно определять, когда и как обрабатывать бизнес-операцию, не создавая зависимостей от центрального оркестратора. |
|
Автоматическое выключение | Обработка ошибок при подключении к удаленной службе или ресурсу, устранение которых может занять непредсказуемое количество времени. |
|
Проверка утверждений | Разделение большого сообщения на схему проверки утверждений и полезную нагрузку, чтобы избежать перегрузки в канале сообщений. |
|
Компенсирующие транзакции | Отмена работы с выполнением серии шагов, которые вместе определяют согласованную в конечном счете операцию. |
|
Конкурирующие потребители | Несколько конкурирующих потребителей обрабатывают сообщения, полученные в одном канале обмена сообщениями. |
|
Консолидация вычислительных ресурсов | Консолидация нескольких задач или операций в одном вычислительном модуле. |
|
CQRS | Вы можете разделить интерфейсы для операций считывания и записи данных. |
|
Метки развертывания | Развертывание нескольких независимых копий компонентов приложения, включая хранилища данных. |
|
Конфигурация рабочей нагрузки Edge | Централизация конфигурации для решения проблемы настройки нескольких систем и устройств на цеховом этаже. | |
Источник событий | Использование инкрементируемого хранилища для сохранения всей последовательности событий, то есть всех действий с данными в домене. |
|
Внешнее хранилище конфигурации | Переместите сведения о конфигурации из пакета развертывания приложения в централизованное расположение. |
|
Федеративная идентификация | Делегирование проверки подлинности внешнему поставщику удостоверений. |
|
Привратник | Защита приложений и служб с помощью выделенного экземпляра узла, который выполняет роль брокера между клиентами и приложением или службой, проверяет и очищает запросы, а также передает запросы и данные между ними. |
|
Агрегирование на шлюзе | Использование шлюза для объединения нескольких отдельных запросов в один общий. |
|
Перенесение в шлюз | Перенесение общих или специализированных функций служб на прокси-сервер шлюза. |
|
Маршрутизация шлюза | Используйте одну конечную точку при маршрутизации запросов к нескольким службам. |
|
Геоде | Развертывайте серверные службы в нескольких географических узлах, каждый из которых может обслуживать любой клиентский запрос в любом регионе. |
|
Мониторинг конечных точек работоспособности | Внедрение в приложение функциональных проверок, к которым внешние средства могут регулярно получать доступ через предоставленные конечные точки. |
|
Таблица индексов | Создание в хранилище данных индексов по полям, которые часто используются в запросах. |
|
Выбор лидера | Метод координации действий для коллекции экземпляров, объединенных совместной задачей в распределенном приложении: один экземпляр выбирается в качестве лидера, который отвечает за управление другими экземплярами. |
|
Материализованное представление | Создание предварительно заполненных представлений на основе данных из одного или нескольких хранилищ данных, когда данные не отформатированы для требуемых операций запросов. |
|
Бридж для обмена сообщениями | Создайте посредника, чтобы обеспечить связь между системами обмена сообщениями, которые в противном случае несовместимы из-за протокола или формата. |
|
Каналы и фильтры | Задачу, которая требует сложной обработки, можно разбить на ряд отдельных элементов для повторного использования при необходимости. |
|
Очередь с приоритетом | Запросы, отправляемые в службу, получают разные приоритеты. При этом запросы с высоким приоритетом принимаются и обрабатываются быстрее, чем запросы с низким приоритетом. |
|
Издатель/Подписчик | Настройка в приложении возможности асинхронно объявлять событие для нескольких объектов-получателей без взаимозависимости между отправителями и получателями. |
|
карантин | Убедитесь, что внешние ресурсы соответствуют согласованному команде уровню качества, прежде чем авторизовать их использование в рабочей нагрузке. |
|
Выравнивание нагрузки на основе очередей | Очередь выполняет роль буфера между задачей и службой, которую она вызывает, позволяя сгладить кратковременные всплески нагрузки. |
|
Шаблон ограничения скорости | Ограничивающий шаблон, помогающий избежать или минимизировать ошибки регулирования, связанные с этими ограничениями регулирования, а также для более точного прогнозирования пропускной способности. |
|
Повторить | Механизм обработки ожидаемых временных сбоев, при котором приложение повторно подключается к службе или сетевому ресурсу, обращение к которым завершилось сбоем, не прерывая потока событий. |
|
Сага | Управление согласованностью данных в микрослужбах в сценариях распределенных транзакций. Сага — это последовательность транзакций, которые обновляют каждую службу и публикуют сообщение или событие для активации следующего шага транзакции. |
|
Планировщик, агент, контролер | Координируйте ряд действий в распределенном наборе служб и других удаленных ресурсов. |
|
Последовательная передача | Обработка набора связанных сообщений в определенном порядке без блокирования обработки других групп сообщений. |
|
Сегментирование | Вы можете разделить хранилище данных на несколько горизонтальных секций, которые называются сегментами. |
|
Расширение | Чтобы обеспечить изоляцию и инкапсуляцию, развертывайте компоненты приложения в отдельном процессе или контейнере. |
|
Размещение статического содержимого | Разверните статическое содержимое в облачной службе хранения для предоставления непосредственно клиенту. |
|
Подавление | Пошаговая миграция устаревшей системы с постепенной заменой определенных компонентов новыми приложениями и службами. |
|
Регулирование | Контролируйте потребление ресурсов, используемых экземпляром приложения, отдельным клиентом или всей службой. |
|
Ключ камердинера | Использование токена или ключа, который предоставляет клиентам ограниченный доступ к определенному ресурсу или службе. |
|
Следующий шаг
Рассмотрите шаблоны проектирования с точки зрения столпа Azure Well-Architected, который они стремятся оптимизировать.
- Дизайн-паттерны для поддержки столпа надежности
- Шаблоны проектирования для поддержки столпа безопасности
- Шаблоны проектирования для поддержки столпа оптимизации затрат
- Шаблоны проектирования для поддержки принципа операционного совершенства
- Паттерны проектирования для поддержки столпа эффективности производительности