什么是云原生？

1. 云原生定义

CNCF，云原生计算基金会(Cloud Native Computing Foundation,CNCF)成立于2015年12月11日，由谷歌与Linux基金会联合创办，成立这个非盈利组织的目的是为了推广、孵化和标准化云原生相关的技术。

按照云原生基金会的定义，云原生是一类技术的统称，通过云原生技术，我们可以构建出更易于弹性扩展的应用程序，其包含容器、服务网格、微服务、不可变基础设施和声明式API等相关技术，这些技术能够构建容错性好、易于管理和便于观察的松耦合系统，结合可靠的自动化手段，相关工程师能够轻松对系统作出频繁和可预测的重大变更。

个人理解，云原生是为了充分利用服务器资源，降低软件构建和运维成本，提高软件交付质量和交付效率的一系列技术的统称，是一个软件工程方法论，软件架构思想，是云计算时代的新的软件文化。

2. 概念由来

⭐️ Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念.

⭐️ 2015年云原生计算基金会(CNCF)成立，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务

⭐️ 到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。

3. 云原生关键技术

》微服务架构：服务与服务之间通过高内聚低耦合的方式交互

传统单体架构设计，系统集成度高，低内聚紧耦合，系统可扩展性差。

微服务架构，将一个复杂的应用拆分成多个独立自治的服务，实现高内聚低耦合，对存在性能瓶颈的节点通过横向扩展可以快速提高系统整体性能，适应快速发展的互联网业务。

优势：

⭐️ 各个微服务之间业务逻辑是相对独立的。

⭐️ 各自独立开发，对技术栈没有限制。

⭐️ 各自都是独立的，封装其自己的数据存储技术、依赖项和编程平台。

⭐️ 微服务之间使用 HTTP/HTTPS、gRPC、WebSocket或AMQP等标准通信协议与其他微服务进行通信。

缺陷：

🚩 测试和运维难度大，服务治理变困难，响应时间变长，架构非常复杂，技术门槛高。

》容器：作为微服务的最佳载体，提供了一个自包含的打包方式

容器是一种打包应用的方式，可以打包应用中的所有软件和软件所依赖的环境，并可实现跨平台部署。容器关键技术包括：namespace 视图隔离，cgroups 资源隔离，Union File System 联合文件系统。容器具有以下优势：

⭐️ 容器可保持运行环境的一致性，做到一次打包，到处运行。

⭐️ 容器可使用独立的文件系统、存储、网络与资源配额。

⭐️ 与标准虚拟机相比，容器能同时提供效率和速度。

⭐️ 容器是微服务的最佳载体。

---

》容器编排：解决服务上云的部署问题

容器编排是自动化管理和协调容器的系统，专注于容器的生命周期管理和调度。核心功能包括：

⭐️ 容器调度：依据策略完成容器与宿主机绑定

⭐️ 资源管理：CPU、内存、GPU、Ports、Device

⭐️ 服务管理：DNS发现、命名空间、服务自动伸缩、服务自愈、滚动更新

容器编排软件是云原生的基础设施，Kubernetes 是当前最为流行的编排工具，作为CNCF基金会的首个毕业项目和金字招牌，甚至很多人认为云原生就是 Kubernetes 和其相关的一系列技术，虽然这样的说法是很不准确的，不过现在云原生技术确实和Kubernetes绑定的越来越紧密，由此而衍生了一大批的工具生态。

》服务网格：解决了服务治理的问题

服务网格是一个基础设施层，用于处理服务间通信，云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递，在实践中，服务网格通常是纤维一组轻量级的网络代理，它们与应用部署在一起，而对应用程序透明。服务网格的特点：

⭐️ 专用的基础设施层

⭐️ 轻量级高性能网络代理

⭐️ 提供安全的、快速的、可靠地服务间通讯

⭐️ 扩展 Kubernetes 的应用负载均衡机制，实现灰度发布

》不可变的基础设施：提高发布效率，提高系统稳定性

