Методология приложения с двенадцатью факторами

Методология приложения с двенадцатью факторами Изучение

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

Эта методология была впервые представлена ​​разработчиками Heroku в 2012 году, которые создали сотни приложений и разработали эту методологию на основе своего опыта. Методология включает 12 принципов, каждый из которых применяется к подмножеству приложения и помогает разработчикам найти лучший способ управления приложениями в целом.

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

Принцип 1. Кодовая база

Должна быть одна кодовая база с разными средами.

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

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

Принцип 2. Зависимости

Все зависимости должны быть объявлены без явной зависимости от системных инструментов или библиотек.

Включение зависимостей в кодовую базу — плохая практика, поскольку это может создать такие проблемы, как базовая зависимость платформы. Например, если загруженные модули были с точки зрения ПК с Windows, а кодовая база была загружена разработчиком Mac OS, у них, несомненно, возникли бы проблемы с запуском проекта.

Читайте также:  Log4Shell: 4 вывода для разработчиков в 2022 году

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

Лучше использовать диспетчер пакетов

Принцип 3. Конфиг

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

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

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

Принцип 4. Вспомогательные услуги

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

Принцип 5. Сборка, выпуск, запуск

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

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

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

Принцип 6. Процессы

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

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

Принцип 7. Привязка порта

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

Этот фактор относится к приложению, которое связывает себя с определенным портом и отвечает на все запросы от этого порта. Порт объявлен как переменная среды и предоставляется во время выполнения.

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

Приложения, построенные на принципиальной основе

Принцип 8. Параллелизм

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

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

Принцип 9. Одноразовость

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

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

Принцип 10. Dev-Prod Parity

В статье с двенадцатью факторами предлагается минимизировать разницу между средой разработки и производственной средой. Это снижает вероятность появления ошибок в конкретной среде.

Разработчики должны стремиться использовать одни и те же сторонние сервисы в процессе разработки и производства. Чтобы минимизировать различия между разработкой и производством, команды, работающие над проектом, должны использовать одни и те же операционные системы, службы поддержки и зависимости. В результате непрерывное развертывание занимает меньше времени. Это также способствует идее быстрой разработки приложений (RAD).

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

Принцип 11. Журналы

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

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

Принцип 12. Административные процессы

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

Преимущества методологии приложения с двенадцатью факторами

Методология приложения «Двенадцать факторов» может повысить эффективность. Кроме того, время, потраченное на изучение и применение этих рекомендаций, может помочь компаниям сэкономить много денег.

Бывают случаи, когда имеет смысл отклониться от некоторых рекомендаций, таких как Журналы, но лучше как можно тщательнее следовать всем рекомендациям по Двенадцати факторам.

Ищете услуги разработки SaaS ? Если у вас есть сомнения или опасения относительно методологии приложения «Двенадцать факторов», лучше всего получить консультацию специалиста. В СКЭНД вы можете получить бесплатную консультацию у наших специалистов. Опишите ваш проект, требования, временные и бюджетные ограничения, и наши консультанты предложат вам наиболее выгодный вариант.

Оцените статью
bestprogrammer.ru
Добавить комментарий