Лекция 6. Архитектура облачного приложения

Архитектура облачного приложения1План• Cloud Application Design Considerations• Cloud Application Reference Architectures• Design Methodologies• Data Storage• Data Analytics• Развертывание и управлениеВопросы проектирования облачныхприложений• Масштабируемость-Масштабируемость является важным фактором, который побуждает разработчиков приложений переходить к облачнымвычислениям.

Создание приложений, которые могут обслуживать миллионы пользователей без ущерба для ихпроизводительности, всегда было сложной задачей. С ростом разработчиков облачных вычислений разработчики могутпредоставить достаточные ресурсы для удовлетворения своих уровней рабочей нагрузки.• Надежность и Доступность-Надежность системы определяется как вероятность того, что система будет выполнять предполагаемые функции вуказанных условиях в течение определенного периода времени.

Доступность - это вероятность того, что система будетвыполнять заданную функцию в заданных условиях в заданное время.• Защита-Безопасность является важным аспектом проектирования для облачных приложений, учитывая аутсорсинговый характерсреды облачных вычислений.• Техническое обслуживание и модернизация-Чтобы достичь быстрого выхода на рынок, компании обычно запускают свои приложения с готовым набором основныхфункций, а затем поэтапно добавляют новые функции по мере их завершения. В таких сценариях важно проектироватьприложения с низкими расходами на техническое обслуживание и модернизацию.Примеры архитектур –Электронная коммерция, бизнес-приложения длябизнеса, банковские и финансовые приложения• Уровень балансировки-Уровень балансировки нагрузки состоитиз одного или несколькихбалансировщиков нагрузки.• Уровень приложения--Для этого уровня рекомендуетсянастроить автоматическоемасштабирование.Автомасштабирование может бытьзапущено, если записанные значения длялюбого из указанных показателей, такихкак загрузка процессора, использованиепамяти и т.д., Превышают определенныеПримеры архитектур –Приложения для доставки контента• На рисунке показана типичная архитектураразвертывания для приложений доставки контента,таких как фотоальбомы онлайн, веб-трансляция видео ит.

Д.• В этом развертывании показаны как реляционные, так инереляционные хранилища данных.• Для доставки носителей используется сеть доставкиконтента (CDN), которая состоит из глобальной сетипограничных расположений.• CDN используется для ускорения доставки статическогоконтента, такого как изображения и видео.Примеры архитектур –Приложения для аналитики данных• На рисунке показана типичная архитектураразвертывания для приложений с интенсивнымвычислением, таких как Data Analytics, MediaTranscoding и т.

Д.• Состоит из веб-приложений, хранилищ, вычислений /аналитики и уровней базы данных.• Уровень аналитики состоит из облачныхраспределенных пакетных платформ обработкиданных, таких как Hadoop, которые подходят дляанализа больших данных.• Задания анализа данных (например, MapReduce)отправляются на уровень аналитики с серверовприложений.• Задания ставятся в очередь для выполнения, и позавершении анализируемые данные представляются ссерверов приложений.Service Oriented Architecture• Сервис-ориентированная архитектура (SOA) - это хорошозарекомендовавший себя архитектурный подход для проектированияи разработки приложений в виде сервисов, которые могут совместноиспользоваться и повторно использоваться.• SOA представляет собой набор дискретных программных модулей илисервисов, которые составляют часть приложения и в совокупностиобеспечивают функциональность приложения.• Службы SOA разрабатываются в виде слабосвязанных модулей безвстроенных в службы аппаратных вызовов.• Эти службы обмениваются сообщениями друг с другом.• Службы описываются с помощью языка описания веб-служб (WSDL).• WSDL - это язык описания веб-сервисов на основе XML, которыйиспользуется для создания описаний служб, содержащих информациюо функциях, выполняемых службой, и входах и выходах службы.SOA Layers•Бизнес-системы-•Компоненты службы-•Композитные службы могут быть организованы для создания бизнес-процессовболее высокого уровня.

В этих слоях определяются композиции и оркестровкисоставных сервисов для создания бизнес-процессов.Презентационные услуги-•Это крупномасштабные службы, которые состоят из двух или болеекомпонентов обслуживания. Композитные службы могут использоваться длясоздания компонентов масштаба предприятия или отдельных компонентовбизнес-единицы.Управляемые бизнес-процессы-•Компоненты службы позволяют вышеперечисленным уровнямвзаимодействовать с бизнес-системами.

Компоненты сервиса несутответственность за реализацию функциональности предоставляемых услуг.Композитные услуги-•Этот уровень состоит из заказных встроенных приложений и унаследованныхсистем, таких как Enterprise Resource Planning (ERP), CRM (Управлениевзаимоотношениями с клиентами), Supply Chain Management (SCM) и т.

