12-ти факторная модель создания облачных приложений

Doc

Doc

АйТишник со стажем... Профиль автора.

12-ти факторная модель разработки приложений в облакеМетодология 12 факторов представляет собой популярный набор принципов созда­ния облачных приложений, составленный создателями облачной платформы Heroku. Twelve-Factor Арр — сайт, изначально созданный Адамом Виггинсом (Adam Wiggins), соучредителем Heroku, в виде манифеста с описанием SaaS-приложений, разрабо­танных с целью получить преимущества от использования приемов, свойственных современным облачным платформам.

На  их сайте  методология начинается с описания набора ключевых основополагающих идей по созданию приложений.



Ранее в блогах мы обсуждали перспективы, которые платформа дает пользовате­лям, создающим приложения. В табл. 1.1 представлен набор идей, точно определя­ющих ценные предложения по созданию приложений и следующих методологии 12 факторов. Идеи разбиваются еще и на набор требований — на 12 отдельных факторов, выделяющих суть этих ключевых идей в коллекцию советов по способам создания приложений.

Таблица 1. Ключевые идеи 12-факторных приложений

  • Использование декларативных форматов для автоматизации установок и настроек в целях сведения к минимуму времени и усилий присоединяющихся к проекту новых разработчиков
  • Заключение четких соглашений с базовой операционной системой, предусматривающих максимальную переносимость между средами выполнения
  • Обеспечение должного развертывания па современных облачных платформах, избавляющего от необходимости использовать серверы и системное администрирование
  • Сведение к минимуму отступлений развертывания от эксплуатации с целью предоставить возможность непрерывного развертывания, позволяющего достичь максимальной адаптации к новым условиям
  • Предоставление возможности масштабирования без существенных изменений архитектуры, а также практики применения оснастки или развертывания

Все 12 факторов, перечисленных в табл. 2, описывают требования, способ­ствующие созданию приложений, использующих идеи, изложенные в табл. 1. Двенадцать факторов — базовый набор требований, которые могут применяться в целях создания приложений, оптимизированных для работы в облачной среде. Поскольку факторы охватывают широкий круг вопросов, касающихся самых распространенных приемов во всех современных облачных платформах, создание 12-факторных приложений есть общая отправная точка в разработке облачных приложений.

Таблица 2. Приемы создания 12-факторных приложений

Кодовая база

Использование одной кодовой базы, отслеживаемой в системе контроля версий при множестве развертываний

Зависимости

Явное объявление и изолирование зависимостей

Конфигурация

Сохранение конфигурации в среде

Вспомогательные сервисы

Отношение к вспомогательным сервисам как к подключенным ресурсам

Сборка, выпуск, практическое применение

Четкое разделение стадий сборки и практического применения

Процессы

Выполнение приложения в виде одного или нескольких процессов, не использующих состояния

Привязка портов

Экспорт сервисов через привязку портов

Многопоточное выполнение

Горизонтальное масштабирование с помощью модели процесса

Утилизируемость

Максимальная надежность за счет быстрого запуска и корректного завершения работы

Функциональная совместимость разработки и практического применения

Максимально возможная схожесть разработки, доводки и практического применения

Ведение регистрационных записей

Отношение к регистрационным записям как к потокам событий

Процессы администрирования

Запуск задач администрирования и управления в виде разовых процессов

Кроме информации на сайте, посвященном 12-факторным приложениям, подробно описывающей каждый из них, дальнейшему раскрытию каждого требования были посвящены целые книги. Методология 12 факторов теперь используется в от­дельных прикладных средах, чтобы помочь разработчикам выполнить требования некоторых или даже абсолютно всех 12 факторов.

В данной книге методология 12 факторов будет применяться для описания кон­кретных особенностей Spring-проектов, реализованных с целью следовать данному стилю разработки приложений. Так что сейчас важно предоставить краткое изло­жение каждого из этих факторов.

 

Кодовая база

Одна кодовая база, отслеживаемая в системе контроля версий при множестве развертываний

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

Исходный код создается 1 раз и отслеживается для каждой среды 

Рис. 1Исходный код создается 1 раз и отслеживается для каждой среды

 

