到底什么是 “云原生”？

2020-03-162020-03-16 10:37:20 阅读 5K0

同学，你听说过 “云原生” 吗？

我相信大部分人会回答：“Yes，I do.”

是的，作为云计算领域的一个新兴概念，云原生现在频繁出现在我们的视野中。很多互联网大咖把它奉为至宝，走到哪说到哪。

那么，我们不仅会好奇，究竟什么是 “云原生”？它会给我们带来什么改变？

今天这篇文章，我们来探寻答案。

云原生的起源

介绍云原生之前，我们先介绍一下 CNCF。

CNCF，全称为 Cloud Native Computing Foundation，中文译为 “云原生计算基金会”。

这个基金会成立于 2015 年 12 月 11 日，属于 Linux 基金会旗下。

CNCF 致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。

所以说，CNCF 是云原生领域影响力最大最有话语权的组织。

说起 CNCF 的故事，还要从Cgroups（control groups，控制组群）开始说起。

十六年前，也就是 2004 年，谷歌开始使用容器技术。到了 2006 年，谷歌发布了 Cgroups，最初叫 Process Container（进程容器）。

Process Container 的目的非常直白，它希望能够像虚拟化技术那样，给进程提供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力。

带着这样的设计思路，Process Container 发布后第二年就进入了 Linux 内核主干。

因为在 Linux 内核中，容器（container）这个名词有许多不同的意义，为避免混乱，就更名为 Control Groups，也就是 Cgroups。

2013 年，Docker 项目正式发布，2014 年，K8s 项目也正式发布。

K8s 项目的初衷，就是提供一种方式去帮助大家方便、快速、优雅地管理容器。（K8s 是云原生的基石，后面会细讲。）

在 Google 和 Redhat 发布了 K8s 之后，这个项目的发展速度非常之快。

2015 年，由 Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了 CNCF 云原生基金会。

CNCF 成立之初，就有 22 个创始会员，而且 K8s 也成为了 CNCF 托管的第一个开源项目。

CNCF 一直保持高速发展。截止 2020 年 2 月，已有 433 个会员。

会员名单（部分）

那么，CNCF 是如何定义云原生的呢？

如下图所示：

翻译为中文：

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

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

除了 CNCF 之外，网络上还流传着另一个版本的 “云原生” 定义和来源——

这种说法认为，是 Pivotal 公司的 Matt Stine，于 2013 年首次提出云原生概念。

2015 年，云原生刚推广时，Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12 因素、微服务、自敏捷架构、基于 API 协作、扛脆弱性。

到了 2017 年，Matt Stine 改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理 6 特质。而 Pivotal 官网对云原生概括为 4 个要点：DevOps + 持续交付 + 微服务 + 容器。

云原生所需能力与特征 by:CNCF 大使 宋净超

MattStine 认为云原生它是一个思想的集合，包括 DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等。

云原生既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等），可以说是一系列云技术、企业管理方法的集合。

我们还是以 CNCF 官方的定义为准吧。

按 CNCF 的定义，云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

那么，这些技术都是什么？这些技术有什么联系？

云原生的代表技术

• 容器

一般我们说的 “容器”（LinuxContainer，LXC），都是 “Linux 容器”（当然微软也在搞容器，但还没 linux 那么成熟）。

开源解决方案供应商红帽官网给出的容器定义：

Linux® 容器是与系统其他部分隔离开的一系列进程。

运行这些进程所需的所有文件都由另一个镜像提供，这意味着从开发到测试再到生产的整个过程中，Linux 容器都具有可移植性和一致性。

因而，相对于依赖重复传统测试环境的开发渠道，容器的运行速度要快得多。容器比较普遍也易于使用，因此也成了 IT 安全方面的重要组成部分。

容器提供进程级的隔离，可以将操作系统管理的资源划分到相互隔离的组中，在相互隔离的组之间解决资源使用存在冲突的问题。

比如应用程序（Application）APP 1 ，只能在 centos 操作系统上运行；APP2 只能在 ubuntu 操作系统上运行。而同一个操作系统同时运行 APP1 和 APP2 就产生冲突。容器技术则恰恰可以解决这类问题。目前主流的容器技术有 Docker、LXD 以及 RKT 等。

