第一章：云计算的技术革命

1.1 互联网时代的历程

1.2 云计算到底是什么？

• ① 云计算不是新技术，是一种新的互联网模式，通过使用公有云或私有云资源，便捷、快速的为我们提供服务。
• ② 在虚拟化、分布式、自动化平台上的更层次的解决方案。
• ③ 云计算分为私有云、公有云和混合云。
• ④ "云" 中的资源在使用者看来是可以无限扩展的，并且可以 随时获取，按需使用，随时扩展，按使用付费 ，这种特性经常被称为像水电一样使用 IT 基础设施。

1.3 云计算历程

1.4 名词

• IaaS：Infrastructure-as-a-Service，基础设施即服务。
• PaaS：Platform-as-a-Service，平台即服务，如：阿里云、腾讯云、华为云等。
• SaaS：Software-as-a-Service，软件即服务，如：钉钉、金蝶、微盟等。
• CaaS：Container-as-a-Service，容器即服务。

1.5 云平台的优缺点

• 优点：
  • ① 稳定性：云平台大量资源，分布式集群部署，保障服务主机永不宕机。
  • ② 弹性扩展：按需获取，一键秒级开通需要的资源。
  • ③ 安全性：云上平台生产级可用的完全权限系统。
  • ④ 成本：初期计算资源成本极低，后期更是大量降低运维成本。
  • ⑤ 易用性：各大云厂商都有 WEB 管理控制台，可视化、智能化便捷操作。
  • ……
• 缺点：
  • ① 公有云：服务资源被第三方管理，不符合特殊级别的安全场景。
  • ② 私有云：搭建、维护、升级成本大。
  • ……

第二章：云计算技术架构演进变革

2.1 体系变革

2.2 架构变革

2.2.1 单体架构阶段

2.2.2 集群架构阶段

• 虚拟 VIP 的实现技术：keepalive。
• 假设设置虚拟 VIP 的 IP 地址为 192.168.65.100 ，应用服务器的 IP 地址为 192.168.65.101 ，热备应用服务器的 IP 地址为 192.168.65.102，通过 Keepalive 监听应用服务器和热备应用服务器，一旦应用服务器宕机，就会自动切换到热备应用服务器，这种架构中所有的流量都是一台应用服务器来分担。

2.2.3 分布式架构阶段

• 负载均衡的实现技术：硬件有 F5 ，软件有 Nginx 等。
• 假设负载均衡的 IP 地址为 192.168.65.100 ，应用服务器 1 的 IP 地址为 192.168.65.101 ，应用服务器 2 的 IP 地址为 192.168.65.102 ，应用服务器 3 的 IP 地址为 192.168.65.103 ，通过配置负载均衡策略以及反向代理，可以让三台应用服务器分担所有的流量，根据负载均衡策略分担的流量不同。

2.2.4 分布式和集群的区别？

• 分布式是将一个大型的应用，拆分出很多的功能模块，各个功能模块部署在不同的机器上，所有这些服务器合起来对外提供服务。
• 集群：将相同的功能模块部署在不同的机器上。

2.2.5 微服务架构

2.2.6 网格化架构（服务网格）

第三章：云上的挑战

3.1 云上的挑战

• 云机器资源编排。
• 云存储方案。
• 云负载均衡方案。
• 云缓存方案。
• 云持久化。
• 云运维。
• 云监控。
• 云容器技术。
• 云 DevOps 。
• 云安全防护。
• ……

3.2 kubernetes 能解决什么问题？

3.3 应用上云新型架构

• 应用上云的新型架构是：Kubernetes + ServiceMesh 。

第四章：云原生的生态系统

4.1 云原生的生态系统

4.2 云原生的技术方案

• 官网。

4.3 常见技术

