作者：张磊

云原生是什么？

提起云原生，可能很多人都听过这个概念，甚至有很多人是这个领域的从业者，但是大家依然会有一个问题，那就是什么是云原生，或者说云原生的定义是什么？

实际上我们在接触到了很多的云原生开源技术也好，云原生产品也好，都会逐渐发现这么一个现象，就是说云原生它本质上其实并不是一个非常确切的事实或者物体。

所以在这里强调一下，云原生其实没有什么定义，它是一个不断演进的过程。而云原生更本质的内容，或者说云原生的内涵，我们其实可以认为它是一套愿景，那么这个愿景的内容是什么呢？

云原生认为，在未来云的时代，咱们的软件或者说应用是天然生于云上，长于云上。而正是因为这样的现象或事实，云计算就能够最大程度地去帮助这些软件降本提效，释放软件本身最大的业务价值，所以这个才是云原生真正想要做的一件事情。它不是某项具体的技术，也不是某一个方法，更不是某一个具体的科研项目。

不断演进的云原生

我们可以通过下面这张图来更好地阐明云原生整体的玩法，或者说整体的形态到底是怎么演进发展。

首先，前面讲到云原生非常强调利用云的特性，所以它的核心方法论和核心概念都是围绕着如何让软件和应用能够利用云的特性，那么云的特性是什么呢？云能够无限弹性，云的资源是可以快速交付，云的使用方法是可以按量付费，这些都是云常本质的特性。

所以说，围绕这样的云特性，云原生才有了一套最基础的方法论和概念。比如，大家可能听说过想不可变的基础设施，就是说我们的应用部署在云上，它可以假设应用载体是一个不可变的，这样可以随时把它删掉、替换掉，所以更新应用会非常容易。升级应用可以直接采用删掉旧的，上线新的方式来做，而不需要动态变更应用里面的某项配置，甚至动态更改代码实现。所以不可变基础设施，就是一套非常典型的利用云的快速资源交付能力的方法论。

再比如说，云原生强调要高度的自动化，要能够高度自运维，甚至自愈，这同时也是希望我们的软件本身能够更好地利用云的特性。

因为云的能力是非常强大的，能够提供各种各样的运维能力，所以我希望我的应用、软件本身，它可能从开发的时候，考虑到云能够提供很多能力到应用层，而不是说先开发完应用，再去思考怎么借助云去帮我们运维，因为这样是构建不出一个自运维、自愈的软件。

再比如说，云经常强调这个应用用什么语言、框架都是无所谓的，这也是一个很明显的特点，因为云本身是一个基础设施能力，就应该不会去跟某种语言或者框架锁定。同样，也是希望世界上所有的软件都能够利用到云的能力，而不是云只能服务于某种语言。

这些都是基于云，想要更好地利用云的背景下，云原生所提出的一些非常重要的概念。而这些概念本身在我们的技术演进当中，就会被映射成为一系列的系统，或者说架构思想。比如刚刚提到不可变基础设施，一个应用可以随时把旧的实例删掉，换成新的实例。想要实现这样的一套方法，就要靠容器技术。容器技术本质上给我们一个东西叫做容器镜像，一个容器镜像自包含一个应用的运行环境，包括应用本身，所以我们就随时可以把镜像旧的版本替掉，上线一个新的版本，这就是容器是不可变基础设施的一套非常良好的实现。

这意味着未来是不是有某一种技术，能够更好地实现不可变基础设施，这是很有可能的，那么这项技术是不是云原生呢？当然。

所以未来可能有一个新的技术，能够实现不可变基础设施，或者更好地实现不可变基础设施，这样的技术也一定是云原生的核心范畴。

与之类似的，云原生里面强调的Sidecar架构，就是把中间件能力通过Sidecar容器的方式对接到业务容器里，而不是在业务本身上做定制，去集成中间件解决问题。这其实就是希望能够实践我们强调的无关语言、框架的方法论，提出了一个架构，而这个架构的特点就是中间件能力不再需要以语言或者框架的方式，嵌入到业务代码中，所以说Sidecar加上容器能够实现这样一套方法，这个就是云原生方法论背后所不断推演出来的一系列技术和架构。

