• 一份基准代码,多份部署 显式声明依赖关系 在环境中存储配置 把后端服务当作附加资源 严格分离构建和运行 以一个或多个无状态进程运行应用 通过端口绑定提供服务 通过进程模型进行扩展 快速启动和优雅终止可最大化健壮性 尽可能的保持开发,预发布,线上环境相同 把日志当作事件流 后台管理任务当作一次性进程运行


    The Twelve-Factor App (简体中文) https://12factor.net/zh_cn/

    简介

    如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或软件即服务(SaaS)。12-Factor 为构建如下的 SaaS 应用提供了方法论:

    • 使用标准化流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目。
    • 和操作系统之间尽可能的划清界限,在各个系统中提供最大的可移植性
    • 适合部署在现代的云计算平台,从而在服务器和系统管理方面节省资源。
    • 将开发环境和生产环境的差异降至最低,并使用持续交付实施敏捷开发。
    • 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展

    这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。

    背景

    本文的贡献者参与过数以百计的应用程序的开发和部署,并通过 Heroku 平台间接见证了数十万应用程序的开发,运作以及扩展的过程。

    本文综合了我们关于 SaaS 应用几乎所有的经验和智慧,是开发此类应用的理想实践标准,并特别关注于应用程序如何保持良性成长,开发者之间如何进行有效的代码协作,以及如何 避免软件污染 。

    我们的初衷是分享在现代软件开发过程中发现的一些系统性问题,并加深对这些问题的认识。我们提供了讨论这些问题时所需的共享词汇,同时使用相关术语给出一套针对这些问题的广义解决方案。本文格式的灵感来自于 Martin Fowler 的书籍: Patterns of Enterprise Application Architecture , Refactoring 。

    读者应该是哪些人?

    任何 SaaS 应用的开发人员。部署和管理此类应用的运维工程师。

    12-factors

    I. 基准代码

    一份基准代码,多份部署

    II. 依赖

    显式声明依赖关系

    III. 配置

    在环境中存储配置

    IV. 后端服务

    把后端服务当作附加资源

    V. 构建,发布,运行

    严格分离构建和运行

    VI. 进程

    以一个或多个无状态进程运行应用

    VII. 端口绑定

    通过端口绑定提供服务

    VIII. 并发

    通过进程模型进行扩展

    IX. 易处理

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

    X. 开发环境与线上环境等价

    尽可能的保持开发,预发布,线上环境相同

    XI. 日志

    把日志当作事件流

    XII. 管理进程

    后台管理任务当作一次性进程运行

    Introduction

    In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

    • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
    • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
    • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
    • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
    • And can scale up without significant changes to tooling, architecture, or development practices.

    The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

    Background

    The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Herokuplatform.

    This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.

    Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.

    Who should read this document?

    Any developer building applications which run as a service. Ops engineers who deploy or manage such applications.

    The Twelve Factors

    I. Codebase

    One codebase tracked in revision control, many deploys

    II. Dependencies

    Explicitly declare and isolate dependencies

    III. Config

    Store config in the environment

    IV. Backing services

    Treat backing services as attached resources

    V. Build, release, run

    Strictly separate build and run stages

    VI. Processes

    Execute the app as one or more stateless processes

    VII. Port binding

    Export services via port binding

    VIII. Concurrency

    Scale out via the process model

    IX. Disposability

    Maximize robustness with fast startup and graceful shutdown

    X. Dev/prod parity

    Keep development, staging, and production as similar as possible

    XI. Logs

    Treat logs as event streams

    XII. Admin processes

    Run admin/management tasks as one-off processes

  • 相关阅读:
    Linux Shell 文本处理工具集锦--Awk―sed―cut(row-based, column-based),find、grep、xargs、sort、uniq、tr、cut、paste、wc
    ACME[free https] Linux中使用curl命令访问https站点4种常见错误和解决方法
    php composer,update-ca-trust
    bootloader,kernel,initrc
    linux devcie lspci,lscpu,blkdiscard,fstrim,parted,partprobe,smartctl
    剖析Docker文件系统:Aufs与Devicemapper
    Linux 内核中的 Device Mapper 机制
    MapReduce报错:Error: java.io.IOException: Initialization of all the collectors failed. Error in last collector was :interface javax.xml.soap.Text
    hadoop运行报错Wrong FS: hdfs:/, expected: file:///
    Hadoop 伪分布式上安装 Hive
  • 原文地址:https://www.cnblogs.com/rsapaper/p/13633909.html
Copyright © 2020-2023  润新知