д.Это самый верхний уровень, который включает пользовательские интерфейсы,предоставляющие пользователям сервисы и организованные бизнес-процессы.Корпоративная служебная шина-Этот уровень объединяет службы с помощью адаптеров, маршрутизации,преобразования и обмена сообщениями.Cloud Component Model• Cloud Component Model - это методология проектирования приложений, котораяобеспечивает гибкий способ создания облачных приложений в быстром, удобном инезависимом от платформы режиме.• CCM - это архитектурный подход для облачных приложений, который не привязан ккакому-либо определенному языку программирования или облачной платформе.• Облачные приложения, разработанные с использованием подхода CCM, могут иметьразвернуты в гибридных облаках, в которых различные компоненты приложения могутбыть развернуты в облачной инфраструктуре и платформах различных поставщиковоблачных решений.• Приложения, разработанные с использованием CCM, обладают большей мобильностью ифункциональной совместимостью.• Приложения на основе CCM обладают лучшей масштабируемостью благодаря развязкекомпонентов приложения и обеспечению асинхронных механизмов связи.CCM Application Design Methodology• Подход CСM к разработкеприложений включает:-Проектирование компонентовАрхитектурный дизайнДизайн развертыванияCCM Component Design• Модель облачного компонента создается дляприложения на основе всестороннего анализа функцийи строительных блоков приложения.• Модель облачных компонентов позволяетидентифицировать строительные блоки облачногоприложения, которые классифицируются на основаниивыполняемых функций и типа требуемых облачныхресурсов.• Каждый строительный блок выполняет набор действийдля получения желаемых результатов для другихкомпонентов.• Каждый компонент берет определенные входы,выполняет заранее определенный набор действий ивыдает желаемые результаты.• Компоненты предлагают свои функции в качествесервисов через функциональный интерфейс, которыйможет использоваться другими компонентами.• Компоненты сообщают о своей производительностибазе данных производительности через интерфейспроизводительности.CCM map for an e-Commerce applicationCCM Architecture Design• In Architecture Design step, interactionsbetween the application components aredefined.• CCM components have the followingcharacteristics:• Loose Coupling• Components in the Cloud Component Model areloosely coupled.-Асинхронная связьlРазрешая асинхронную связь междукомпонентами, можно добавить емкость,добавив дополнительные серверы, когданагрузка приложения возрастает.Асинхронная связь становится возможнойблагодаря использованию очередейсообщений.Architecture design of an e-Commerce application.CCM Deployment Design• На этапе разработки развертывания компонентыприложения сопоставляются с конкретнымиоблачными ресурсами, такими как веб-серверы,серверы приложений, серверы баз данных и т.

Д.• Поскольку компоненты приложения разработаныс учетом их асинхронной связи и не зависят отсостояния, компоненты могут быть развернутынезависимо друг от друга.• Такой подход упрощает миграцию компонентовприложения из одного облака в другое.• Благодаря такой гибкости в разработке иразвертывании приложений разработчикиприложений могут обеспечить соответствиеприложений требованиям производительности изатрат при изменении контекстов.Deployment design of an e-Commerce applicationModel View Controller• Model View Controller (MVC) is a popular software design pattern for web applications.• Model-• View-Модель управляет данными и поведением приложений.

Модель обрабатывает события, отправленные контроллером. Модель не имеет информации опредставлениях и контроллерах. Модель реагирует на запросы информации о своем состоянии (из представления) и отвечает на инструкции поизменению состояния (от контроллера).Представление готовит интерфейс, который отображается пользователю.

Пользователи взаимодействуют с приложением через представления.Представления представляют информацию о том, что модель или контроллер сообщают представление пользователю, а также обрабатывают запросыпользователей и отправляют их контроллеру.• Controller-Контроллер обрабатывает запросы пользователей и обновляет модель, когда пользователь манипулирует представлением. Контроллер также обновляетпредставление при изменении модели.Topology and Orchestration Specificationfor Cloud Applications (TOSCA)16 января 2014 года технический комитет OASIS TOSCA утвердил TOSCA 1.0 в качестве стандарта.Цель проекта TOSCA — создать стандарт длявзаимодействия облачных платформ. Идеястандарта состоит в том, чтобы избежатьзависимости от конкретного поставщика (vendor lockin), которая возникает из-за использованиямножества «облачных» API и слишком разрозненныхтехнологий безопасности, управления исовместимостиOASIS TOSCAПохожиепроекты• HOT– HeatOrchestrationTemplate– Declarative– YAML• TOSCA– Topology&OrchestrationStandardforCloudApplication– Declarative&Imperative– XMLandnowYAMLСходства• Структурныесходства:– Описание– Входныеивыходныепараметры–• Проектированиекомпонентов-компонентявляетсяобъектомтипазависитотдругихкомпонентовимеетконфигурацию/начальноесостояниевформатесвойствРазличие• Жизненныйцикл– HOTимеетограниченныйжизненный– TOSCAиспользуетинтерфейсыдля• Поддержкаработыприложения– HOT100%декларативным.– TOSCAиспользуетлюбыеинтерфейсыдлялюбогоописаниялюбогопроцесса.SugarCRMExampleHOTLanguageTypesTemplatesTypeRelationshipScriptDepends_onOS::Nova::ServerSugar_CRM_VMOS::Heat::software_configHosted_onConnects_toapacheSugar_CRM_AppmySQLSugar_CRM_DBОписание инфраструктуры и самой функцииinputs:add_or_del:type: stringconstraints:- valid_values: [add, del]ip_or_url:type: stringnode_templates:firewall:type: tosca.nodes.ImprovedSoftwareComponentrequirements:- host: serverinterfaces:Standard:create:implementation: scripts/vnf_firewall.shinputs:param1: createproperties:actions:configure_firewall:program:implementation: scripts/vnf_firewall.shinputs:param1: { get_input: add_or_del }param2: { get_input: ip_or_url }get_configuration:program:implementation: scripts/vnf_firewall.shinputs:param1: showoutputs:configuration:type: stringserver:type: tosca.nodes.ImprovedComputeattributes:ports:in: port1out: port1capabilities:host:properties:disk_size: 10 GBmem_size: 2048 MBnum_cpus: 1properties:os_image: tosca_zabport1:type: tosca.nodes.network.Port.