Зависимости

Явное объявление и изолирование зависимостей

Зависимости приложения необходимо объявить явным образом, и все без исклю­чения зависимости должны быть доступны из репозитория компонентов, который может загружаться с помощью такого диспетчера зависимостей, как Apache Maven.

Двенадцатифакторные приложения никогда не полагаются на существование под­разумеваемых общесистемных пакетов, требуемых в качестве зависимостей для запуска приложений. Все зависимости приложения объявляются в явном виде в файле манифеста, в котором приводится четкое описание всех подробностей каждой ссылки.

 

Конфигурация

Сохранение конфигурации в среде

Код приложения нужно полностью отделить от конфигурации. Последняя должна определяться средой.

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

Как показано на рис. 2, любое отклонение в вашем приложении от среды к среде рассматривается в качестве конфигурации среды и должно быть сохранено в среде, а не с приложением.


Приложение двенадцати факторов

Выделение конфигурации, специфичной для среды, в саму среду

Рис. 2. Выделение конфигурации, специфичной для среды, в саму среду

 

Вспомогательные сервисы

Отношение к вспомогательным сервисам как к подключенным ресурсам

К вспомогательному относится любой сервис, используемый 12-факторным при­ложением в качестве части его обычной работы. Примерами таких сервисов могут послужить базы данных, веб-сервисы RESTful, управляемые через API, SMTP- или FTP-сервер.

Вспомогательные сервисы считаются ресурсами приложения. Эти ресурсы под­ключены к приложению в течение всего периода его практического применения. Развертывание 12-факторного приложения должно быть рассчитано на замену встроенной базы SQL в среде тестирования внешней базой данных MySQL, размещенной в среде доводки, без внесения изменений в код приложения.

 

Сборка, выпуск, практическое применение

Четкое разделение стадий сборки и практического применения

В 12-факторном приложении имеется четко выраженное разделение стадий сбор­ки, выпуска и практического применения.

  • Стадия сборки. Происходит либо компиляция исходного кода приложения, либо его сборка в пакет. Созданный пакет называется сборкой.
  • Стадия выпуска. Сборка объединяется со своей конфигурацией. Затем выпуск, созданный для развертывания, готов для работы в среде выполнения. Каждый выпуск должен иметь уникальный идентификатор, использующий либо семан­тическое обозначение версии, либо метку времени. Каждый выпуск нужно до­бавить к каталогу, который может использоваться инструментами управления выпусками для отката на предыдущий выпуск.
  • Стадия практического применения. На данной стадии, зачастую называемой временем выполнения (runtime), приложение в виде выбранного выпуска запускается в среде выполнения.

Разбиение этой стадии на отдельные процессы позволяет устранить возможность изменения кода приложения во время выполнения. Единственным способом изменить код остается запуск стадии сборки для создания нового выпуска или запуск отката для развертывания предыдущего выпуска.

 

Процессы

Выполнение приложения в виде одного или нескольких процессов, не исполь­зующих состояния

Двенадцатифакторные приложения создаются без расчета на использование со­стояния и с прицелом на архитектуру без совместно используемых ресурсов. Этим приложениям присуща лишь возможная зависимость от вспомогательного сервиса. Примерами таких сервисов, предоставляющих средства сохранения данных, могут послужить базы данных или хранилища объектов. Все ресурсы подключаются к при­ложению во время выполнения в качестве вспомогательного сервиса. Лакмусовой бу­мажкой, показывающей, применяет ли приложение состояние, является возможность демонтажа и повторного создания среды выполнения без какой-либо потери данных.

Двенадцатифакторные приложения не сохраняют состояние на локальной файло­вой системе в среде выполнения.

 

Привязка портов

Экспорт сервисов через привязку портов

Двенадцатифакторные приложения полностью автономны, то есть им в ходе вы­полнения для внедрения в среду выполнения с целью создания интернет-сервиса
веб-сервер не требуется. Каждое приложение откроет к себе доступ через порт HTTP, который привязан к приложению в среде выполнения. В ходе разверты­вания уровень маршрутизации будет обрабатывать поступающие из открытого имени хоста входящие запросы, направляя их к среде выполнения приложения, в привязки НТТР-порта.