而这些技术架构最终在云原生生态里面，往往是以开源的技术项目提供给大家使用，比如刚刚提到容器，它就有Docker等方面的项目。提到了Sidecar，提到了自运维的这套思想，它会通过Kubernetes实现。再比如最近比较火的Service Mesh，它本质上是在帮我们做中间件的能力，只不过是通过Sidecar的方式去做。再比如说，我们未来或者说现在就已经比较活的eBPF、WASM等，其实都是在实践云原生这套体系背后的某项思想和某种架构，以开源的方式满足我们使用的场景。

正是因为有了这一系列的开源项目，我们才做到一个用户拿到这样的科研项目，拿到这样的技术，能够真正实践云原生理念，从而达到前面讲到的云带来的这两种本质效果。

第一个是提升效率，比如研发效率，交付效率，运维效率。比如应用本身，它通过容器实现了不可变基础设施的理念，那么它的交付就可以非常简单，我们只需要做交付镜像，它就可以运行在每一个地方。

再比如说我们的运维，软件本身通过Kubernetes已经实现了自运维、自动化，那么它的运维难度和成本一定会降低。所以我们一定能够借助云的能力提效。

第二个是降低成本，这里包括了资源成本和人力成本，这个也很容易理解。比如说通过Kubernetes或者容器这样的项目，我们的应用可以更好、更多地集成云服务，通过云服务来减少运维成本，减少人力投入，这都是很明显的成本降低。

再比如说，通过应用的云原生化，实现了应用上云，之后通过云的无限资源池Serverless架构，很快速地资源交付和和更新模式，让整个应用的资源成本也变得很低。同样，也是通过云原生技术让我们应用能够更好地使用到云本质能力非常好的体现和实践。

所以总体而言，我们会发现这一套云原生的方法，它其实是一个很完善的自闭环，不断地去看，去探索如何利用云的特性帮我们提效降本，然后把这一系列的方法或者思想总结和沉淀为云原生的概念和方法论。

通过一系列相应的架构和对应的开源项目把它实现，然后再让用户能够去使用这些技术，从而达到释放云计算红利的本质目的。

所以说云原生没有一个确切的定义，它实际上是一套不断自我演进的理论体系加上最佳实践的组合。

今天的云原生

而今天的云原生大家可能都有些了解，就是围绕着容器、Kubernetes去构建的，因为这样的项目在直接帮助我们实践很多云原生背后的本质思想，包括不可变基础设施、自动化等。

所以说在今天，Kubernetes项目可以被认为是一个云时代通用的控制平面，也有人把它叫做操作系统，也就是说用户所有的操作都可以借助Kubernetes在云上统一完成。

这里面我们会发现Kubernetes这个项目的角色可能会越来越像一个安卓。举一个例子，比如今天的Kubernetes无处不在，每个地方、每个云上都有Kubernetes，部署在用户端，部署在边缘环境，都是非常正常的。

Kubernetes无处不在，就跟安卓一样，车上有，电视里有，甚至空调里都可能存在，更重要的是用户使用Kubernetes的本质目的是什么？是交付和管理软件。

比如说我们用Kubernetes，一定是在上面部署了某一个东西，比如部署了 AI的服务，或者部署一个淘宝，所以用户的本质目的是使用这套东西来管理软件，而这套东西Kubernetes本身它对上暴露的是一系列格式化的抽象，比如Deployment，Service，Ingress，让我们能够去管理和交付应用。而对下它启动了一套标准化的接口，比如通过CNI就可以对接阿里云的网络，对接自研网络插件，所以它本质上是中间层控制平面，接入了大量的基础设施，暴露成为了应用所需要的一些能力，让我们能够用这些能力去管理应用。

而这样的一个趋势往后面不断演进的话，我们就会发现这跟安卓系统特别像，比如安卓系统安装在手机上，安卓本身其实是免费的，但是应用市场的应用是要付钱的，安卓的价值是在说把手机抽象包装封装成一系列应用可以使用的API，所以这就是安卓的定位，或者它的价值和今天的Kubernetes是完全一样的。