• 容器化技术：Docker、Docker Compose 。
• 大规模容器编排：Kubernetes 。
• 云原生应用商店：Helm 。
• 易用的容器管理平台：Rancher 。
• 一站式容器云平台：Kubersphere 。
• 云原生链路追踪标准：OpenTracing 。
• 云原生链路追踪实现产品：Jaeger 。
• ServiceMesh 下的服务流量治理：Istio 。
• 老牌的 CI、CD：Jenkins、JenkinsX、Jenkins-BlueOcean 。
• GitHub、GitLab 自带的 CI、CD：GitHub-CI/CD、GitLab-CI/CD 。
• kubernetes 声明式持续集成：Argo。
• Maven 私有仓库：Nexus 。
• Docker 私有仓库：Harbor 。
• 监控和可视化方案：Prometheus 和 Grafana 。
• 日志和可视化方案：ElasticSearch + Fluentd + Kibana 。
• 无服务器上云方案：Serverless 。
• 微服务上云方案：SpringCloud Kubernetes 。

第五章：云原生的术语

5.1 官网

• 官网。

5.2 应用 12 要素（12 factors apps）

5.2.1 Codebase（基准代码）

• One codebase tracked in revision control, many deploys：一份基准代码，多份部署。

• 12-Factor应用(译者注：应该是说一个使用本文概念来设计的应用，下同)通常会使用版本控制系统加以管理，如Git, Mercurial, Subversion。一份用来跟踪代码所有修订版本的数据库被称作代码库（code repository, code repo, repo）。

• 在类似 SVN 这样的集中式版本控制系统中，基准代码就是指控制系统中的这一份代码库；而在 Git 那样的分布式版本控制系统中，基准代码则是指最上游的那份代码库。
• 基准代码和应用之间总是保持一一对应的关系：
• 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor 进行开发。
• 多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案是将共享的代码拆分为独立的类库，然后使用依赖管理 策略去加载它们。
• 尽管每个应用只对应一份基准代码，但可以同时存在多份部署。每份部署相当于运行了一个应用的实例。通常会有一个生产环境，一个或多个预发布环境。此外，每个开发人员都会在自己本地环境运行一个应用实例，这些都相当于一份部署。
• 所有部署的基准代码相同，但每份部署可以使用其不同的版本。比如，开发人员可能有一些提交还没有同步至预发布环境；预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码，我们就认为它们只是相同应用的不同部署而已。

5.2.2 Dependencies（依赖）

• Explicitly declare and isolate dependencies：显示声明依赖关系。

• 大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，就像 Perl 的 CPAN 或是 Ruby 的 Rubygems 。通过打包系统安装的类库可以是系统级的（称之为 “site packages”），或仅供某个应用程序使用，部署在相应的目录中（称之为 “vendoring” 或 “bunding”）。

• 12-Factor规则下的应用程序不会隐式依赖系统级的类库。 它一定通过依赖清单 ，确切地声明所有依赖项。此外，在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。
• 例如， Ruby 的 Bundler 使用 Gemfile 作为依赖项声明清单，使用 bundle exec 来进行依赖隔离。Python 中则可分别使用两种工具 – Pip 用作依赖声明， Virtualenv 用作依赖隔离。甚至 C 语言也有类似工具， Autoconf 用作依赖声明，静态链接库用作依赖隔离。无论用什么工具，依赖声明和依赖隔离必须一起使用，否则无法满足 12-Factor 规范。
• 显式声明依赖的优点之一是为新进开发者简化了环境配置流程。新进开发者可以检出应用程序的基准代码，安装编程语言环境和它对应的依赖管理工具，只需通过一个构建命令来安装所有的依赖项，即可开始工作。例如，Ruby/Bundler 下使用 bundle install，而 Clojure/Leiningen 则是 lein deps。
• 12-Factor 应用同样不会隐式依赖某些系统工具，如 ImageMagick 或是 curl 。即使这些工具存在于几乎所有系统，但终究无法保证所有未来的系统都能支持应用顺利运行，或是能够和应用兼容。如果应用必须使用到某些系统工具，那么这些工具应该被包含在应用之中。

