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