所以，我们会看到未来Kubernetes不仅会出现在各种各样的地方，更重要的是它会为应用软件的研发、运维、交付的全生命周期提供一系列完整的能力，让用户能够使用它。

与此同时，为了能够更好地把软件交付出去，未来我们会发现有很多这样的项目在K8s上专门帮助我们解决软件交付的问题。

与此同时，以前传统的PaaS会不复存在，因为它的能力已经全部被Kubernetes接管，而未来会出现更多的开放、可扩展的PaaS，它们的作用是让我们能够更好、更简单地交付和管理软件，类似于安卓的豌豆荚，我们可以用豌豆荚便捷管理这些软件。对于这样趋势，我们把它叫做Kubernetes的安卓化。

而另外一个趋势就是说，在如今的云原生生态里面，我们的应用也好，能力也好，它都会往一个能够自动化的方向演进，我们把它叫做Operator 化。

Operator是Kubernetes里的一个核心思想，它指的是任何一个应用和所需要的能力都可以定义成为一个Kubernetes API对象，通过Controller机制让我们去使用云的能力，接入到各种各样的基础设施里。

Operator 化带来的一个直接结果就是我们的应用本身是高度自动化，包括自愈、健壮、可靠、运行的确定性，如今这些事情都是交给Kubernetes解决，用户或应用的Owner不需要再关心这些问题。

这也是我们今天在K8s安卓化的背景下看到另外一个趋势，就是应用本身和应用所需要的能力，它不断地Operator化,不断地往自动化方向演进。这也非常符合云原生的理念，因为应用自动化和自愈能力越强，就越能够跟云对接，人工介入的成本会更低，时间也会更少，更多的是把自动化能力跟云对接好，让云去帮助我们解决所有问题。

我们看到的另外一个趋势是应用本身所需要的中间件能力正在下沉，意思是从以前的中心化的中间件，在过去几年已经演进到了微服务架构。

微服务架构本质上是把中心化中间件这一套东西拆开，以SDK等方式放在业务代码里，我们需要把它引入进来使用，一般会提供一个比较重的客户端或者一个库让我们去使用，这是微服务时代的中间件的一个典型使用方式。

但是在如今云原生越来越普及的情况下，由于有像Sidecar这样的机制存在，如今中间件大量通过Sidecar的方式去被使用，所以我们业务本身不需要再去引入一个库或者特定的框架来做很多事情，我们甚至都不需要感知。

比如说，我们今天要去做流量的切分，不需要在应用里面引入一个库，而是完全交给基础设施去做。

那么应用怎么去跟云交互，就是通过Sidecar这么一个容器，让这个容器去代理应用本身所需要的进出流量，所以云就可以非常容易地通过这样一个代理调节流量去做流量切分，这就是一个非常简单的Service Mesh原理。

我们能看到如今中间件能力通过这样的方式在不断下沉，它会带来一个非常明显的趋势就是中间件不再与业务相关，不再与程序编写语言相关了，也不需要对框架有什么依赖，它的实现跟K8s、Kubernetes、容器化这套体系会非常紧密地结合。另外，对Sidecar的依赖也会更多，所以对Sidecar管理能力的要求也会逐步提高，可以把它总结为应用中间件能力的进一步下沉。

• 层出不穷的云原生服务
  

除此之外，伴随着云原生整套体系的不断发展，可以看到云服务也在大量、频繁地向云原生生态靠近，甚至带来一些革命性的影响。

比如阿里云的Polar DB，我们把它叫做云原生的数据库，它实际上就是基于云原生的一些核心的思想理念，比如无限弹性，高度可扩展等，提出了一个全新的数据库架构，使得数据库本身能够非常容易地扩展，应付极高、极为苛刻的流量和处理海量数据的需求，更满足现代互联网应用数据库使用诉求。