5.2.3 Config（配置分离）

• Store config in the environment：在环境中存储配置。

• 通常，应用的配置在不同部署 (预发布、生产环境、开发环境等等)间会有很大差异。这其中包括：数据库，Memcached，以及其他后端服务的配置，第三方服务的证书，如 Amazon S3、Twitter 等，每份部署特有的配置，如域名等，有些应用在代码中使用常量保存配置，这与 12-Factor 所要求的代码和配置严格分离显然大相径庭。配置文件在各部署间存在大幅差异，代码却完全一致。

• 判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。
• 需要指出的是，这里定义的“配置”并不包括应用的内部配置，比如 Rails 的 config/routes.rb，或是使用 Spring 时代码模块间的依赖注入关系 。这类配置在不同部署间不存在差异，所以应该写入代码。
• 另外一个解决方法是使用配置文件，但不把它们纳入版本控制系统，就像 Rails 的 config/database.yml 。这相对于在代码中使用常量已经是长足进步，但仍然有缺点：总是会不小心将配置文件签入了代码库；配置文件的可能会分散在不同的目录，并有着不同的格式，这让找出一个地方来统一管理所有配置变的不太现实。更糟的是，这些格式通常是语言或框架特定的。
• 12-Factor 推荐将应用的配置存储于环境变量中（ env vars, env ）。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关。
• 配置管理的另一个方面是分组。有时应用会将配置按照特定部署进行分组（或叫做“环境”），例如 Rails 中的 development,test, 和 production 环境。这种方法无法轻易扩展：更多部署意味着更多新的环境，例如 staging 或 qa 。 随着项目的不断深入，开发人员可能还会添加他们自己的环境，比如 joes-staging ，这将导致各种配置组合的激增，从而给管理部署增加了很多不确定因素。
• 12-Factor 应用中，环境变量的粒度要足够小，且相对独立。它们永远也不会组合成一个所谓的“环境”，而是独立存在于每个部署之中。当应用程序不断扩展，需要更多种类的部署时，这种配置管理方式能够做到平滑过渡。

5.2.4 Backing services（后端服务）

• Treat backing services as attached resources：将后端服务当做附加资源。

• 后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL，CouchDB），消息/队列系统（RabbitMQ，Beanstalkd），SMTP 邮件发送服务（Postfix），以及缓存系统（Memcached）。

• 类似数据库的后端服务，通常由部署应用程序的系统管理员一起管理。除了本地服务之外，应用程序有可能使用了第三方发布和管理的服务。示例包括 SMTP（例如 Postmark），数据收集服务（例如 New Relic 或 Loggly），数据存储服务（如 Amazon S3），以及使用 API 访问的服务（例如 Twitter, Google Maps, Last.fm）。
• 12-Factor 应用不会区别对待本地或第三方服务。 对应用程序而言，两种都是附加资源，通过一个 url 或是其他存储在 配置 中的服务定位/服务证书来获取数据。12-Factor 应用的任意 部署 ，都应该可以在不进行任何代码改动的情况下，将本地 MySQL 数据库换成第三方服务（例如 Amazon RDS）。类似的，本地 SMTP 服务应该也可以和第三方 SMTP 服务（例如 Postmark ）互换。上述 2 个例子中，仅需修改配置中的资源地址。
• 每个不同的后端服务是一份资源 。例如，一个 MySQL 数据库是一个资源，两个 MySQL 数据库（用来数据分区）就被当作是 2 个不同的资源。12-Factor 应用将这些数据库都视作附加资源 ，这些资源和它们附属的部署保持松耦合。
• 部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 – 整个过程都不需要修改代码。

5.2.5 Build, release, run（构建、发布、运行）

• Strictly separate build and run stages：严格分离构建和运行。