• Docker

说到容器，就不得不说 Docker。

2010 年，几个大胡子的年轻人在美国旧金山成立了一家名叫 “dotCloud” 的公司。这家公司主要提供基于 PaaS 的云计算技术服务。具体来说，是和 LXC 有关的容器技术。

LXC，就是 Linux 容器虚拟技术（Linux container）

后来，dotCloud 公司将自己的容器技术进行了简化和标准化，并命名为——Docker。

Docker 项目发布时，无非也是 LXC 的一个使用者。它创建和使用应用容器的逻辑跟 Warden 等竞争对手没有本质不同。

不过，我们现在也知道，真正让 PaaS 项目无所适从的，是 Docker 项目最厉害的杀手锏：容器镜像。

Docker 项目通过容器镜像，直接将一个应用运行所需的完整环境，即：整个操作系统的文件系统也打包了进去。

这种思路，可算是解决了困扰 PaaS 用户已久的一致性问题，制作一个 “一次发布、随处运行” 的 Docker 镜像的意义，一下子就比制作一个连开发和测试环境都无法统一的 Buildpack 高明了太多。

Docker 项目大大降低了容器技术的使用门槛。轻量级，可移植，虚拟化，语言无关，写了程序扔上去做成镜像可以随处部署和运行，开发、测试和生产环境彻底统一了，还能进行资源管控和虚拟化。

Docker 作为一种开源应用容器引擎，是为开发人员和系统管理员设计的用于构建、发布和运行分布式应用的平台，典型的 Docker 平台 Kubernetes、Openshift V3、Flynn、Deis 等。

Docker 允许开发人员将各种应用以及依赖包打包到一个可移植的 Docker 容器中，以 Docker 容器为资源分割和调度的基本单位，封装整个软件运行时的环境，然后发布到 Linux 机器上。

按照 Docker 的设计方案，应用软件的交付过程如同海上运输，操作系统 OS 如同一个货轮，每一个在 OS 基础上的软件都如同一个集装箱。

用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员（开发人员或系统管理员）定制。

如此一来，交付一个应用软件产品，就相当于交付一系列标准化组件的集合。

• Kubernetes

有了容器，就需要编排管理容器的生命周期。这里就要提到 kubernetes。

Kubernetes，这个单词来自于希腊语，含义是舵手或领航员。K8s 是它的缩写，用 “8” 字替代了 “ubernete” 这 8 个字符。

K8s 并不是一件全新的发明。它是谷歌根据其内部使用的 Borg 改造成的一个通用容器编排调度器，于 2014 年 6 月开源。

同年 7 月，微软、Red Hat、IBM、Docker 等公司，相继加入 K8s。

2015 年，谷歌将其捐赠给 Linux 基金会下属的云原生计算基金会（CNCF），K8s 也成为 CNCF 第一个项目。

云可以为我们提供稳定而唾手可得的基础设施，但是业务上云成了一个难题，K8s 的出现与其说是从最初的容器编排解决方案开始，倒不如说是为了解决应用上云（即云原生应用）这个难题。

CNCF 中托管的一系列项目，即致力于云原生应用整个生命周期的管理，从部署平台、日志收集、Service Mesh（服务网格）、服务发现、分布式追踪、监控以及安全等各个领域通过开源软件为我们提供一整套解决方案。

Kubernetes 作为云应用的部署标准，直接面向业务应用，大大提高了云应用的可移植性，解决云厂商锁定的问题，让云应用可以在夸云之间无缝迁移，甚至用来管理混合云，成为企业 IT 云平台的新标准。

• 微服务

微服务需要从两个方面去理解：什么是 “微”、什么是 “服务”。

微，狭义来讲就是体积小。

著名的 “2 pizza 团队” 很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos 提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来只需要 2 个披萨就够了）。

而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

传统的单体架构，是以整个系统为单位进行部署。而微服务，则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。

对于单体应用，如果发现某一业务的请求量非常大，那么是无法单独扩展该业务的，只能拷贝整个单体应用，再部署一套环境，来实现集群。

