提取码：45on
云原生（Cloud Native）的概念，由来自Pivotal的MattStine根据其多年的架构和咨询经验的总结于2013年首次提出并于2015年7月由隶属于 Linux 基金会的云原生计算基金会CNCF（Cloud Native Computing Foundation）详细定义：“云原生计算”是一个用于部署微服务应用的开源软件堆栈，其方式是把各个组件都打包到容器中并动态调度容器以优化计算资源利用率。
“云原生”应用价值
从CNCF的定义来看，采用基于云原生的技术和管理方法，将更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续服务能力。像Facebook 和Netflix 这样的大公司都已经在云原生技术上投入了大量的资源，而一些小的公司也意识到了该技术的价值。根据云原生技术实践的反馈，我们总结了如下一些优点。
1）快速迭代
利用云原生应用程序开发，意味着使用敏捷与可扩展的组件，如以Kubernetes为代表的容器来提供离散和可重用的功能，这些功能以良好描述的方式集成，甚至跨越多云等技术边界，这使得交付团队可以使用重复的自动化和编排来快速迭代。
2）自动部署
云原生方法远优于传统的面向虚拟化的业务流程，传统方法需要投入大量的精力来构建开发环境，以及软件交付过程中的其他不同环境。而云原生架构具备自动化和组合功能，并且依赖于可靠、经过验证和审核的已知良好流程的基础，交付十分敏捷，而不再需要人工干预重复执行。
3）独立高效
云原生带来了微服务化架构，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发、甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。
云原生的设计哲学 云原生一词已经被过度的采用，很多软件都号称是云原生，很多打着云原生旗号的会议也如雨后春笋般涌现。
云原生本身甚至不能称为是一种架构，它首先是一种基础设施，运行在其上的应用称作云原生应用，只有符合云原生设计哲学的应用架构才叫云原生应用架构。
云原生的设计理念 云原生系统的设计理念如下:
面向分布式设计（Distribution）：容器、微服务、API 驱动的开发； 面向配置设计（Configuration）：一个镜像，多个环境配置； 面向韧性设计（Resistancy）：故障容忍和自愈； 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应； 面向交付设计（Delivery）：自动拉起，缩短交付时间； 面向性能设计（Performance）：响应式，并发和资源高效利用； 面向自动化设计（Automation）：自动化的 DevOps； 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪； 面向安全性设计（Security）：安全端点、API Gateway、端到端加密； 以上的设计理念很多都是继承自分布式应用的设计理念。虽然有如此多的理念但是我们仍然无法辨认什么样的设施才是云原生基础设施，不过可以先用排除法，我将解释什么不是云原生基础设施。
什么不是云原生基础设施？ 云原生基础设施不等于在公有云上运行的基础设施。光是租用服务器并不会使您的基础设施云原生化。管理 IaaS 的流程与运维物理数据中心没什么两样，将现有架构迁移到云上也未必能获得回报。
云原生不是指在容器中运行应用程序。Netflix 率先推出云原生基础设施时，几乎所有应用程序部署在虚拟机中，而不是在容器中。改变应用程序的打包方式并不意味着就会增加自治系统的可扩展性和优势。即使应用程序是通过 CI/CD 渠道自动构建和部署的，也不意味着您就可以从增强 API 驱动部署的基础设施中受益。
这也并不意味着您只能运行容器编排器（例如 Kubernetes 和 Mesos）。容器编排器提供了云原生基础设施所需的许多平台功能，但并未按预期方式使用这些功能，这意味着您的应用程序会在一组服务器上运行，被动态调度。这是一个非常好的起步，但仍有许多工作要做。
调度器与编排器
术语 “调度器” 和 “编排器” 通常可以互换使用。
在大多数情况下，编排器负责集群中的所有资源利用（例如：存储，网络和 CPU）。该术语典型地用于描述执行许多任务的产品，如健康检查和云自动化。
调度器是编排平台的一个子集，仅负责选择运行在每台服务器上的进程和服务。
云原生不是微服务或基础设施即代码。微服务意味着更快的开发周期和更小的独特功能，但是单片应用程序可以具有相同的功能，使其能够通过软件有效管理，并且还可以从云原生基础设施中受益。
基础设施即代码以机器可解析语言或领域特定语言（DSL）定义、自动化您的基础设施。将代码应用于基础架构的传统工具包括配置管理工具（例如 Chef 和 Puppet）。这些工具在自动执行任务和提供一致性方面有很大帮助，但是它们在提供必要的抽象来描述超出单个服务器的基础设施方面存在缺陷。
配置管理工具一次自动化一台服务器，并依靠人员将服务器提供的功能绑定在一起。这将人类定位为基础设施规模的潜在瓶颈。这些工具也不会使构建完整系统所需的云基础设施（例如存储和网络）的额外部分自动化。
尽管配置管理工具为操作系统的资源（例如软件包管理器）提供了一些抽象，但它们并没有抽象出足够的底层操作系统来轻松管理它。如果一位工程师想要管理系统中的每个软件包和文件，这将是一个非常艰苦的过程，并且对于每个配置变体都是独一无二的。同样，定义不存在或不正确的资源的配置管理仅消耗系统资源并且不能提供任何价值。
虽然配置管理工具可以帮助自动化部分基础设施，但它们无法更好地管理应用程序。我们将在后面的章节中通过查看部署，管理，测试和操作基础架构的流程，探讨云原生基础设施的不同之处，但首先，我们将了解哪些应用程序是成功的以及应该何时与原生基础设施一起使用。
云原生应用程序 就像云改变了业务和基础设施之间的关系一样，云原生应用程序也改变了应用程序和基础设施之间的关系。我们需要了解与传统应用程序相比，云本身有什么不同，因此我们需要了解它们与基础设施的新关系。
为了写好本书，也为了有一个共享词汇表，我们需要定义 “云原生应用程序” 是什么意思。云原生与 12 因素应用程序不同，即使它们可能共享一些类似的特征。如果你想了解更多细节，请阅读 Kevin Hoffman 撰写的 “超越 12 因素应用程序”（O'Reilly，2012）。
云原生应用程序被设计为在平台上运行，并设计用于弹性，敏捷性，可操作性和可观察性。弹性包含失败而不是试图阻止它们；它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。可观察性提供信息来回答有关应用程序状态的问题。
云原生定义
云原生应用程序的定义仍在发展中。还有像 CNCF 这样的组织可以提供其他的定义。
