云原生 简介
一、云原生简介
1、发展历程
- 2004年开始，Google已在内部大规模地使用容器技术。
- 2008年，Google将 Cgroups合并进入了Linux内核。
- 2013 年，Docker 项目正式发布。
- 2014年，Kubernetes项目正式发布。
- 2015年，由Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了CNCF(Cloud Native Computing Foundation)云原生计算基金会。
- 2017年，CNCF达到170个成员和14个基金项目。
- 2018年，CNCF成立三周年有了195个成员，19个基金会项目和11个孵化项目。
- 2022年，全球187国家、820+企业成员、130+项目、16万以上开发者。
2、云原生定义
云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
变迁历程：
云原生（CloudNative）是由Pivotal公司的Matt Stine于2013年首次提出的概念。
2015年，Matt Stine于《迁移到云原生架构》中定义了符合云原生的几个特征：
- 符合 12 因素应用
- 面向微服务架构
- 自服务敏捷架构
- 基于 API 的协作
- 抗脆弱性
2017年，Matt Stine将云原生架构归纳为：
- 模块化
- 可观测
- 可部署
- 可测试
- 可替换
- 可处理
现在Pivotal最新官网对云原生概括为4个要点：
- DevOps
- 持续交付
- 微服务
- 容器
- 云原生安全
十二因素应用：
十二因素应用程序，是一种被广泛认可的用于构建基于云的应用程序的方法。 它介绍了一系列原则和做法，开发人员在构建针对新式云环境进行优化的应用程序时需要遵循这些内容。
- 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
- 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
- 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
- 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
- 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。
| 因素 | 说明 |
|---|---|
| 1、基本代码 | 一份基准代码记录在版本控制中，多份部署。 |
| 2、依赖项 | 在每个微服务显式地声明和隔离相互之间的依赖。只有与应用程序的用途唯一相关的代码存储在源代码控制系统中。 |
| 3、配置 | 配置信息以环境变量或独立配置文件的形式来定义的设置，注入到各种运行环境中。 |
| 4、后端服务 | 鼓励将外部组件，如数据库、消息代理以及可由系统人员提供和维护的独立服务作为附加资源。通过API等方式相互调用。 |
| 5、构建、发布、运行 | 严格区分构建和运行阶段。将部署过程分解为三个可复制的阶段，可以在任何时候进行实例化。 |
| 6、进程 | 将应用程序作为一个或多个无状态进程执行。当进程是无状态的时候，可以添加和删除实例，以解决给定时间点的特定负载负担。由于每个进程都是独立运行的，无状态可以防止意想不到的副作用。 |
| 7、端口绑定 | 服务或应用程序可以通过端口号而不是域名来对外提供访问识别。 |
| 8、并发 | 根据进程的用途来组织进程，然后将这些进程分开，以便根据需求来扩展和缩小。例如当访问增加时通过多副本方式进行弹性横向扩展。 |
| 9、易处理 | 快速启动和优雅终止可最大程度上保持服务可用性。 |
| 10、开发与生产环境等价 | 尽可能保持开发、预发布和生产环境相同。所有的部署路径都应是相似的但又是独立的 |
| 11、日志记录 | 将所有运行中的进程和服务的输出流统一分类存储。可以使人员快速方便的查看 |
| 12、管理进程 | 将管理任务作为一次性进程运行，且和正常的业务进程使用同样的运行环境。 |
为了使应用程序能够真正利用现代云基础设施和工具，并在云中蓬勃发展，而不是仅仅在云中生存，Kevin Hoffman 修订了最初的12个因素，并增加了三个额外的因素——15因素应用程序方法论: 《超越12因素应用程序》。
| 新要素 | 说明 |
|---|---|
| 13、API 优先 | 使一切成为服务。 |
| 14、遥测 | 确保设计包括监视、特定于域和运行状况/系统数据的集合。让云端的应用程序及其行为具有更深层次的可见性。 |
| 15、认证和授权 | 应用程序可以使用基于以角色为基础的访问控制来保护其端点。角色规定调用的客户端是否具有足够的权限，以便应用程序能够响应请求 |
3、CNCF介绍
CNCF，英文全称为Cloud Native Computing Foundation，中文译为“云原生计算基金会”。成立于2015年12月11日。
成立这个组织的初衷：
- 推动云原生计算可持续发展；
- 帮助云原生技术开发人员快速地构建出色的产品；
- CNCF的使命是让云原生计算无处不在
CNCF通过建立社区、管理众多开源项目等手段来推广技术和生态系统发展。
CNCF 是目前云计算领域最成功的开源基金会之一，是 Kubernetes、 etcd、Envoy 等知名开源项目的托管基金会。
CNCF官网：https://www.cncf.io/
CNCF基于著名的鸿沟理论开展项目管理，将项目分为沙盒项目(Sandbox)、孵化项目(Incubating)、毕业项目(Graduated)。基于该理论，CNCF技术监督委员会制定了严格的项目管理制度和项目毕业标准，保证毕业的项目具有采用率、健康的变化率以及来自多个组织的提交人等。
CNCF Landscape：
CNCF Landscape是CNCF中的一个重要项目，它始于2016年11月，旨在为云原生应用者提供一个资源地图，帮助企业和开发人员快速了解云原生体系的全貌。
CNCF Landscape最重要的产出包括一个路线图和一个全景图。路线图（Trail Map）是CNCF对云原生用户使用开源项目以及云原生技术的推荐过程。在路线图的每个步骤中，用户都可以选择供应商支持的产品或自己动手使用开源项目。
CNCF Landscape路线图从实践步骤上帮助用户梳理了整个云原生应用的最佳流程。然而整个实践过程中的每个环节，用户都需要了解有哪些具体的软件和产品选择，这就是CNCF Landscape全景图的作用。
全景图地址: https://landscape.cncf.io/
二、云原生相关技术
依据CNCF发布的云原生1.0版本的定义，云原生技术主要包括容器化、微服务、服务网格、不可变基础设施以及声明式API。
- 容器化：以Docker、Containerd、为代表的容器运行技术。
- 微服务：微服务架构通过将大的系统按照业务服务的粒度进行拆分，使每个服务可独立开发、测试、验证和部署。
- 服务网格：服务网格是用于处理服务间通信的专用基础设施层，负责在微服务间进行可靠地请求传递。如Service Mesh等。
- 不可变基础设施：可以理解为一个应用运行所需要的基本运行需求，不可变最基本的就是指运行服务的服务器在完成部署后，就不在进行更改，比如镜像等。
- 声明式API：描述应用程序的运行状态，并且由系统来决定如何来创建这个环境。简单来说就是 我们不需要关心任何过程细节。过程是由工具自己内部figure out、内部执行的。