• 基准代码转化为一份部署(非开发环境)需要以下三个阶段：

  • ① 构建阶段：是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包依赖项，编译成二进制文件和资源文件。
  • ② 发布阶段：会将构建的结果和当前部署所需 配置 相结合，并能够立刻在运行环境中投入使用。
  • ③ 运行阶段（或者说“运行时”）：是指针对选定的发布版本，在执行环境中启动一系列应用程序进程。
• 12-factor 应用严格区分构建，发布，运行这三个步骤。 举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。
• 部署工具通常都提供了发布管理工具，最引人注目的功能是退回至较旧的发布版本。比如， Capistrano 将所有发布版本都存储在一个叫 releases 的子目录中，当前的在线版本只需映射至对应的目录即可。该工具的 rollback 命令可以很容易地实现回退版本的功能。
• 每一个发布版本必须对应一个唯一的发布 ID，例如可以使用发布时的时间戳（2011-04-06-20:32:17），亦或是一个增长的数字（v100）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。
• 新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。构建阶段是可以相对复杂一些的，因为错误信息能够立刻展示在开发人员面前，从而得到妥善处理。

5.2.6 Processes（进程）

• Execute the app as one or more stateless processes：以一个或多个无状态进程运行应用。

• 运行环境中，应用程序通常是以一个和多个进程运行的。
• 最简单的场景中，代码是一个独立的脚本，运行环境是开发人员自己的笔记本电脑，进程由一条命令行（例如python my_script.py）。另外一个极端情况是，复杂的应用可能会使用很多 进程类型 ，也就是零个或多个进程实例。
• 12-Factor 应用的进程必须无状态且无共享 。 任何需要持久化的数据都要存储在后端服务内，比如数据库。
• 内存区域或磁盘空间可以作为进程在做某种事务型操作时的缓存，例如：下载一个很大的文件，对其操作并将结果写入数据库的过程。12-Factor应用根本不用考虑这些缓存的内容是不是可以保留给之后的请求来使用，这是因为应用启动了多种类型的进程，将来的请求多半会由其他进程来服务。即使在只有一个进程的情形下，先前保存的数据（内存或文件系统中）也会因为重启（如代码部署、配置更改、或运行环境将进程调度至另一个物理区域执行）而丢失。
• 源文件打包工具（Jammit, django-compressor） 使用文件系统来缓存编译过的源文件。12-Factor 应用更倾向于在构建步骤做此动作——正如 Rails资源管道 ，而不是在运行阶段。
• 一些互联网系统依赖于 “粘性 session”， 这是指将用户 session 中的数据缓存至某进程的内存中，并将同一用户的后续请求路由到同一个进程。粘性 session 是 12-Factor 极力反对的。Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。

5.2.7 Port binding（端口绑定）

• Export services via port binding：通过端口绑定来提供服务。

• 互联网应用有时会运行于服务器的容器之中。例如 PHP 经常作为 Apache HTTPD 的一个模块来运行，正如 Java 运行于 Tomcat 。

• 12-Factor 应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务 ，并监听发送至该端口的请求。
• 本地环境中，开发人员通过类似 http://localhost:5000/ 的地址来访问服务。在线上环境中，请求统一发送至公共域名而后路由至绑定了端口的网络进程。
• 通常的实现思路是，将网络服务器类库通过依赖声明载入应用。例如，Python 的 Tornado, Ruby 的Thin , Java 以及其他基于 JVM 语言的 Jetty。完全由 用户端 ，确切的说应该是应用的代码，发起请求。和运行环境约定好绑定的端口即可处理这些请求。
• HTTP 并不是唯一一个可以由端口绑定提供的服务。其实几乎所有服务器软件都可以通过进程绑定端口来等待请求。例如，使用 XMPP 的 ejabberd ， 以及使用 Redis 协议 的 Redis 。
• 还要指出的是，端口绑定这种方式也意味着一个应用可以成为另外一个应用的后端服务 ，调用方将服务方提供的相应 URL 当作资源存入 配置 以备将来调用。

