共计 7768 个字符，预计需要花费 20 分钟才能阅读完成。
云原生技术概谈
说起“云原生技术”，大家可能有点懵，只闻其声，不明其意。然而云原生背地典型的几个公司或者技术产品的名称可能大家常常听到：
比方容器技术的代表公司 docker；容器编排技术开源产品 kubernetes（因为 K 和 S 之间有 8 个字母简称 K8S）；服务网格 Service Mesh；
无服务器架构 Serverless；云原生基金会（CNCF）；以及这些技术背地的驰名公司 Google，IBM，Redhat，VMWare，等。
本文尝试从以下几个方面来“扒一扒”云原生，帮忙大家从各个不同的维度来了解云原生这个形象的概念。
云原生的定义
Pivotal：云原生的提出者
2015 年来自 Pivotal 公司的 Matt Stine 编写了一本名为《迁徙到云原生利用架构》的电子书，提出云原生利用架构应该具备的几个次要特色：
a、合乎 12 因素利用 (Twelve-Factor Applications)
b、面向微服务架构 (Microservices)
c、自服务麻利架构 (Self-Service Agile Infrastructure)
d、基于 API 的合作 (API-Based Collaboration)
e、抗脆弱性 (Antifragility)
在 2017 年 10 月，也是 Matt Stine，在承受 InfoQ 采访时，则对云原生的定义做了小幅调整，将 Cloud Native Architectures 定义为具备以下六个特质：
a、模块化 (Modularity):（通过微服务）
b、可观测性 (Observability)
c、可部署性 (Deployability)
d、可测试性 (Testability)
e、可解决性 (Disposability)
f、可替换性 (Replaceability)
CNCF：云原生计算基金会
谈到云原生，就不得不说 CNCF，即云原生计算基金会，2015 年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包含亚马逊、微软、思科
等巨头，我国也有泛滥企业参加其中，包含华为、阿里、腾讯等。
目前 CNCF 所托管的我的项目已达 24 个，包含大家耳熟能详的 Kubernetes、etcd、gRPC、Prometheus 等。下图为其颁布的 Cloud Native Landscape，给
出了云原生生态的参考体系。更具体的信息请参见 https://landscape.cncf.io/
CNCF 对云原生的定义，也经验了几个阶段，起初 CNCF 对云原生的定义蕴含以下三个方面：
a、利用容器化 (software stack to be Containerized)
b、面向微服务架构 (Microservices oriented)
c、利用反对容器的编排调度 (Dynamically Orchestrated)
到了 2018 年，随着近几年来云原生生态的一直壮大，所有支流云计算供应商都退出了该基金会，且从 Cloud Native Landscape 中能够看出云原生无意蚕
食原先非云原生利用的局部。CNCF 基金会中的会员以及包容的我的项目越来越多，该定义曾经限度了云原生生态的倒退，CNCF 为云原生进行了从新定位。
2018 年 6 月，CNCF 正式对外颁布了更新之后的云原生的定义（蕴含中文版本）v1.0 版本：
a、云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微
服务、不可变基础设施和申明式 API。
b、这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩，云原生技术使工程师可能轻松地对系统作出频繁和可预测
的重大变更。
c、云原生计算基金会（CNCF）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为
公众所用。
下图从工夫上展现了 CNCF 对云原生定义的变动：
云原生技术的前世今生
Docker“横空出世”
1、2010 年几个大胡子年轻人在旧金山成立了一家做 PaaS 平台的公司，起名为 dotCloud，尽管 dotCloud 期间取得过一些融资，但随着大厂商（微软、谷歌、亚
马逊等）杀入 PaaS 平台，dotCloud 举步维艰。
2、2013 年的 IT 技术，AWS 和 openstack 如日中天，过后是 IAAS 的天下，云里雾里的云计算最终都落地成了虚拟机以及私有云的资源账单！
3、2013 年开源的 paas 我的项目 Cloud Foundry 却属于云计算中的一股清流，在经验了艰巨的 paas 概念遍及阶段后，吸引了少量国内外厂商参加 paas 开源平台的建
设。
4、而 2013 年之前“Docker”这个词还只是 dotCloud 这个公司外部的一个容器我的项目的名称，dotCloud 这个公司的创业者们也是 Paas 热潮中的一份子，然而 dotCloud
微不足道，小的可怜，他主打的产品和 Cloud Foundry 社区脱节，长期无人问津，眼看着就要被 PAAS 潮流有情的摈弃！
5、2013 年 dotCloud 公司决定开源本人的容器我的项目“Docker”，显然这在过后没人 Care，因为“容器”不是陈腐玩意，大家都晓得他是基于 linux 的内核技术（namespace
和 cgroupe）实现，这和 Cloud Foundry 底层技术大部分都一样。然而恰好是那一小部分的不一样（docker 的镜像打包技术）造就了 Docker 的雄起。
6、2013 年，Docker 我的项目开源后短短几个月内迅速崛起，红遍大江南北，以秋风扫落叶之势迅速干掉其余 paas 社区，他们甚至都没资格成为 Docker 的竞争对手就
曾经出局，Docker 雄心勃勃大有对立容器江湖之势。
7、Docker 崛起的时候 CoreOS 也是其中的一员，在容器生态圈中 CoreOS 的标签就是：专为容器设计的操作系统。作为互补，CoreOS+Docker 已经也是容器部署
的明星套餐。CoreOS 为 Docker 的推广和源码社区都做出了微小的奉献。
8、2014 年随着 Docker 通过开发或者收买，逐步完善容器云平台的各个组件，筹备打造 Docker 本人的生态圈当前，CoreOS 发现 docker 想摈弃本人，docker 的一
系列布局与本人有间接竞争关系，因而 CoreOS 也愤恨的公布了另一个开源容器引擎 Rocket 简称 rkt 作为两家的离别宣言，至此两家各奔前程！
“江湖大佬”出山
Google 公司秘而不宣的应用容器曾经有十几年了，本想要害时候做杀手锏，没想到 docker 竟然搞出了 docker 容器还开源了，且发展势头极其迅猛。Google 坐不
住了，放心本人的江湖位置受到挑战。于是财大气粗的 Google 就鼎力搀扶 docker 的“反对派”营垒 -CoreOS，kubernetes 一经推出就原生反对 rkt 容器引擎，并且在
2015 年 4 月 Google 还给 CoreOS 投资了 1200 万美刀，而 CoreOS 也公布了 Tectonic，成为首个反对企业版本 kubernetes 的公司。从此容器生态江湖分为两大阵营
Google 和 Docker。
“容器编排”群雄逐鹿
2014 年，当 Google 发现 CoreOS 在容器生态畛域切实不是 Docker 的竞争对手之后，决定换道超车，于当年发表推出 kubernetes 容器集群编排工具，并在 2014
年 6 月 7 日将初始版本代码提交到 Github 上齐全开源，当年 7 月 10 日微软、RedHat、IBM、Docker 退出 Kubernetes 开源社区。
2014 年的 Docker 公司雄心勃勃，于 2014 年底在 DockerCon 上公布了本人研发的“Docker 原生”容器集群治理我的项目 DockerSwarm，并想与 kubernetes 一较高下。
Mesosphere 公司的 Mesos + Marathon（马拉松）的我的项目更是晚期容器编排解决方案的领头羊，像是有 3 亿用户的 Twitter 以及苹果语音助手 Siri 就是应用 mesos 作为
后端集群管理工具。
但因为 kubernetes 基于 Google 外部应用的容器集群管理系统 Borg+Omega，在谷歌曾经安稳运行了 15 年，Google 将他们本人超大范畴的技术教训带到了容器
编排中，该填的坑早曾经被谷歌的技术大神们填了，因而推出后不到三年横扫 docker swarm 和 mesos marathon 容器编排工具。
CNCF 的成立
2015 年 7 月，由 Google 牵头并联结 linux 基金会以及一大票牛掰的技术公司（IBM、microsoft、redhat 等等）成立了 CNCF（Cloud Native Computing Foundation）
，紧接着就把 kubernetes1.0 版本的源代码募捐给 CNCF。
这给大家传递的信息就是 K8S 是大家的，因而 K8S 一入世就让大家趋之若鹜，而借着 CNCF，谷歌纠集了除了 docker 以外容器畛域的简直全副力量，此时 docker
如果不退出 CNCF 就会被 CNCF 摈弃掉。
起初 CNCF 就提出，如果容器要疾速倒退就必须要标准化，不能受控于一家公司，由谁来制作容器的一系列标准化？为了给 docker 机会，就让 docker 去制订规范
化（OCI），毕竟在容器畛域 Docker 的技术还是当先的，因而 docker 的容器运行时（runtime）从一开始的 LXC 进化到 libcontainer，再到最初的 runC，完全符合 OCI 规范！
尘埃落定
2017 年 10 月 17 日，随着 docker 发表反对 kubernetes 开始，容器编排的和平发表完结，整个行业曾经聚焦到 K8S 家门前！截止 2017 年 6 月，据 CNCF 统计：K8S
占据着 77% 的市场份额；docker swarm 则只有 21%，远远落后；而第三名 Mesos 则是 13%。
云计算的演进历史
谈到 Cloud Native，就不得不谈一谈 Cloud，疾速回顾一下云计算的历史，来帮忙咱们对云有个更理性的意识。
虚拟化技术的成熟
云计算的呈现和虚拟化技术的倒退和成熟密切相关，2000 年前后 x86 的虚拟机技术成熟后，云计算逐步倒退起来。
基于虚拟机的云计算
基于虚拟机技术，陆续呈现了 IaaS/PaaS/FaaS 等状态，以及他们的开源版本。
容器的衰亡和编排大战
2013 年 docker 呈现，容器技术成熟，而后围绕容器编排一场大战，最初在 2017 年底，kubernetes 胜出。2015 年 CNCF 成立，并在近年造成了 cloud native 生态。
云的状态变动
这是云的状态变动，能够看到：供应商提供的性能越来越多，而客户或者说利用须要本人治理的性能越来越少。
云计算历史回顾小结
云原生的利用是什么样子
微服务架构中的痛点
在当下的微服务实际中，Spring Cloud，Dubbo 作为支流的落地计划，在企业应用架构中施展越来越重要的作用。须要明确的是，
企业应用肯定是围绕业务进行的。无论采纳什么的架构落地，都是为了更好的为利用业务进行服务。从企业应用的个性思考，次要包含：
稳定性，安全性，扩展性，容错性。围绕着企业应用的这些特点，咱们来看一个典型的微服务企业架构模型，如图所示：
从这个典型的服务架构体系中，可能清晰的表明层级架构以及各层涵盖的职责。然而，恰好是这个看似清晰的微服务架构中，
暗藏着一个最大的痛点： 业务性能与非业务性能耦合在一起 。
当咱们的利用和非性能需要（基础设施）耦合在一起的时候，基础设施要进行降级的时候，就须要所有的利用一起来降级，这对于
利用来讲也是一个很大的苦楚。对于基础设施来讲，如果利用不降级的话，你就无奈实现基础设施能力的晋升。
微服务往云原生架构的演进
第一阶段：管制逻辑和业务逻辑耦合
为了实现业务逻辑，须要编写大量的管制逻辑，来解决服务发现，熔断等各种非性能逻辑，不仅效率低下，容易出错，而且节约人力。
第二阶段：类库或框架
应用类库或框架，将服务发现，熔断等各种非性能需要进行下沉，这打消了这部分性能的反复，提供了复用能力。但类库或框架个别
是语言绑定的，无奈提供平台无关的能力，并且无论是类库还是框架，和利用个别还是运行在一个过程内的，这也给性能降级带来了极大的麻烦。
第三阶段：代理
应用代理来进一步下沉非性能需要，这个方向是正确的，只是性能较为简陋，运维老本较高。
第四阶段：Sidecar
Sidecar pattern，即容器设计模式，利用同一 Pod 中容器能够共享各种 namespace 的能力，将利用容器与工具容器解耦，在 POD 启动
的时候主动的将 Sidecar 容器注入到 POD 中，应用程序无需感知。
举个简略的例子：实现利用日志收集
1、业务容器将日志写在一个 Volume 外面。
2、因为 Volume 在 Pod 外面是被共享的，所以日志容器，即 Sidecar 容器肯定能够通过共享该 Volume，间接把日志文件读出来，然
后存到近程存储外面。当初业界罕用的 Fluentd 日志过程或日志组件，基本上都是这样的工作形式。
Sidecar pattern 及 Mesh 化
Sidecar pattern，实质上体现了一种关注点拆散的思维，当应用程序无需关怀网络（服务发现 / 编解码 / 负载平衡）、流量配置（服务路由
/ 熔断 / 限流）、平安、可观测（指标、日志、追踪）等非性能个性的时候，此时咱们认为整个零碎曾经实现了 Mesh 化。当 Mesh 化实现的时候，
才真正做到了基础设施和利用能够独立的演进，能够在悄无声息中实现基础设施的降级，就像一架正在航行中的客机一样，能够在航行的过
程中实现引擎的替换，而乘客却不必感知。
更进一步的是，与业务环境相干的一些根底的 runtime（比方：CDB 云数据库，CMQ 音讯队列，等）再进一步进行下沉，成为云基础设施的
一部分的时候，这样就演进成一个更充沛的解耦的架构，咱们称之为无服务器架构 Serverless。
图：利用基础设施全面解耦
图：Service Mesh
云原生为什么要和云计算联合
置信不少研发人员会认为，云原生不就是应用 k8s 作为底座，将一些公共能力一直下沉，让下层利用专一于本身业务，而不必关怀底层基础设施
的一种架构思维和一系列组件么，这些我在 Local IDC 也能玩得起来，为什么必须要上云呢，上云到底有什么劣势呢？
要解释这种疑难，那么就必须要理解，上云和自建 IDC 相比，到底有哪些劣势？
云上弹性裸金属服务器 + k8s 为利用提供最佳计算基础设施
在云原生时代，传统的物理机 + 虚机模式曾经不适应高速增长的计算需要，因为传统虚构机会带来额定 8% – 10% 的性能损耗，这对于大规模散布
式零碎而言，无疑是一笔微小的资金节约；而 POD 带来的应用层隔离性，曾经和虚机十分靠近，因而在将来的大规模计算场景中，倒退的方向肯定是
裸金属 + 容器。
而大部分中小公司，都是没有自主弹性裸金属研发实力的，从这方面来说，上云的劣势比拟显著。上面是阿里神龙裸金属 + 容器服务的几大劣势，
可参考。
云上存储与计算拆散为利用开发带来微小收益
传统的服务器存储和计算部署在同一个物理服务器上，会存在一个资源节约的问题。比方，计算密集型服务对对磁盘的利用率低，导致存储资源
节约；存储密集型利用又会导致计算资源节约；计算与存储各自不能独立的扩大，导致运维效率低下，等。
云化存储正好解决了这几个痛点，利用只须要关怀 CPU 和内存，存储能够按需扩大；存储和计算不在同一个物理空间内，减速扩容变更效率，无
需本地数据迁徙。这些都是自建 IDC 很难做到的。
高速混合云网络的撑持
自建 IDC 往往只有很无限的 1 个或几个地区，无奈满足业务高速增长对流量在各区域自在调配的需要，比方当某地区热点暴发的时候，云上网络
能够疾速将网络流量引流到热点地区，而不会影响到整个零碎的稳固运行。
云原生时代对开发人员的要求
云原生时代，我认为对于开发人员，最重要的两个要求：拥抱云计算，拥抱 kubernetes。
拥抱云计算
云计算是云原生的载体，是云原生可能取得高可用性，高弹性，低成本的首选平台。
拥抱 kubernetes
Kubernetes 是云原生的关键所在，怎么强调都不为过。这里有一个被越来越多人认可的说法：Kubernetes 是云原生时代的 Linux。
对这句话，这里有两个重要的意识：
1、应该以 kubernetes 为底座进行能力建设：简略说就是如果是 kubernetes 已有的能力则间接应用，如果 k8s 的能力有余，则在 kubernetes
上做改良和加强，充分利用 k8s 的能力，而不是抉择忽视。
2、把 kubernetes 当 kubernetes 用：即要合乎 kubernetes 的理念和设计，遵循 kubernetes 的游戏规则。
谈到遵循 kubernetes 的游戏规则，外围在于遵循 kubernetes 的 CRD + Controller 模型：
- 如果 k8s 底座的能力不够：则应该去补充和增强 k8s 的能力，体现为实现新的 Controller。
- 如果 k8s 的形象不够：比如说对于某些简单场景，现有 CRD 不实用或不够用，则应该定义新的形象，体现为增加新的 CRD。
两者联合起来，加固 k8s 底座（Controller）+ 扩大 k8s 形象（CRD），就能够失去新的云原生基础设施。
总结
云原生是一系列技术或理念的汇合，包含但不限于容器、服务网格、微服务、不可变基础设施和申明式 API，云原生是构建和运行可
弹性扩大、容错性好、易于治理的零碎的最佳实际。
a、容器和资源编排带来效率和资源利用率晋升：弹性裸金属服务器 + 容器编排。
b、分布式系统的可弹性扩大与可靠性：存储与计算拆散 + 高速混合云网络的撑持。
c、凋谢规范带来的无供应商锁定：面向 k8s 编程，而不是面向 AWS，GCP 编程。
d、继续的交付带来的翻新迭代速度晋升：基础设施和利用独立演进，利用轻装前行，交付和翻新迭代速度失去大幅晋升。
说到底，技术是为了业务服务，任何技术的倒退，都是为了撑持业务疾速的试错，一直晋升业务零碎的交付效率，来满足市场的需要。
在这个 VUCA 时代，任何商业机会都会昙花一现，谁能最疾速的提供市场须要的产品或服务，谁就能在这个残暴的商业世界中存活下来。
这是最好的时代，也是最坏的时代，在这样不确定的时代，让咱们增强学习，拥抱云计算，拥抱云原生，用这样弱小的武器来武装自
己，一直开辟新的国土。
参考资料
https://landscape.cncf.io
https://github.com/cncf/toc/blob/master/DEFINITION.md
https://jimmysong.io/kubernetes-handbook/cloud-native/cloud-n…
https://www.kubernetes.org.cn/2250.html
https://www.infoq.cn/article/fA42rfjV*dYGAvRANFqE
https://www.infoq.cn/article/5HN5rqFE0K026pFXu8hX
https://juejin.im/post/5d42945ff265da03a715b2f0
https://www.infoq.cn/article/kJQXGx4Qs7m6qqBI1r9u
https://tanzu.vmware.com/cn/cloud-native
https://www.infoq.cn/article/xyxNdh6OiooK75vo4ZiE
本文由 mdnice 多平台公布