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