不可变基础设施的核心思想是任何基础设施的实例一旦创建之后变成为只读状态，如需修改和升级，则使用新的实例进行替换。可变的基础设施人工干预较多，需要人工去操作系统里进行各种更改;不可变的基础设施更偏向自动化，预先将基础设施及其依赖都定义好，只需要去触发新的变更就可以完成整体变更。

对于容器技术，当构建一个镜像，然后在镜像的基础上去部署业务。如果出现问题，不会去已有容器的里去做变更，而是从容器构建阶段去解决问题，重新打包构建新的镜像。所以从容器的角度，镜像就是一个不可变的基础设施。

所谓不可变，不是说它不变，而是在镜像构建阶段把所有的依赖和配置都打包好，作为一个整体进行更新。

更多参考：https://www.51cto.com/article/746801.html

》声明式API：让系统更加健壮

与声明式相对应的是命令式 API，通过命令告诉计算机，该怎么做，执行一系列操作然后得到想要的结果，计算机只是帮助开发者执行计算。直接发出让服务器执行的命令，例如：“运行容器”、“停止容器”等；声明式 API，用户只需要告诉计算机期望的结果，不需要列出执行的命令和步骤，具体怎么做有计算机自己完成。

**为什么声明式使系统更加健壮？**声明式 API 描述最终运行环境的状态，由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个 Nginx 的集群”，而不是把创建 Nginx 的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。

Kubernetes 的 API 就是一种声明式 API。Kubernetes 中，所有应用的部署都是基于 YAML 文件的，这实际上就是一种 Infrastructure as Code，可支持通过代码来管理基础设施和部署环境。

》DevOps：缩短研发周期，增加部署频率，更安全更敏捷

DevOps 使以前孤立的角色（开发、IT 运营、质量工程和安全）可以协调和协作，以生产更好、更可靠的产品。通过采用 DevOps 文化、做法和工具，团队能够更好地响应客户需求，增强对所构建应用程序的信心，更快地实现业务目标。

4. 云原生应用的设计

关于云原生应用该如何设计，Heroku团队提出的十二要素（Twelve-Factor）提供了很多非常有价值的建议。十二要素包含：

按照十二要素的要求，编码、开发、构建、运维等操作都需要被清晰界定和规范，应用需要专注在业务逻辑，将部署环境、运行依赖，状态保存、并发、日志等问题都交给云平台来处理。云原生应用的开发过程变成：快速响应业务需求开发精简的应用构建标准包，然后在不同的环境以不同配置动态部署，运行的各种依赖利用云平台解决。按照这些原则去设计自己的应用，应用会更易于使用云服务提供的标准能力，会更易于实现快速交付，更易于进行灵活扩展。

在十二要素发布后，Pivotal公司的Kevin Hoffman编写的Beyond the Twelve-Factor App一书中，又增加了三个新要素作为补充：

最后，要构建云原生的应用，下面是在应用研发上线过程中的一些建议：

• 代码里应该重点关注业务逻辑而不是其他
• 代码尽量不要有任何状态，状态都存到云服务里
• 代码里不要有和本应用无关的业务逻辑，它应该在其他应用里通过API调用
• 不要实现用于运维和服务治理和观测的具体逻辑，要依赖第三方库和云服务
• 不要硬编码地址等任何配置，这段代码要运行在很多环境
• 不要假定这段代码会部署在什么地址，会部署几个实例
• 不要假定程序永远不死，要保证单个实例的死去不要影响其他实例
• 构建结果是一个整体，不能把构建的代码部署后再去改动代码包里的内容

5. 趋势与展望

CNCF的项目全景图网址链接: https://landscape.cncf.io/

6. 参考资料：

1. https://zhuanlan.zhihu.com/p/499334409
2. https://zhuanlan.zhihu.com/p/68945404
3. https://zhuanlan.zhihu.com/p/150190166
4. https://zhuanlan.zhihu.com/p/120073918
5. https://www.jianshu.com/p/ccac4f129a4b
6. https://azure.microsoft.com/zh-cn/resources/cloud-computing-dictionary/what-is-devops/

关注公众号一起学习——无涯的计算机笔记