“12-Factor”，你准备好了吗？
【编者的话】如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS），12-Factor 为构建网络应用提供了方法论。本文综合了关于 SaaS 应用几乎所有的经验和智慧，是开发此类应用的理想实践标准，保证了应用程序设计模块化和灵活性，提倡开发者之间进行有效的代码协作，以及避免软件污染 。
应用程序开发过程中可选框架众多，但并非所有框架都适应当今的云环境。 大多数框架缺乏模块化和灵活性，甚至有些还不能有效利用使用云计算的优势。 ”12-Factor”应用程序原则自始至终是专门为现代化、容器化云环境而设计的。 每个组件都根据容器和云部署的灵活性进行定制，同时为每个团队成员(以及第三方开发人员)创建了一个可遵循的标准。
同时，”12-Factor”创建了一种更直接的方法来开发具有微服务架构的云应用。 它不仅兼顾了良好用户体验，还提高了虚拟环境的可用性。所以我们的问题来了：您已经为实践”12-Factor”应用程序原则做好准备了吗？
“12-Factor”应用程序设计原则
“12-Factor”应用程序原则的主要目标是：使创建的应用程序完全不受云环境和依赖关系的影响。 通过实现此目标，可以将应用程序部署在不同的虚拟环境中，而无需特定的驱动程序或要求。
你可能会好奇，”12-Factor”应用程序原则：这到底是什么，以及如何去监测
由该方法管理的”12-Factor”是决定应用程序的可伸缩性和灵活性的基本因素。它们是：
1. Base Code 基准代码库
通过使用统一的代码库，应用程序可以通过自定义配置文件实现一份基准代码多份部署，而不是在应用程序或者微服务中直接定义环境。同样，你只需定义”12-Factor”应用程序配置，而不用在实际的运行环境中操作。正如 ”12-Factor”网站 所说，“12-Factor”应用程序总是在版本控制系统（如Git、Mercurial或Subversion）中被跟踪。修订跟踪数据库的副本称为代码库，通常简称为代码库或仓库。代码库是一个单个仓库（在Subversion这样的集中版本控制系统中）或仓库的原始提交集合（在Git这样的分布式版本控制系统中）。”
2.Dependencies 依赖关系
包管理器 是一种更好，更有效的管理依赖项方法。与直接将依赖项添加到代码库中不同，使用包管理器跨环境重新生成部署将更容易。此外，一个”12-Factor”的应用程序从不依赖于全系统包的隐式存在，它通过依赖项声明的manifest完整准确地描述所有依赖项。
3.Config 配置
Config被视为环境变量，使codebase不受环境特定参数的影响。正如第一个因素中提到的，独立的配置是如何保持应用程序灵活的。
4.Backing Services 支持服务
确保与支持服务的兼容性也是一个重要步骤，因为它允许您在不必更改代码的情况下切换服务提供者或服务。使用这种方法，可以确保每个服务都是完全可移植的。
5.Build, Run, Release 构建 发布 运行
“12-Factor”方法论将构建、运行和发布阶段牢牢地分开。在代码审查和代码测试时，代码会从一个阶段转移到另一个阶段，这意味着已部署的代码始终可以完成其相应阶段工作。
6.Stateless Processes 无状态进程运行应用
目前，”12-Factor”应用程序始终支持无状态服务，为服务添加状态的日子已经一去不复返了。
7.Port Binding 端口绑定提供服务
该组件易于部署，因为它基本上意味着通过端口绑定使服务可用。其结果是：以微服务为组件即可作为一个独立的应用程序。
8.Concurrency 并发
为了使扩展易于管理， 微服务的粒度被最小化 。 由于微服务的无状态化，它们也可以按单元或整个应用进行扩展（参考因素6）。
9.Disposability可丢弃性
是的，应用程序中的每个过程都是一次性的。 使用这种方法使处理故障和跟踪效率都变得更加容易。
10. Dev-Prod Parity 开发/产品奇偶校验
匹配的环境是CI/CD循环更有效的关键。
11.Logs日志
一个良好完善的框架应该具有有效的日志追踪调试功能和完善的健康监测功能 。“符合”12-Factor”的应用程序不应该关注路由的设计和输出流的存储功能，也不应试图写入或管理日志文件。相反，每个正在运行的进程都将其事件流（无缓冲）写入stdout。 在本地开发期间，开发人员将在其终端的前台查看此流，以观察应用程序的行为。在暂存或生产部署中，每个流程的流将被执行环境捕获，与应用程序中的所有其他流一起路由到一个或多个最终目的地以供查看和长期存档。这些存档目标对应用程序不可见或不可配置，而是完全由执行环境管理。开放源代码日志路由器（如Logplex和Fluentd）可用于此。”
12.Admin Processes 管理进程
后台管理任务当作一次性进程运行而不是连续周期运行。在应用程序运行时处理其常规业务（如web请求等）的进程以数组的形式被处理。另外，开发人员通常会希望对该应用执行一次性的管理或维护任务。在与应用程序的常规长期运行进程相同的环境中运行这些一次性管理进程。使用与针对该版本运行的任何进程相同的代码库和配置，针对该版本运行它们。 管理员代码必须与应用程序代码一起提供，以避免同步问题。 这样的一次性过程可以包括：
- “ 运行数据库迁移 （例如，在Django中为manage.py进行迁移，在rake db中：在Rails中进行迁移）。
- 运行控制台（也称为REPL Shell）以运行任意代码或针对实时数据库检查应用程序的模型。 大多数语言通过运行不带任何参数的解释器来提供REPL（例如python或perl），或者在某些情况下具有单独的命令（例如irb用于Ruby，Rails控制台用于Rails）。
- 运行提交到应用程序仓库中的一次性脚本（例如php scripts / fix_bad_records.php）。”
Kubernetes中实践”12-Factor”应用原则
“12-Factor”应用原则中的许多是使Kubernetes如此受欢迎的因素之一。模块性、可处理性和并发性是使用Kubernetes部署应用程序和微服务的一些强大的特性。
如果您查看一些”12-Factor”的应用程序示例部署，您还将发现它们在Kubernetes pods和配置文件中非常合理。pod利用端口绑定保持可见，使用为每个pod定义的配置和需求，并且具有良好的可伸缩性。
实际上，诸如“ Horizontal Pod Autoscaler “(HPA) 之类的工具使缩放Kubernetes pods变得很简单。 Kubernetes固有的生命周期控制器（包括DaemonSet和ReplicationController）允许并发Pod使高可用性成为可能。
状态在无状态环境中
采用”12-Factor”应用程序原则的唯一真正挑战是 Kubernetes应用程序需要使用状态 （或者您必须开发有状态的应用程序）。 进程中状态的维持和实现有效的资源共享方面至关重要。 起初看起来似乎是一个完全的死胡同，但是当实现”12-Factor”时，有很多方法可以绕过Kubernetes中的状态。
附加到Kubernetes环境的Config上的持久数据存储库是解决该问题的理想方法。 它使您能够拥有可扩展的Pod，而不会牺牲数据存储和服务状态。
“12-Factor”方法论是可以在几乎任何开发情况下和开发框架下实施的。 更重要的是搭配Kubernetes的效果比我们预想要好的多。 如果您正在为应用程序开发项目寻求采用的标准，那么就可以使用”12-Factor”应用程序了。
更多深入阅读：
About The Author