正因为单体应用的缺陷，才有了微服务。

微服务和单体应用的区别，可以用 Martin Fowler 的这张图来解释：

图中左边是单体架构的集群，右边是微服务集群。

什么意思呢？比如根据每个服务的吞吐量不同，支付服务需要部署 20 台机器，用户服务需要部署 30 台机器，而商品服务只需要部署 10 台机器。这种灵活部署只有微服务架构才能实现。

而近几年流行的 Docker，为微服务架构提供了有效的容器。

• 服务网格

服务网格 (Service Mesh)，是指用以处理服务与服务之间通信的基础设施层。

其最早由 Buoyant 公司（开发 Service Mesh 项目 Linkerd 的公司）提出，并在内部使用。该公司 2016 年 9 月 29 日第一次公开使用这个术语。

Service Mesh 一般用于微服务应用的可配置基础架构层 (configurable infrastructure layer)。Istio(由 Google、IBM、Lyft 公司在背后进行支持) 是目前最广为人知的一款服务网格架构。

Kubernetes 是目前 Istio 唯一支持的容器组织框架。

为什么 Service Mesh 这么受欢迎？

对许多公司来说，Docker 和 Kubernetes 这样的工具已经 “解决了部署问题”，或者说几乎解决了。但他们还没有解决运行时的问题，这就是服务网格的由来。

什么是解决了部署问题？

使用 Docker 和 Kubernetes 等功能可显著减轻部署的增量操作负担。使用这些工具，部署 100 个应用或服务不再是部署单个应用的 100 倍。

这是向前迈出的一大步。对许多公司来说，这导致采用微服务的成本大幅降低。这不仅是因为 Docker 和 Kubernetes 所提供了强大的抽象，而且还因为它们使整个组织的打包和部署模式过程标准化了。

Service Mesh 的出现，弥补了 Kubernetes 在微服务的连接、管理和监控方面的短板，为 Kubernetes 提供更好的应用和服务管理。

因此，Service Mesh 的代表 Istio 一经推出，就被认为是可以和 Kubernetes 形成双剑合璧效果的微服务管理的利器，受到了业界的推崇。

• 不可变基础设施

在传统的可变服务器基础架构中，服务器会不断更新和修改。

使用此类基础架构的工程师和管理员可以通过 SSH 连接到他们的服务器，手动升级或降级软件包，逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。

换句话说，这些服务器是可变的。它们可以在创建后进行更改。

可变基础设施通常会导致以下问题：

在灾难发生的时候，难以重新构建服务。持续过多的手工操作，缺乏记录，会导致很难由标准初始化后的服务器来重新构建起等效的服务。

在服务运行过程中，持续的修改服务器，就犹如程序中的可变变量的值发生变化而引入的状态不一致的并发风险。这些对于服务器的修改，同样会引入中间状态，从而导致不可预知的问题。

不可变基础架构是另一种基础架构范例，其中服务器在部署后永远不会被修改。

程序设计中不可变变量（ImmutableVariable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不在进行更改。

不可变基础架构的好处，包括基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。

它可以缓解或完全防止可变基础架构中常见的问题，例如配置漂移和雪花服务器。但是，有效地使用它通常包括全面的部署自动化，云计算环境中的快速服务器配置，以及处理状态或短暂数据（如日志）的解决方案。

• 声明式 API

声明式（Declarative）的编程方式一直都会被工程师们拿来与命令式（Imperative）进行对比。

我们最常接触的其实是命令式编程，它要求我们描述为了达到某一个效果或者目标所需要完成的指令，常见的编程语言 Go、Ruby、C++ 其实都为开发者了命令式的编程方法，

声明式和命令式是两种截然不同的编程方式:

在命令式 API 中，我们可以直接发出服务器要执行的命令，例如： “运行容器”、“停止容器” 等；

在声明式 API 中，我们声明系统要执行的操作，系统将不断向该状态驱动。

通俗的说，命令式编程是第一人称，我要做什么，我要怎么做。

操作系统最喜欢这种编程范式了，操作系统几乎不用 “思考”, 只要一对一的将代码翻译成指令就可以了。