Джошу Лонгу, одному из соавторов этой книги, в сообществе Java приписывается изречение: «Make JAR not WAR» («Создавайте не WAR, a JAR»). Джош использует данное выражение, чтобы объяснить, как в сборочном JAR-файле самые новые Spring-приложения могут встраивать такой сервер Java-приложения, как Tomcat.

 

Многопоточное выполнение

Горизонтальное масштабирование с помощью модели процесса

Приложения должны быть пригодны к масштабированию процессов или потоков для параллельного выполнения работы по требованию. JVM-приложения могут автоматически справляться с оперативным распараллеливанием с помощью не­скольких потоков.

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

Двенадцатифакторные приложения должны также иметь возможность горизон­тального масштабирования и обработки запросов по сбалансированности нагрузки между несколькими идентичными выполняемыми экземплярами приложения. От­каз от использования состояний в конструкции приложений позволяет справлять­ся с более тяжелыми нагрузками с помощью горизонтального масштабирования приложений по нескольким узлам.

 

Утилизируемость

Максимальная надежность за счет быстрого запуска и корректного завершения работы

Процессы 12-факторных приложений спроектированы с прицелом на утилизиру­емость. Приложение в ходе выполнения процесса может быть остановлено в любое время и при этом достойно справиться с утилизацией процессов.

Процессы приложения должны максимально сократить время запуска. Приложе­ниям следует запускаться за несколько секунд и приступать к обработке входящих
запросов. Быстрые запуски сокращают время масштабирования экземпляров при­ложений в ответ на увеличение нагрузки.

Если процессы приложения запускаются долго, то могут ограничить доступность при большом объеме трафика, который способен перегрузить все доступные нормально действующие экземпляры приложения. При уменьшении времени запуска приложений до нескольких секунд его вновь вводимые в общую работу экземпляры получают возможность быстрее реагировать на непредсказуемые резкие скачки трафика без снижения доступности или производительности.

 

Функциональная совместимость разработки и практического применения

Максимально возможная схожесть разработки, доводки и эксплуатации

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

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

 

Ведение регистрационных записей

Отношение к регистрационным записям как к потокам событий

Двенадцатифакторные приложения ведут регистрационные записи в виде упорядо­ченного потока событий в стандартное устройство вывода stout. Приложениям не следует пытаться управлять хранилищем собственных регистрационных файлов. Вместо этого сбором и архивированием регистрационных записей для приложения должна заниматься среда выполнения.

 

Процессы администрирования

Запуск задач администрирования и управления в виде разовых процессов

Иногда у разработчиков приложения возникает потребность запустить разовые административные задачи. К таковым могут относиться миграции баз данных или запуск одноразовых сценариев, зарегистрированных в репозитории исходного кода приложения. Они считаются процессами администрирования. Подобные процессы для поддержания согласованности между средами должны запускаться в среде вы­полнения с помощью сценариев, зарегистрированных в репозитории.

 

  

Вас заинтересует / Intresting for you:

Принципы разработки и архитект...
Принципы разработки и архитект... 2633 просмотров Дэйзи ак-Макарова Sat, 29 May 2021, 15:25:47
Надежды, связанные с платформо...
Надежды, связанные с платформо... 2748 просмотров Илья Дергунов Thu, 27 Sep 2018, 12:34:48
Cisco: сокращения при вводе ко...
Cisco: сокращения при вводе ко... 2710 просмотров Андрей Волков Wed, 17 Feb 2021, 16:35:17
Версии операционной системы Ci...
Версии операционной системы Ci... 2899 просмотров Валерий Павлюков Wed, 09 Oct 2019, 17:24:12
Войдите чтобы комментировать

 аватар
ответил в теме #10923 1 год 2 мес. назад
indomethacin cheap cheap indomethacin 50mg indomethacin for sale
ildergun аватар
ildergun ответил в теме #10739 1 год 5 мес. назад
Классика! Хорошее описание модели. Спасибо!
admin аватар
admin ответил в теме #10289 2 года 3 мес. назад
Тема раскрыта отлично. Зачет!