再比如阿里云的基础设施，它是基于“裸金属+容器”解决的，这也相当符合云原生的思想。因为这样的基础设施能够给我们带来极致的资源使用效率，减少了很多性能损耗，让容器便捷弹性地运维部署和管理。并且通过安全容器，通过更强的安全边界来保证容器之间的隔离性。

神龙架构能够为容器带来物理级别极致的网络存储和计算性能，这是非常重要的，也是应用通过云原生的理念使用云计算服务的一个典型例子。

再比如说像AWS厂商已经发布了云原生芯片，它让芯片本身能够更容易、更直接地适配容器化应用的使用方式，因为一个容器可能只有一个非常独立或非常模块化的一个进程在跑，就可以用芯片、核心去适配这样的业务，把基础设施的能力发挥得更强，把云的能力发挥到极致，这也是一个非常典型的例子。同时，能够保证这样的核心之间干扰非常少，更适应容器化、微服务应用的使用方式。

再比如说，AWS推出了Proton，它是一个云原生应用部署引擎，它可以用完全一致的方式去部署任何云服务或容器服务，这都能够帮助我们利用云的能力去提升应用管理、交付、运维效率的一个典型产品。

所以我们看这些产品或者开源项目，我们思考这个云产品是不是云原生的技术，其实非常简单，我们去判断一下它能不能帮助我们的应用最大程度地利用云计算降本提效，能否通过这样的方式释放最大的业务价值，这是判断一项技术或者产品的定位是不是云原生的一个核心标准，而不是看这个产品是不是容器。

回到阿里巴巴本身的例子，可以看到如今阿里巴巴的基础设施已经基于像Kubernetes容器这样的整套技术，完成了云原生化，而真正回过头来看这样一件事情，我们会发现其实云原生本身给阿里巴巴带来了非常重要的一些变革。

• 阿里巴巴云原生化
  

这里稍微总结一下，第一个是我们对业务是研发，通过云原生的思想很好地做到了关注点，分离研发更专注于业务。通过云原生的标准交付方式，我们还提出了云原生标准交付规范，标准化、模块化地进行可持续交付，兼顾用户体验和灵活度，从而大幅提升业务的研发效能，完全专注于自己的业务，不需要再去接触到复杂的基础设施，这是云原生给业务研发带来的最大价值。

再比如说，对大量的业务运维SRE来说，云原生体系所提供的敏捷运维、高效运营的理念，以及它的技术实现，包括前面讲的轻量级容器，不可变基础设施，再包括这种高度自动化的应用本身和运维方式，都能够让我们今天的软件运维极其简单、高效。

尤其相比于之前的传统方式，基于容器的声明式自动化方式，能够极高地提高运维自动化程度，大量减少人工介入，提升操作的并发度，真正意义上实现所谓的把“把复杂留给系统，把简单留给用户”，这是云原生的体系给阿里的基础设施、运维、稳定性带来的一个非常重要的变革。

如今容器化之后，现在的项目、淘宝应用等，做水平扩容、升级都是非常的快捷高效，而不是升级一下淘宝就会导致手机应用就挂了，这在云原生时代是不会发生的。

另外一个例子是对基础设施来说，阿里如今完全使用神龙裸金属的实例，加上安全容器，它们能够去帮助我们极大提升数据中心使用资源的效率，尤其是它能够支持我们极高密度地部署安全容器，利用云的规模效应降低资源碎片，我们可以做混部，可以根据工作负载的不同形态放心地填资源碎片，因为我们有神龙裸金属，能够确保这样做依然有极高的业务运行效率，同时互相之间不会有任何干扰。这都是云原生的环境下这套基础设施所带来的重要变革，随着云原生技术的引入和发展，也给阿里巴巴带来了非常好的变化。

比如我们对内积极引入像Kubernetes、Service Mesh这样的开源技术，另一方面让阿里巴巴的技术栈非常地标准化开放，能够跟生态无缝集成，也能够降低研发成本，让整个体系的可靠性和研发效率都有很好的提升。