5.2.8 Concurrency（并发）

• Scale out via the process model：通过进程模式来进行扩展。

• 任何计算机程序，一旦启动，就会生成一个或多个进程。互联网应用采用多种进程运行方式。例如，PHP 进程作为 Apache 的子进程存在，随请求按需启动。Java 进程则采取了相反的方式，在程序启动之初 JVM 就提供了一个超级进程储备了大量的系统资源(CPU 和内存)，并通过多线程实现内部的并发管理。上述 2 个例子中，进程是开发人员可以操作的最小单位。
• 在 12-factor 应用中，进程是一等公民。12-Factor 应用的进程主要借鉴于 unix 守护进程模型 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的 进程类型 。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。
• 这并不包括个别较为特殊的进程，例如通过虚拟机的线程处理并发的内部运算，或是使用诸如 EventMachine, Twisted, Node.js 的异步/事件触发模型。但一台独立的虚拟机的扩展有瓶颈（垂直扩展），所以应用程序必须可以在多台物理机器间跨进程工作。
• 上述进程模型会在系统急需扩展时大放异彩。 12-Factor 应用的进程所具备的无共享，水平分区的特性意味着添加并发会变得简单而稳妥。这些进程的类型以及每个类型中进程的数量就被称作进程构成 。
• 12-Factor 应用的进程 不需要守护进程 或是写入 PID 文件。相反的，应该借助操作系统的进程管理器(例如 systemd ，分布式的进程管理云平台，或是类似 Foreman 的工具)，来管理输出流 ，响应崩溃的进程，以及处理用户触发的重启和关闭超级进程的请求。

5.2.9 Disposability（易处理）

• Maximize robustness with fast startup and graceful shutdown：快速启动和优雅终止可最大化健壮性。

• 12-Factor 应用的 进程是易处理（disposable）的，意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用，迅速部署变化的代码或配置 ，稳健的部署应用。

• 进程应当追求最小启动时间 。 理想状态下，进程从敲下命令到真正启动并等待请求的时间应该只需很短的时间。更少的启动时间提供了更敏捷的发布以及扩展过程，此外还增加了健壮性，因为进程管理器可以在授权情形下容易的将进程搬到新的物理机器上。
• 进程一旦接收 终止信号（SIGTERM） 就会优雅的终止 。就网络进程而言，优雅终止是指停止监听服务的端口，即拒绝所有新的请求，并继续执行当前已接收的请求，然后退出。此类型的进程所隐含的要求是HTTP请求大多都很短(不会超过几秒钟)，而在长时间轮询中，客户端在丢失连接后应该马上尝试重连。
• 对于 worker 进程来说，优雅终止是指将当前任务退回队列。例如，RabbitMQ 中，worker 可以发送一个NACK信号。
• Beanstalkd 中，任务终止并退回队列会在worker断开时自动触发。有锁机制的系统诸如 Delayed Job 则需要确定释放了系统资源。此类型的进程所隐含的要求是，任务都应该可重复执行 ， 这主要由将结果包装进事务或是使重复操作幂等来实现。
• 进程还应当在面对突然死亡时保持健壮，例如底层硬件故障。虽然这种情况比起优雅终止来说少之又少，但终究有可能发生。一种推荐的方式是使用一个健壮的后端队列，例如 Beanstalkd ，它可以在客户端断开或超时后自动退回任务。无论如何，12-Factor 应用都应该可以设计能够应对意外的、不优雅的终结。Crash-only design 将这种概念转化为 合乎逻辑的理论。

5.2.10 Dev/prod parity（开发环境和线上环境等价）

• Keep development, staging, and production as similar as possible：尽可能的保持开发、预发布、线上环境相同。

