Методология 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 раз и отслеживается для каждой среды
Зависимости
Явное объявление и изолирование зависимостей
Зависимости приложения необходимо объявить явным образом, и все без исключения зависимости должны быть доступны из репозитория компонентов, который может загружаться с помощью такого диспетчера зависимостей, как 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. Приложениям не следует пытаться управлять хранилищем собственных регистрационных файлов. Вместо этого сбором и архивированием регистрационных записей для приложения должна заниматься среда выполнения.
Процессы администрирования
Запуск задач администрирования и управления в виде разовых процессов
Иногда у разработчиков приложения возникает потребность запустить разовые административные задачи. К таковым могут относиться миграции баз данных или запуск одноразовых сценариев, зарегистрированных в репозитории исходного кода приложения. Они считаются процессами администрирования. Подобные процессы для поддержания согласованности между средами должны запускаться в среде выполнения с помощью сценариев, зарегистрированных в репозитории.