Saas 应用12个架构规范 _Saas

引言如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论：
使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。
这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。
特别声明本文转自国外一篇文章，由Adam Wiggins所著，原文地址：https://12factor.net/
在此文基础上增加个人的理解以及部分图解。
统一源代码管理系统一份基准代码（Codebase），多份部署（deploy）
在类似 SVN 这样的集中式版本控制系统中，基准代码就是指控制系统中的这一份代码库；而在 Git 那样的分布式版本控制系统中，基准代码则是指最上游的那份代码库。
基准代码和应用之间总是保持一一对应的关系：
一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor 进行开发。
多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案是将共享的代码拆分为独立的类库，然后使用依赖管理策略去加载它们。

文章插图

依赖管理显式声明依赖
大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，就像 Perl 的 CPAN 或是 Ruby 的 Rubygems。通过打包系统安装的类库可以是系统级的（称之为 “site packages”），或仅供某个应用程序使用，部署在相应的目录中（称之为 “vendoring” 或 “bunding”）
12-Factor规则下的应用程序不会隐式依赖系统级的类库。它一定通过依赖清单，确切地声明所有依赖项。此外，在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。
显式声明依赖的优点之一是为新进开发者简化了环境配置流程。新的开发者可以检出应用程序的基准代码，安装编程语言环境和它对应的依赖管理工具，只需通过一个构建命令来安装所有的依赖项，即可开始工作，如Maven，Pip，Npm等
12-Factor 应用同样不会隐式依赖某些系统工具，如 ImageMagick 或是curl 。即使这些工具存在于几乎所有系统，但终究无法保证所有未来的系统都能支持应用顺利运行，或是能够和应用兼容。如果应用必须使用到某些系统工具，那么这些工具应该被包含在应用之中。
配置管理在环境中存储配置
通常，应用的配置在不同部署 (预发布、生产环境、开发环境等等)间会有很大差异。这其中包括：
数据库，Memcached，以及其他后端服务的配置
第三方服务的证书，凭证，如 Amazon S3、Twitter 等
每份部署特有的配置，如域名等
应用程序不允许将配置存储为代码中的常量，这需要严格地将配置与代码分离。配置在部署之间差异很大，代码则没有。另外，“config”的这个定义不包括内部应用程序配置，这种类型的配置在部署之间不会有所不同，因此最好在代码中保存
提示：对应用程序是否在代码中正确分配了所有配置的试金石是，代码库是否可以随时变为开源，而不用担心泄漏任何敏感凭据。
应用程序应将配置存储在环境变量中（通常缩写为env vars或env）。在不更改任何代码的情况下，可以在部署之间轻松更改Env变量; 与配置文件不同，它们几乎没有机会被意外地检入代码仓库; 与自定义配置文件或其他配置机制（如JAVA系统属性）不同，它们是与语言和操作系统无关的标准。

文章插图

后端服务把后端服务(backing services)当作附加资源
后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL，CouchDB），消息/队列系统（RabbitMQ，Beanstalkd），SMTP 邮件发送服务（Postfix），以及缓存系统（Memcached）。
类似数据库的后端服务，通常由部署应用程序的系统管理员一起管理。除了本地服务之外，应用程序有可能使用了第三方发布和管理的服务。示例包括 SMTP（例如 Postmark），数据收集服务（例如 New Relic 或 Loggly），数据存储服务（如 Amazon S3），以及使用 API 访问的服务（例如 Twitter, google Maps, Last.fm）。