• 从以往经验来看，开发环境（即开发人员的本地 部署）和线上环境（外部用户访问的真实部署）之间存在着很多差异。这些差异表现在以下三个方面：

  • 时间差异： 开发人员正在编写的代码可能需要几天，几周，甚至几个月才会上线。
  • 人员差异： 开发人员编写代码，运维人员部署代码。
  • 工具差异： 开发人员或许使用 Nginx，SQLite，OS X，而线上环境使用 Apache，MySQL 以及 Linux。
• 12-Factor 应用想要做到 持续部署 就必须缩小本地与线上差异。 再回头看上面所描述的三个差异:
  • 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。
  • 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。
  • 缩小工具差异：尽量保证开发环境以及线上环境的一致性。
• 传统应用 12-Factor 应用每次部署间隔数周几小时开发人员 vs 运维人员不同的人相同的人开发环境 vs 线上环境不同尽量接近。
• 后端服务是保持开发与线上等价的重要部分，例如数据库，队列系统，以及缓存。许多语言都提供了简化获取后端服务的类库，例如不同类型服务的 适配器 。
• 类型语言类库适配器数据库 Ruby/RailsActiveRecordMySQL, PostgreSQL, SQLite队列Python/DjangoCeleryRabbitMQ, Beanstalkd, Redis缓存Ruby/RailsActiveSupport::CacheMemory, filesystem, Memcached 。
• 开发人员有时会觉得在本地环境中使用轻量的后端服务具有很强的吸引力，而那些更重量级的健壮的后端服务应该使用在生产环境。例如，本地使用 SQLite 线上使用 PostgreSQL；又如本地缓存在进程内存中而线上存入 Memcached。
• 12-Factor 应用的开发人员应该反对在不同环境间使用不同的后端服务 ，即使适配器已经可以几乎消除使用上的差异。这是因为，不同的后端服务意味着会突然出现的不兼容，从而导致测试、预发布都正常的代码在线上出现问题。这些错误会给持续部署带来阻力。从应用程序的生命周期来看，消除这种阻力需要花费很大的代价。
• 与此同时，轻量的本地服务也不像以前那样引人注目。借助于Homebrew，apt-get等现代的打包系统，诸如Memcached、PostgreSQL、RabbitMQ 等后端服务的安装与运行也并不复杂。此外，使用类似 Chef 和 Puppet 的声明式配置工具，结合像 Vagrant 这样轻量的虚拟环境就可以使得开发人员的本地环境与线上环境无限接近。与同步环境和持续部署所带来的益处相比，安装这些系统显然是值得的。
• 不同后端服务的适配器仍然是有用的，因为它们可以使移植后端服务变得简单。但应用的所有部署，这其中包括开发、预发布以及线上环境，都应该使用同一个后端服务的相同版本。

5.2.11 Logs（日志）

• Treat logs as event streams：将日志当做事件流。

• 日志使得应用程序运行的动作变得透明。在基于服务器的环境中，日志通常被写在硬盘的一个文件里，但这只是一种输出格式。

• 日志应该是事件流的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。日志没有确定开始和结束，但随着应用在运行会持续的增加。
• 12-factor应用本身从不考虑存储自己的输出流。 不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。
• 在预发布或线上部署中，每个进程的输出流由运行环境截获，并将其他输出流整理在一起，然后一并发送给一个或多个最终的处理程序，用于查看或是长期存档。这些存档路径对于应用来说不可见也不可配置，而是完全交给程序的运行环境管理。类似 Logplex 和 Fluentd 的开源工具可以达到这个目的。
• 这些事件流可以输出至文件，或者在终端实时观察。最重要的，输出流可以发送到 Splunk 这样的日志索引及分析系统，或 Hadoop/Hive 这样的通用数据存储系统。这些系统为查看应用的历史活动提供了强大而灵活的功能，包括：找出过去一段时间特殊的事件、图形化一个大规模的趋势，比如每分钟的请求量、根据用户定义的条件实时触发警报，比如每分钟的报错超过某个警戒线。

5.2.12 Admin processes（管理进程）

• Run admin/management tasks as one-off processes：后台管理任务当做一次性进程运行。

