Last updated
Last updated
技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
Pivotal 公司
Pivotal 公司的 Matt Stine 于2013年首次提出云原生（CloudNative）的概念；
2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；
到了2017年，Matt Stine在接受 InfoQ 采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；
Pivotal 最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。
CNCF
2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；
2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。
软件通常会作为一种服务来交付，它们被称为网络应用程序，或“软件即服务”（）。“十二要素应用程序”（12-Factor App）为构建如下的SaaS应用提供了方法论：
基准代码 一份基准代码，多份部署 基准代码和应用之间总是保持一一对应的关系： 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用12-Factor进行开发。 多个应用共享一份基准代码是有悖于12-Factor原则的。解决方案是将共享的代码拆分为独立的类库，然后使用依赖管理策略去加载它们。尽管每个应用只对应一份基准代码，但可以同时存在多份部署。所有部署的基准代码相同，但每份部署可以使用其不同的版本。
依赖 显式声明依赖关系 12-Factor规则下的应用程序不会隐式依赖系统级的类库。 它一定通过依赖清单 ，确切地声明所有依赖项。此外，在运行过程中通过 依赖隔离 工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。
配置 在环境中存储配置 12-Factor推荐将应用的配置存储于环境变量 中 (env vars, env) 。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如Java的属性配置文件）相比，环境变量与语言和系统无关。 12-Factor应用中，环境变量的粒度要足够小，且相对独立。它们永远也不会组合成一个所谓的“环境”，而是独立存在于每个部署之中。当应用程序不断扩展，需要更多种类的部署时，这种配置管理方式能够做到平滑过渡。
后端服务 把后端服务当作附加资源 12-Factor应用不会区别对待本地或第三方服务。 对应用程序而言，两种都是附加资源，通过一个url或是其他存储在 配置 中的服务定位/服务证书来获取数据。12-Factor应用的任意 部署 ，都应该可以在不进行任何代码改动的情况下，将本地MySQL数据库换成第三方服务(例如 Amazon RDS)。类似的，本地SMTP服务应该也可以和第三方SMTP服务(例如Postmark)互换。
构建，发布，运行 严格分离构建和运行 12-facfor应用严格区分构建，发布，运行这三个步骤。每一个发布版本必须对应一个唯一的发布ID。 新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。
进程 以一个或多个无状态进程运行应用 12-factor应用的进程必须无状态且无共享 。任何需要持久化的数据都要存储在后端服务内，比如数据库。粘性Session是twelve-factor极力反对的。Session中的数据应该保存在诸如Memcached 或 Redis 这样的带有过期时间的缓存中。
端口绑定 通过端口绑定提供服务 12-factor应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用 通过端口绑定来提供服务，并监听发送至该端口的请求。
并发 通过进程模型进行扩展 在12-factor应用中，进程是一等公民。 12-factor应用的进程主要借鉴于 unix守护进程模型 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型 。
易处理 快速启动和优雅终止可最大化健壮性 12-factor应用的进程是可支配的，意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用，迅速部署变化的代码或配置，稳健地部署应用。进程应当追求最小启动时间；进程一旦接收终止信号(SIGTERM) 就会优雅的终止 。进程还应当在面对突然死亡时保持健壮 。
开发环境与线上环境等价 尽可能的保持开发、预发布、线上环境相同 12-factor应用想要做到持续部署就必须缩小本地与线上差异。12-factor应用的开发人员应该反对在不同环境间使用不同的后端服务 ，即使适配器已经可以几乎消除使用上的差异。
日志 把日志当作事件流 12-factor应用本身从不考虑存储自己的输出流。 不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出(stdout)事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。
管理进程 后台管理任务当作一次性进程运行 一次性管理进程应该和正常的 常驻进程 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置，基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。所有进程类型应该使用同样的依赖隔离技术。12-factor尤其青睐那些提供了REPL shell的语言，因为那会让运行一次性脚本变得简单。
