Официальный адрес: https://12factor.net/zh_cn/

Принцип 1: кодовый номер, многократная развертывание

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

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

Нарушение принципа подпункта 2 и 3, управление кодом и компиляция работы приведет к возникновению проблемы:

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

Принцип 2: явно объявить зависимости

упаковочная система
Тип упаковки: пакеты сайта, vendoring | укрупнение
Список Reliance: применение в соответствии с 12-Фактора правила не неявно используют библиотеки системного уровня
Разделительная зависимость: независимо от того, какие инструменты, не полагаться на заявления и полагаться на изоляцию, должны быть использованы вместе, или не может удовлетворить 12-коэф
Построение команды: Одно из преимуществ явно декларируют зависимости заключается в упрощении процесса настройки для новых разработчиков абитуриенты среды.

Принцип 3: конфигурация хранения в среде

Во-первых, понятно, здесь относится к среде конфигурации, связанные с конфигурацией и развертывания, такие как:

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

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

Я думаю, что большинство разработчиков знают, как добиться разделения кода и конфигурации с помощью файла конфигурации, но этот подход все еще имеет некоторые недостатки, такие как:

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

Чтобы избежать этой проблемы, этот принцип требует конфигурации хранения в среде. Типичный метод для настройки хранения в переменных окружения, что делает полное разделение кода и конфигурации, языков разработки формата, а также нет соединения рамы, и не будет представлен на ошибочном коде. Вы также можете использовать этот тип Spring Cloud Configuration Manager Конфигурация сервера для настройки нажимные услуг, а также управление версиями и управление изменениями является также причиной для настройки их вместе.

Принцип 4: фоновые услуги в качестве дополнительных ресурсов

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

Этот принцип имеет несколько значений следующим образом:

Не используйте эти услуги на местном: Cloud нативного само приложение требует применения негосударственный, то информация о состоянии должны храниться во внешнем службе (см непреложный сервер). В то же время, модель микро-услуги требует права выбрать одно приложение для достижения надежности и масштабируемости, если приложение находится в локальной базе данных, то платформа микро-сервис не сможет заменить отказавшее приложение экземпляра достижения высоких приложений доступности не может быть автоматизировано с помощью масштабного отказа обеспечения масштабируемости, так как он содержит два свойства полностью различного программного обеспечения (приложений и баз данных) пример приложения, не может быть использована для масштабирования и таким же образом. Кроме того, если эти услуги на местном применении, она не может быть упрощена за счет возможности в полной мере воспользоваться облачной платформы обеспечивает функционирование и техническое обслуживание, например, если приложение находится в локальной базе данных, вместо того чтобы использовать облачную платформу обслуживания базы данных, то, очевидно, вы не можете использовать сервис базы данных обеспечивает автоматическое резервное копирование, безопасность и высокие характеристики доступности.
URL или в сервисном центр регистрации / аутентификация для доступа к фонам услуг через: приложение должно быть в состоянии, без внесения каких-либо изменений коды, и какая-либо конкретная реализация для развертывания в различных целевых средах, приложениях и фоновые услуги не должны существовать тесно связаны отношения.
Аналогичные принципы «явно объявляемые зависимости», приложение может быть лучше отображенных объявить их использование этих серверных служб для облегчения ресурсов службы облака платформы автоматически связанными, когда происходит сбой в фоновых услугах, облачные платформах Он может быть автоматически восстановлены.

Принцип 5: строгое разделение сборки, публиковать и управлять

В этом принципе, строить, публиковать и запустить эти три понятия могут быть разными , и первое, что необходимо в первую очередь быть ясно:

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

Этот принцип требует, чтобы строить, публиковать и запускать строго различать эти три этапа:

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

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

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

Принцип 6: один или более лиц без процессов, запущенных приложений

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

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