• 进程构成（process formation）是指用来处理应用的常规业务（比如处理 web 请求）的一组进程。与此不同，开发人员经常希望执行一些管理或维护应用的一次性任务，例如：

  • 运行数据移植（Django 中的 manage.py migrate, Rails 中的 rake db:migrate）。
  • 运行一个控制台（也被称为 REPL shell），来执行一些代码或是针对线上数据库做一些检查。大多数语言都通过解释器提供了一个 REPL 工具（python 或 perl） ，或是其他命令（Ruby 使用 irb, Rails 使用 rails console）。
  • 运行一些提交到代码仓库的一次性脚本。
• 一次性管理进程应该和正常的 常驻进程 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的 代码 和 配置 ，基于某个 发布版本 运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。
• 所有进程类型应该使用同样的 依赖隔离 技术。例如，如果Ruby的web进程使用了命令 bundle exec thin start ，那么数据库移植应使用 bundle exec rake db:migrate 。同样的，如果一个 Python 程序使用了 Virtualenv，则需要在运行 Tornado Web 服务器和任何 manage.py 管理进程时引入 bin/python 。
• 12-factor 尤其青睐那些提供了 REPL shell 的语言，因为那会让运行一次性脚本变得简单。在本地部署中，开发人员直接在命令行使用 shell 命令调用一次性管理进程。在线上部署中，开发人员依旧可以使用ssh或是运行环境提供的其他机制来运行这样的进程。

5.3 蓝绿部署（Blue/Green Deployment）

• 运行两个相同的生产环境的实践，目的是最大程度地减少停机时间和风险。
• 一个在任何时间都在运行（例如，“蓝色”环境），而另一个（例如，“绿色”环境）处于空闲状态。
• 可以对空闲（绿色）环境进行更改，然后将生产负载切换到该环境。
• 这样可以最大程度地减少停机时间。 如果在新的（绿色）环境中出现问题，可以立即将生产负载切换回蓝色环境，从而将风险降到最低。

5.4 构建包（Buildpacks）

• 在Cloud Foundry社区内使用此术语来描述软件片段，这些软件片段充当以特定语言编写的应用程序的链接。
• 有二进制和静态文件（HTML，CSS，JavaScript和Nginx）构建包，以及Java，.Net，Go，Node.js，PHP，Python和Ruby的构建包。

5.5 云应用平台（Cloud Application Platform）

• 为云计算提供平台即服务（PaaS）的软件：PaaS通常被认为是可用于将软件部署到云计算基础架构的东西。 它还可以用于在整个开发，测试和部署周期中连续交付软件。

5.6 云原生（Cloud-native）

• 云原生开发不关心在何处托管新应用或服务，而是如何创建它。 云原生原则规定，应将应用程序和服务托管在能够扩展到成千上万个自我修复的多租户节点的分布式系统环境中。 必须将它们包装在容器中，进行动态管理并围绕微服务进行定位。

5.7 云提供商界面（Cloud Provider Interface）

• 略。

5.8 容器（Containers）

• 通过容器，轻量、便捷的运行和扩展程序

5.9 DevOps

• 开发、运维均需考虑。

5.10 数字化转型（Digital Transformation）

• 重点关注软件，数据流和用户体验，而不是有形的 IT 资产。

5.11 分布式系统（Distributed System）

• 未来我们经常会处理大型分布式系统。

5.12 IaaS（Infrastructure-as-a-Service）

• 提供基础设施，如计算资源、存储、网络等。用户无需维护基础计算资源。

5.13 PaaS（Platform-as-a-Service）

• 提供好平台，用户无需自行搭建相关平台环境，直接使用即可。比如，阿里云的日志服务、高可用数据库服务。

5.14 SaaS（Software-as-a-Service）

• 用户通常要支付许可费而不是购买价。

5.15 FaaS（Function-as-a-Service）

