12-Factor App

Двенадцатифакторное приложение (12-Factor App) — это методология разработки приложений, предложенная инженерами Heroku. Она описывает набор из 12 принципов, которые помогают создавать программное обеспечение, подходящее для облачных сред.

Основные цели этой методологии:

• Простое масштабирование.
• Портативность между средами.
• Упрощение разработки и развертывания.

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

Принципы двенадцатифакторного приложения

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

Думал, а как можно нарушить этот принцип. И вспомнил случай. После переименования сервиса в GitLab пришлось сделать для одного стенда форк репозитория, чтобы собраться со старым названием для фикса. Это было связано с тем, что все стенды зависели от названия репозитория, поэтому было невозможно переименовать сервис только для одного стенда.

Зависимости. Явное объявление и изоляция зависимостей. Используйте менеджеры зависимостей.

Конфигурация. Храните конфигурацию отдельно от кода. Используйте переменные окружения для настройки среды. Пример: URL базы данных, секреты или ключи API задаются через ENV, а не в коде.

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

Сборка, выпуск, выполнение. Четкое разделение стадий: сборка приложения, создание релиза и его выполнение.

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

Stateless. Приложение не должно хранить данные или состояние внутри процессов. Все состояния хранятся во внешних ресурсах. Пример: Сессии пользователей сохраняются в Redis, а не в оперативной памяти приложения. Если процесс падает или перезапускается, состояние не теряется, так как оно хранится в Redis, базе данных или другой внешней системе.

Привязка портов. Приложение экспортирует HTTP (или другой) сервис через привязанный порт.

Параллелизм. Процессы должны быть разделены на масштабируемые модули.

Среда разработки = среда продакшена. Минимизируйте различия между стендами разработки и продакшеном.

Журналирование. Приложение пишет события в поток вывода (stdout), а обработкой логов занимается внешняя система. Пример: Логи собираются через Elasticsearch или Datadog.

Административные задачи. Запускайте административные задачи, такие как миграции базы данных, вместе с запуском сервиса.

Мета информация

Область:: 00 Микросервисная архитектура
Родитель::
Источник::
Создана:: 2024-12-08
Автор::

Дополнительные материалы

Дочерние заметки