5.7 KiB
aliases | tags | date | |||
---|---|---|---|---|---|
|
|
2024-12-08 |
Двенадцатифакторное приложение (12-Factor App) — это методология разработки приложений, предложенная инженерами Heroku. Она описывает набор из 12 принципов, которые помогают создавать программное обеспечение, подходящее для облачных сред.
Основные цели этой методологии:
- Простое масштабирование.
- Портативность между средами.
- Упрощение разработки и развертывания.
Эти принципы применимы ко всем видам приложений, но особенно полезны для веб-приложений и микросервисов.
Принципы двенадцатифакторного приложения
Единая кодовая база должна управляться в системе контроля версий и использоваться во всех средах. Все ветки и деплойменты одного микросервиса привязаны к одному репозиторию. Не должно быть такого, чтобы на один стенд деплой происходил из одного репозитория, а на другой из другого.
Думал, а как можно нарушить этот принцип. И вспомнил случай. После переименования сервиса в GitLab пришлось сделать для одного стенда форк репозитория, чтобы собраться со старым названием для фикса. Это было связано с тем, что все стенды зависели от названия репозитория, поэтому было невозможно переименовать сервис только для одного стенда.
Зависимости. Явное объявление и изоляция зависимостей. Используйте менеджеры зависимостей.
Конфигурация. Храните конфигурацию отдельно от кода. Используйте переменные окружения для настройки среды. Пример: URL базы данных, секреты или ключи API задаются через ENV, а не в коде.
Внешние ресурсы. Базы данных, очереди, файловые хранилища рассматриваются как прикрепляемые ресурсы. Пример: База данных PostgreSQL или очередь RabbitMQ могут быть заменены без изменения кода.
Сборка, выпуск, выполнение. Четкое разделение стадий: сборка приложения, создание релиза и его выполнение.
Процессы. Приложение должно быть построено из одного или нескольких независимых процессов. Каждый процесс приложения отвечает за свою задачу (например, обработка HTTP-запросов, фоновые задания).
Stateless. Приложение не должно хранить данные или состояние внутри процессов. Все состояния хранятся во внешних ресурсах. Пример: Сессии пользователей сохраняются в Redis, а не в оперативной памяти приложения. Если процесс падает или перезапускается, состояние не теряется, так как оно хранится в Redis, базе данных или другой внешней системе.
Привязка портов. Приложение экспортирует HTTP (или другой) сервис через привязанный порт.
Параллелизм. Процессы должны быть разделены на масштабируемые модули.
Среда разработки = среда продакшена. Минимизируйте различия между стендами разработки и продакшеном.
Журналирование. Приложение пишет события в поток вывода (stdout), а обработкой логов занимается внешняя система. Пример: Логи собираются через Elasticsearch или Datadog.
Административные задачи. Запускайте административные задачи, такие как миграции базы данных, вместе с запуском сервиса.
Мета информация
Область:: ../../../../wiki/zero/00 Микросервисная архитектура Родитель:: Источник:: Создана:: 2024-12-08 Автор::