Трудно добиться балансировки нагрузки липкий сессии, поскольку баланс липких сеансов зависит не только от стратегии балансировки нагрузки, а также связанные с поведением самой сессии, например, могут быть некоторые случаи на сессии приложений имеет много бросить курить, в то время как другие сессии на экземпляре по-прежнему активны, то нагрузка будет в два экземпляре части несбалансированного состоянии и балансировка нагрузки не может перевести активный сеанс экземпляр приложения холостой.
Новый экземпляр запускается приложение не будет увеличивать общую мощность обработки заявки сразу, потому что они могут только провести новый экземпляр новой сессии, старая сессия остается липкой на старых примерах применения.
应用实例退出会导致会话丢失，所以在实例发生故障时，即使云平台可以对故障实例进行自动替换，也会导致用户数据丢失。即使是对应用实例进行人工维护，也需要在维护之前对该实例上的会话进行转移，这往往意味着需要编写复杂的业务代码。

在传统模式下，可以通过在双机之间进行会话复制来实现对用户无感知的单机下线维护（虽然会付出处理能力减半的代价），但是在微服务模式下，应用的实例数量往往远不止两个，在大量的实例之间进行会话复制会使实例之间原本非常简单的逻辑关系复杂化，此时将无法通过云平台对其进行无差别的自动化维护。另外，在实例之间进行会话复制也意味着实例之间存在着直接的数据共享，这会为应用的横向扩展带来障碍。

所以，粘滞会话是应用实现可用性和扩展性的重要障碍，使用粘滞会话显然是种得不偿失的选择。更好的实现方式是将会话信息存储在缓存服务中。

原则7：通过端口绑定提供服务

服务端应用通过网络端口提供服务，这点毋庸置疑，但是本原则还有如下两个深层次的含义：

无论是云原生应用还是微服务模式都要求应用应该完全自我包含，而不是依赖于外部的应用服务器，端口绑定指的是应用直接与端口绑定，而不是通过应用服务器进行端口绑定。

如果一定要使用应用服务器，那就使用嵌入式应用服务器，无论是云原生应用还是微服务模式都极力反对将多个应用放置于同一个应用服务器上运行，因为在这种模式下，一个应用出错会对同一个应用服务器上的其他应用造成影响，也无法针对单一应用做横向扩展。
端口绑定工作应该由云平台自动进行，云平台在实现应用到端口的绑定之外，还需要实现内部端口到外部端口的映射和外部端口到域名的映射。在应用的整个生命周期内，应用实例会经历多次的重新部署、重启或者横向扩展，端口会发生变化，但URL会保持不变。

原则8：通过进程模型进行扩展

与通过进程模型进行扩展相反的方式是通过线程模型进行扩展，这是一种相对较为传统的方式，典型的例子是Java应用。当我们启动一个Java进程的时候，通常会通过JVM参数为其设置各个内存区域的容量上下限，同时还可能会在应用层面为其设置一个或者多个线程池的容量上下限，当外部负载变化时，进程所占用的内存容量和进程内部的线程数量可以在这些预先设置好的上下限之间进行扩展，这种方式也被称为纵向扩展或者垂直扩展。

但是这种方式存在一些问题，首先，在进程的内存容量和线程数量提高时，应用的某些性能指标可能不会得到同步提高，甚至可能会下降（这往往是因为程序对某些无法扩展的资源进行争用所造成的），这种参差不齐的性能扩展对外部负载提高的承接能力会很不理想，有时甚至会适得其反；

其次，为了使进程本身可以完成纵向扩展，还需要在虚拟机层面或者容器层面为其预留内存资源和对应的CPU资源，这会造成大量的资源浪费（当然，也可以使虚拟机或者容器跟随进程一起进行纵向扩展，这在技术上是可行的，但是会为虚拟机或者容器管理平台的资源调度造成一些不必要的困难，例如频繁的虚拟机迁移或者容器重启）。

所以，现在更为推崇使用“固定的”进程（对前面Java应用的例子来说，就是固定的内存容量和线程池容量），在外部负载提高时，启动更多的进程，在外部负载降低时，停止一部分进程，这种方式就是本原则所说的通过进程模型进行扩展，有时候也被称为横向扩展或者水平扩展。

这种扩展方式的好处是，在进程数量增加的时候，应用的各种性能指标会得到同步的提高，这种提高即使不是线性的，也会按照一种平滑和可预期的曲线展开，可以更为稳定的应对外部负载的变化。