而声明式编程则类似于 “第二人称”， 也就是你要做什么。

有点 “” 产品经理”和 “开发” 之间的关系，“产品经理”只负责提需求，而 “开发” 怎么实现的，他并不关心。

让我们来总结一下上面提到的技术和工具：

k8s 是整个云原生的基石，云原生的整个生态体系都是依靠 k8s 建立起来的。

容器（Container）是 k8s 的底层引擎。

Docker 是应用最广的容器工具。

微服务是 docker 的好搭档。

服务网格是微服务的辅助，建立在 k8s 上的针对请求的扩展功能。

不可变基础设施是现代运维的基石。

声明式 API 是 k8s 的编码方式。

云原生的应用价值

由于篇幅关系，简单列举三项云原生应用价值。

1）快速迭代

利用云原生应用程序开发，意味着使用敏捷与可扩展的组件，如以 Kubernetes 为代表的容器来提供离散和可重用的功能，这些功能以良好描述的方式集成，甚至跨越多云等技术边界，这使得交付团队可以使用重复的自动化和编排来快速迭代。

2）自动部署

云原生方法远优于传统的面向虚拟化的业务流程，传统方法需要投入大量的精力来构建开发环境，以及软件交付过程中的其他不同环境。而云原生架构具备自动化和组合功能，并且依赖于可靠、经过验证和审核的已知良好流程的基础，交付十分敏捷，而不再需要人工干预重复执行。

3）独立高效

云原生带来了微服务化架构，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发、甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。

谈云原生就要谈云计算，不和云计算对比都是耍流氓。云计算的第一个浪潮是关于成本节约和业务敏捷性，尤其是云计算的基础设施更加廉价。

很多企业倾向于使用微服务架构来开发应用。微服务开发快速，职责单一，能够更快速的被客户所采纳。同时，这些应用能够通过快速迭代的方式，得到进化，赢得客户的认可。

云原生可以打通微服务开发、测试、部署、发布的整个流程环节。

云供应商为迎合市场，提供了满足各种场景方案的 API，例如用于定位的 Google Maps，用于社交协作的认证平台等。将所有这些 API 与企业业务的特性和功能混合在一起，可以让他们为客户构建独特的方案。所有这些整合都在 API 层面进行。这意味着，不管是移动应用还是传统的桌面应用都能无缝集成。

所以，采用云原生所开发的应用都且具备极强的可扩展性。

软件不可能不出故障。传统的企业级开发方式，需要有专职人员来对企业应用进行监控与维护。而在云原生架构下，底层的服务或者是 API 都由将部署到云中，等价于将繁重的运维工作转移给了云平台供应商。这意味着客户应用将得到更加专业的看护，同时，也节省了运维成本。

结 语

9 年前，Netscape 公司的创始人马克 · 安德森说：“软件正在吞噬世界”。

6 年前，OpenStack 基金会创始人 Jonathan Bryce 补充说：“世界的一切源于开源”。

再之后，业内普遍认同 “云计算已改变了天空的颜色”。

但近两年云计算概念又被清晰细分，“云原生” 才是那条最大的鱼。

“大鱼” 来了，我们能做的不是墨守成规，而是拥抱 “大鱼”。

让我们了解云原生，拥抱云原生，追随云原生。

参考资料：

1.Kubernetes 是什么？，Linux 中国

2.Kubernetes 与云原生应用概览，宋净超

1. 云原生的不同解释及正确含义，倚天码农

4.10 分钟看懂 Docker 和 K8S，鲜枣课堂

5.CNCF 官方大使张磊：什么是云原生？

本文分享自微信公众号 - 鲜枣课堂（xzclasscom），作者：白告天

原文出处及转载信息见文内详细说明，如有侵权，请联系 yunjia_community@tencent.com 删除。

原始发表时间：2020-03-04

本文参与腾讯云自媒体分享计划，欢迎正在阅读的你也加入，一起分享。

展开阅读全文

举报

点赞 6 分享

我来说两句

0 条评论

登录 后参与评论
https://cloud.tencent.com/developer/article/1598764