Архитектура 12-факторов приложений,12 Factor App

Создание приложений, работающих в веб-масштабе, - тяжелая работа. Риски есть повсюду - от остановки приложения из-за перегрузки сети до захвата вашей доли рынка конкурентом из-за того, что он получает больше кода, и до требовательных пользователей быстрее, чем вы можете. Любое преимущество, которое вы можете получить, чтобы лучше и быстрее создавать рабочий код в веб-масштабе, идет вам на пользу.

К счастью, проблемы работы в веб-масштабе хорошо известны. Есть решения. Одно из них - приложение « 12 факторов» , опубликованное в 2011 году Адамом Виггинсом. Приложение «12 факторов» - это набор принципов, описывающих способ создания программного обеспечения, при соблюдении которого компании могут создавать код, который можно надежно выпускать, быстро масштабировать и поддерживать согласованным и предсказуемым образом.

Ниже приводится краткое изложение принципов работы приложения «12 факторов».

I. Кодовая база

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

Изображение

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

II. Зависимости

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

Изображение

Принцип зависимостей утверждает, что в системе управления версиями хранится только код, который является уникальным и имеет отношение к цели приложения. На внешние артефакты, такие как пакеты Node.js, файлы Java .jar или .NET DLL, следует ссылаться в манифесте зависимостей, загружаемом в память во время разработки, тестирования и производственной среды выполнения. Вы не хотите хранить артефакты вместе с исходным кодом в репозитории исходного кода.

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

Хранить конфигурацию в среде

Изображение

Принцип конфигурации утверждает, что информация о конфигурации вводится в среду выполнения как переменные среды или как параметры, определенные в независимом файле конфигурации. Хотя в некоторых случаях допустимо хранить параметры по умолчанию, которые можно переопределить непосредственно в коде, такие параметры, как номер порта, URL-адреса зависимостей и параметры состояния, такие как DEBUG, должны существовать отдельно и применяться при развертывании. Хорошими примерами внешних файлов конфигурации являются файл свойств Java, файл манифеста Kubernetes или файл docker-compose.yml .

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

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

Рассматривайте вспомогательные сервисы как прикрепленные ресурсы

Изображение

Принцип вспомогательных сервисов побуждает архитекторов рассматривать внешние компоненты, такие как базы данных, почтовые серверы, брокеры сообщений и независимые сервисы, которые могут быть предоставлены и поддержаны системным персоналом, как присоединенные ресурсы. Об этом говорит сайт https://intellect.icu . Рассмотрение ресурсов как вспомогательных услуг способствует гибкости и эффективности жизненного цикла разработки программного обеспечения (SDLC).

V. Сборка, выпуск, запуск

Строго отдельные этапы сборки и запуска

Изображение

Принцип сборки, выпуска и запуска разбивает процесс развертывания на три воспроизводимых этапа, которые можно создать в любое время. На этапе сборки код извлекается из системы управления исходным кодом и встраивается / компилируется в артефакты, хранящиеся в репозитории артефактов, таком как Docker Hub или репозиторий Maven. После создания кода настройки конфигурации применяются на этапе выпуска . Затем, в Run стадии, среда времени выполнения скриптов , предусмотренная через с помощью такого инструмента, как анзибль. Приложение и его зависимости развертываются во вновь подготовленной среде выполнения.

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

VI. Процессы

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

Изображение

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

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

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

Изображение

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

Основная идея, лежащая в основе принципа привязки портов, заключается в том, что единообразное использование номера порта - лучший способ представить процесс в сети. Например, появились шаблоны, в которых порт 80 является обычным для веб-серверов, работающих под HTTP, порт 443 - это номер порта по умолчанию для HTTPS, порт 22 - для SSH, порт 3306 - порт по умолчанию для MySQL, а порт 27017 - это порт. порт по умолчанию для MongoDB.

VIII. Параллелизм

Масштабирование в технологическом режиме

Изображение

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

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

IX. Одноразовость

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

Принцип Disposability утверждает, что приложения должны запускаться и останавливаться плавно. Это означает выполнение всей необходимой «уборки» до того, как приложение станет доступным для потребителей. Например, плавный запуск гарантирует, что все подключения к базе данных и доступ к другим сетевым ресурсам будут в рабочем состоянии. Кроме того, были выполнены любые другие необходимые работы по настройке.

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

X. Разарботка / продакшн паритет

Сделайте разработку, стейджинг и производство как можно более похожими

Изображение

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

На рисунке выше показаны две версии кода приложения. Версия V1 предназначена для выпуска в производственной среде. Новая версия V2 предназначена для среды разработки. И V1, и V2 следуют одинаковому пути развертывания: от сборки до выпуска и затем запуска . Если версия кода V2 будет сочтена готовой к производству, артефакты и настройки, относящиеся к версии 2, НЕ будут скопированы в производственную среду.

Скорее, процесс CI / CD будет скорректирован, чтобы установить цель развертывания V2 на Production. Процесс CI / CD будет следовать ожидаемому шаблону сборки, выпуска и запуска по направлению к этой новой цели.

Как видите, Dev / Prod Parity очень похож на Build, Release и Run . Важное различие заключается в том, что Dev / Prod Parity обеспечивает тот же процесс развертывания для производственной среды, что и для разработки.

XI. Логирование

Рассматривайте логирование как потоки событий

Изображение

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

XII. Админ-процессы

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

Изображение

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

Изображение

Однако, несмотря на то, dataSeederчто это административный процесс, ему предоставляется путь развертывания сборки, выпуска и запуска, аналогичный сервису заказов. Также он выпущен по принципам Codebase и Dev / Prod Parity . Процесс администрирования dataSeederне отделен от общего SDLC, а скорее является его частью.

Выводы

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

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

Вау!! 😲 Ты еще не читал? Это зря!

• DDD
• SOLID
• Don’t repeat yourself
• GRASP
• KISS
• YAGNI