云原生技术概谈

说起“云原生技术”，大家可能有点懵，只闻其声，不明其意。但是云原生背后典型的几个公司或者技术产品的名称可能大家经常听到：

比如容器技术的代表公司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-native-definition.html

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