saas 自定义域名_Saas 应用12个架构规范

关注世界领先 DevOps 平台 JFrog

引言

如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务(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等