云原生应用和微服务模式极力推崇将通过进程模型进行扩展作为唯一的扩展方式，除了前文所述，还有一个原因是进程是云平台可以操作的最小运行单元（当然，可以通过其他技术手段去操作线程，但是那不会成为云平台的通用技术特性），云平台可以根据各个层面的监控数据，通过预设规则决定是否为应用增加或者减少进程，例如，当前端的负载均衡器检测到访问某个后端应用的并发用户数超过某个阈值时，可以立即为这个后端应用启动更多的进程，以承接更大的负载，同时还可以选择是否对该应用后端的数据库进行扩展。

如果此时选择对应用进行纵向扩展，则云平台既不知道应用处理能力的变化，也无法对这种变化进行预期管理，更无法使应用的前后端对这种变化进行联动，即该应用的扩展行为脱离了云平台的管理。在微服务模式下，如果大量的进程都采用纵向扩展方式，则会为平台的资源调度带来极大的混乱。

注3：该原则似乎更适合被称为横向扩展原则，但是为了和12原则的原文保持一直，这里我们仍然将其称为“通过进程模型进行扩展”。

原则9：快速启动和优雅终止可最大化健壮性

该原则要求应用可以瞬间（理想情况下是数秒或者更短）启动和停止，因为这将有利于应用快速进行横向扩展和变更或者故障后的重新部署，而这两者都是程序健壮性的体现。

前文不止一次提到过应用的快速启动，在理念章节的开头，我们提到过平价的进程生成对多道程序设计至关重要，而微服务模式在某种程度上可以认为是多道程序设计在Web领域和分布式系统下的进一步扩展，这里所说的平价进程生成指的是操作系统的一种特性，是应用快速启动的基础，除此之外为了保证应用可以在数秒内完成启动，还需要大量的优化工作，需要开发人员掌握复杂的调优技术与工具，有些工作必须在应用的初始设计阶段完成，例如：如果应用体积过大或者是引用了太多的库文件，那么再多的后期优化也无法将启动时间降低到数秒以内。

在“原则5：严格分离构建、发布和运行”中我们还提到，应用的运行步骤应该非常简单，这里的“简单”也隐含着快速的意思，目的是为了在硬件重启、实例故障和横向扩展等情况下，应用可以快速的实现重启。除此之外，“原则6：以一个或多个无状态的进程运行应用”也与应用的快速启动有关，遵守无状态原则，使用云平台提供的缓存服务，而不是在应用内部加载缓存，可以避免在应用启动期间进行耗时的缓存预热。

比起应用的快速启动，优雅终止（Graceful Shutdown）需要考虑的问题会更为广泛一些。优雅终止需要尽可能降低应用终止对用户造成的不良影响（对于微服务应用，用户可能是人，也可能是其他微服务）。

对于短任务来说，这一般意味着拒绝所有新的请求，并将已经接收的请求处理完毕后再终止；对于长任务来说，这一般意味着应用重启后的客户端重连和为任务设置断点并在重启后继续执行。除此之外，优雅终止还需要释放所有被进程锁定的资源，并对事务的完整性和操作的幂等性做出完备的考虑。

最后，应用还必须应对突如其来的退出，在硬件出现故障时或者进程崩溃时，应用需要保证不会对其使用的数据造成损坏，遵守无状态原则、将数据交由后端服务处理的应用可以很容易的将应对突然退出的复杂度外部化。

12-Factor应用的进程是易处理（disposable）的，意思是说它们可以瞬间开启或停止。这有利于快速、弹性的伸缩应用，迅速部署变化的代码或配置，稳健的部署应用。
进程应当追求最小启动时间
进程一旦接收终止信号（SIGTERM）就会优雅的终止
进程还应当在面对突然死亡时保持健壮，例如底层硬件故障
12-Factor应用都应该可以设计能够应对意外的、不优雅的终结。

原则10：开发环境与线上环境等价

本原则的浅层次含义是要求在开发环境和线上环境中使用相同的软件栈，并尽可能为这些软件栈使用相同的配置，以避免“It works on my machine.”这类问题。本原则反对在不同的环境中使用不同的后端服务，虽然可以使用适配器或者在代码中做出兼容性考虑以消除后端服务的差异，但是这将牵扯开发人员和测试人员大量的精力以保证这些适配器和代码确实可以按预期工作，在应用的整个开发周期中，这将积累极大的额外工作量，是一种非常不必要的资源浪费。