而另一方面我们也知道，随着自身基础设施的标准化，阿里巴巴的技术正在大量、迅速地进入开源社区当中。目前阿里巴巴是CNCF里面开源项目最多的公司，远远领先于任何厂商和其他组织。

这里一个关键原因就在于，如今阿里巴巴的技术跟生态无缝对接，所以我们才能积极参与更广泛的开源生态，把阿里的开源技术传输出去，甚至引领和影响整个业界生态的发展过程，这是阿里巴巴云原生化之后的变化。

总结 – 我们视角的云原生

回顾一下上文的云原生理念，我们可以发现它实际上是一套架构到技术再到产品不断引进的一个过程。从架构上来讲，云原生认为软件天然生于云上，能够最大化地利用云的能力。

另外一方面，区别于传统的搬站模式，简单地把应用搬上云，云原生能够让开发者享受到云的红利，去引领软件和应用本身去不断现代化。

而围绕这种架构和理念，我们有一系列的技术，有开源的，有自研的，但是它背后的逻辑和思想是高度一致的。

我们围绕着基础设施、应用架构、开发、运维、交付等场景，通过云原生技术让我们的系统更加可靠、弹性，有更好的容错性，并且组件之间松耦合、易管理可观测，充分发挥云计算的优势。前面我们提到云原生能够释放云的最大潜力，其实它的背后往往离不开云原生这套本质的理念和技术的支持。

所以以这些理念和架构为代表，如容器、不可变基础设施、声明式API、Service Mesh等，它们其实是我们落地云原生的高效手段。

而围绕这些手段本身，我们才有了各种各样云原生理念加持的产品，包括云原生数据库，云原生服务，中间件，函数计算，容器等一系列的开放标准，能够弹性，利用云的价值，通过云本身更好地服务应用、研发、运维和应用交付人员的一系列产品。它们能够非常明显地区别于传统完全基于资源交付模式的云计算服务提供的形态。

所以，我们会看到未来的云会更多地向Serverless化、SARS化、服务化的方式演进，而较少地专注在基础设施层，因为用户真正的关注点在应用能否发挥最大的业务价值。

未来 - “云原生”的下一步关注点？

前面我们讲到的整个演进趋势，它其实都伴随着一个非常重要的点，就是云的能力在不断地丰富，这非常重要。

过去整个软件架构本身，需要大量的传统中间件，甚至一些微服务框架或者PaaS，帮助我们更好地管理软件，它背后一个非常重要的原因在于云或者基础设施能力不够强。比如我们今天就想要蓝绿发布这么一个简单的能力，云在长期的一段时间内是不具备这个能力的，所以必须通过某种中间件或者某种框架来帮我们解决。

但如今不是这样，如今我们的云几乎能满足想象到的任何一种应用所需要的管理能力，甚至可以说云的能力已经快要超出了如今软件架构的大部分需求。

所以在这种情况下，必然不再需要一个额外的层，无论是传统中间件还是传统的微服务框架或者PaaS，来弥补软件的诉求跟基础设施之间的鸿沟，如今这个鸿沟越来越窄，这也是为什么会出现各种各样的云原生技术。

所以说，任何一种云原生技术不再是某种能力的弥补，更多的是如何把云的能力以某种方式更简单、更高效地透出给应用去使用。无论是容器、K8s还是Service Mesh，它们都是在不同的环节帮助应用更好地使用云服务，或者说使用云背后的基础设施能力。

比如K8s，它可以让我们的应用无感、极简地接入到云的存储和网络当中使用云的计算能力，Service  Mesh通过Sidecar这样完全无侵入的方式，让我们能够使用云的流量控制能力来做微服务治理。

Dapr和OM通过与基础设施完全无关的方式，让我们能够去编写与基础设施无关的代码，以与基础设施无关的方式交付应用。

所以未来整个云计算的发展，包括云原生背后的关注点一定也是这样，不断持续充分地释放云计算的基础设施能力到软件的研发交付乃至整个生命周期当中，这是非常重要的一点，因为未来云的能力一定会越来越强。伴随着这样的趋势，我们才会看到云原生逐步引领整个云计算生态往这个方向前进。