• 是与新兴的无服务器基础架构相关的相对较新的术语。
• 正如通常将无服务器部署为处理小型，快速，事件驱动的需求（尤其是在IoT（物联网）部署中发现的需求）一样，FaaS是一种不涉及正在进行的应用程序服务的方法。 预计响应时间将非常快（以毫秒为单位）。

5.16 CaaS（Containers-as-a-Service）

• 容器即服务（Containers-as-a-Service）随着Docker的兴起而出现，现在被用来描述以任何容器技术编写的Web应用程序的交付。
• 通常将其与平台即服务Platform-as-a-Service（PaaS）进行比较，尽管这两个术语不一定是离散的。 （例如，通常将Docker视为写有应用程序的平台，而Cloud Foundry平台将自己的容器作为平台的一部分。）

5.17 微服务（Microservices）

• 在容器内交付的服务。 它们应可独立部署，并且通常在应用程序或体系结构中相互松散耦合。“微型”可能会引起误解，因为容器内提供的服务可能非常复杂和复杂。

5.18 私有云（Private Cloud）

• 虚拟化并作为云服务交付给单个企业的计算资源和应用程序。 计算资源位于本地（也称为本地或“本地”）或第三方托管的托管设备中。

5.19 公有云（Public Cloud）

• 由第三方（例如Amazon Web Services）提供和管理的计算资源。

5.20 混合云（Hybrid Cloud）

• 企业可以建立混合基础架构，私有云资源和公共云资源的组合。

5.21 多云架构（Multi-Cloud）

• 一个基础架构，它包含多个云，无论是私有云，公共云还是混合云。 多云策略可能涉及使用本地或托管的私有云基础架构以及Amazon Web Services（AWS），Google Compute Engine（GCE），Microsoft Azure或其他公共云。
• 没有严格的定义可循，因为每个公司都在确定最佳的云技术组合。 多云策略可以减轻供应商锁定的可能性，同时还可以微调企业在预算和成本，性能指标，计算和存储的角色以及地理要求之间取得平衡的需求。

5.22 开源（Open Source）

• 开源软件的主要优势在于它是由社区而不是由单个公司开发的，以促进更多样化的创新，避免组织团体思维。

5.23 无服务器（Serverless）

• 云计算领域中的这一最新术语是指来自云服务提供商或软件平台的服务，它们以秒而不是小时为单位进行度量，并且不会向用户显示特定的服务器实例。 对于用户来说，它们似乎是“无服务器的”，即使在后台某处仍运行着实际的服务器。
• 无服务器基础设施被认为是物联网部署的一种有前途的方法，物联网部署通常是事件驱动的，其特征是大量的小数据包爆发，并且需要显着的灵活性来适应在任何给定时期内广泛变化的资源需求。

5.24 静态文件（Staticfile）

• 除网络服务器外，不需要后端代码的应用或内容。
• 静态文件应用程序的示例包括前端 JavaScript 应用程序，静态 HTML 内容和 HTML / JavaScript 表单。

5.25 Stemcell

• 指的是Cloud Foundry中的映像，该映像包装有针对基础结构的特定包装。
• 它通常包含一个基本的最低操作系统“框架”，以及一些常用的预安装实用程序。

5.26 虚拟机（Virtual Machine）

• “虚拟机”是云计算基础架构中的一个实例，对用户而言，它似乎是具有特定资源的真实系统。 但是，提供商正在从多个系统的资源中创建此系统，以最大程度地利用数据中心设施内的资源，同时保持用户期望的预期功能和性能。

5.27 虚拟化（Virtualization）

• 对于云计算，这意味着可以将服务器资源与其原始系统分离，并合并到虚拟机中。这种方法允许使用每个服务器的更高百分比，并为用户提供一种根据需要扩大和缩小对服务器资源的访问的方法。

第六章： 云原生的定义

• 官网。

• 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API 。

• 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
• 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

第七章：云原生官方指导路线

• 官网。