近年来个人电脑的性能大幅提高，开发人员一度得以在本地开发环境中运行与生产环境中一致的软件栈，而不是像曾经那样采用轻量的替代方案。但是随着云原生应用和微服务模式的流行，情况又发生了微妙的变化：开发微服务时需要依赖云平台提供的基础服务和其他微服务，越来越难以把这些服务完整的运行在本地，与此同时，完全的在线开发愈发成为一种趋势，那样的话至少在软件栈上开发环境和线上环境就真的没有任何区别了。

在我编写这段文字的时候，Red Hat公司刚好在洽购在线开发环境创业公司Codenvy用以充实他们的云平台产品OpenShift，而另一家与Codenvy类似的创业公司Cloud9在差不多一年前被Amazon公司收购。

本原则的深层次含义是尽量缩小开发环境和线上环境中时间和人员的差异。开发环境中的代码每天都在更新，而这些更新往往会累积数周甚至数月才会被发布到线上环境，这是开发环境和线上环境在时间上的巨大差异；开发人员只关心开发环境，运维人员只关心线上环境，开发人员和运维人员在工作上鲜有交集，这是开发环境和线上环境在人员上的巨大差异。

对于前一个差异，本原则要求更为密集和频繁的向线上环境发布更新，要求建立机制以保障开发人员可以在数小时甚至数分钟内既可将更新发布到线上，这也正是本章理念部分中持续交付所提倡的；对于后一个差异，本原则要求开发人员不能只关心开发环境中自己的代码，更要密切关注代码的部署过程和代码在线上的运行情况，这也正是DevOps所提倡的。

环境之间的差异：部署时间差异、人员分工差异、工具差异
12-Factor应用想要做到持续部署就必须缩小本地与线上差异
12-Factor 应用的开发人员应该反对在不同环境间使用不同的后端服务
使用类似 Chef 和 Puppet 的声明式配置工具，结合像 Vagrant 这样轻量的虚拟环境就可以使得开发人员的本地环境与线上环境无限接近。

原则11：把日志当作事件流

日志使得应用程序运行的动作变得透明。在基于服务器的环境中，日志通常被写在硬盘的一个文件里，但这只是一种输出格式。
日志应该是事件流的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。日志没有确定开始和结束，但随着应用在运行会持续的增加。
12-factor应用本身从不考虑存储自己的输出流，不应该试图去写或者管理日志文件。
在预发布或线上部署中，每个进程的输出流由运行环境截获，并将其他输出流整理在一起，然后一并发送给一个或多个最终的处理程序，用于查看或是长期存档。这些存档路径对于应用来说不可见也不可配置，而是完全交给程序的运行环境管理。类似 Logplex 和 Fluentd 的开源工具可以达到这个目的。
这些事件流可以输出至文件，或者在终端实时观察。最重要的，输出流可以发送到 Splunk 这样的日志索引及分析系统，或 Hadoop/Hive 这样的通用数据存储系统。这些系统为查看应用的历史活动提供了强大而灵活的功能，包括：
- 找出过去一段时间特殊的事件。
- 图形化一个大规模的趋势，比如每分钟的请求量。
- В соответствии с условиями реального времени определяемой пользователем тревоги, например, более чем одна ошибка в минуту оцепление.

Принцип 12: Управление задача выполняется в процессе единовременного

Процесс конфигурации (процесс формирование) относится к регулярному трафику приложениям обработки (например, процесс запроса веб) множество процессов. В отличие от этого, разработчики часто хотят, чтобы выполнить некоторые технического обслуживания или разовых приложений для управления задачами, такие как:
- Операция переноса данных (в Django manage.py мигрировать, грабли БД Рельсы в: мигрируют).
- Запуск консоли (также известный как REPL оболочки), чтобы выполнить код или сделать некоторые онлайн-проверки в отношении базы данных. Большинство языков обеспечивают инструмент REPL (Python или Perl), или другие команды (Ruby с помощью IRB, Рельсы с помощью реек консоли) с помощью переводчика.
- Отправить одноразовый скрипт для запуска в некотором коде хранилища.
12-фактор благоприятствования, особенно те, которые обеспечивают язык РЕПЛ оболочки, так как это делает его легко выполнить однократное скрипт с.

резюме