云原生技术里有很多技术、概念和术语，不了解的人，往往弄不清楚而一头雾水，这些概念都是啥，之间是什么关系？

本文要说的就是这些。

本文更多是科普和扫盲，无意面面俱到，也无意深入细节。 本文适合一定IT基础的人阅读，完全的小白和门外汉，可能是看不懂的。

完全看不懂的云原生

云计算？云原生？

云原生就是“云+原生”（cloud + native）。一般而言，“云”更关注IaaS，也就是基础设施层面（如计算、存储、网络）；“原生”更关注PaaS层面（如容器、微服务）。之所以叫“原生”，是因为它一生下来是给云用的，可谓是生在云里，长在云里。

一位学者可能会说：“云计算是一种灵活提供基础IT资源的架构，云原生是一种在云计算上创建和运行应用程序的方法。”这话没有什么错，但也没有什么用，因为太抽象了。

在词汇使用上，据我观察，“云计算”和“云原生”基本上已经混为一谈了，我从来没有见过一个人说“云原生”的时候，另一个人站出来说“不对，这个是云计算”，反之亦然。

唯一的区别是：人们以前爱说“云计算”，现在爱说“云原生”。

毕竟，新词总是高大上一点嘛。

所以，这块不要太纠结。

云原生带来什么好处

其实这等同一个问题：为什么要上云。

好处有很多，我本人觉得最重要的有3点：

7个字：隔离、弹性、自动化。

1、隔离：在传统架构中，一个网络配置错误可能导致整个DC故障，一个模块出问题可能会导致整个应用系统故障。而且往往很难定位和隔离。云原生通过VPC、容器、微服务这些能力，把网络、操作系统、应用系统以虚拟或拆分的方式隔离开来，做到互不影响。一个部分的运行、变更或故障，不会影响其他部分，这就安全多了。

2、弹性：应用系统在服务能力紧张时，需要扩容，比如增加机器的内存和CPU，或是部署新的实例并做负载均衡，在传统环境下，这需要一定的工作量，尤其是需要运维人员的安装和配置。云原生在一开始设计时，就考虑了如何更方便、更快捷、更安全地扩容，比如虚机、容器的快速生成，自动地扩容和负载均衡。这样，以前是几个小时的事，现在稍稍动动手指就可以了，几分钟或者更少的时间搞定。

3、自动化：不管是部署还是变更、维护，如果一项工作涉及多个步骤，需要多项配置，甚至需要多个团队配合，那就会很繁琐，很复杂，对使用者的要求就会很高，出错的概率就会变大。如果只需一条指令、一个按键就能完成相关工作，那就是高度的自动化。云原生的很多设计，就是以尽可能少的指令，完成尽可能复杂的操作。

自动化通过什么方式呈现给用户？一是图形化界面，让各类用户（平台租户、运营人员、运维人员、开发人员）都可以简单上手操作，比如租户（就是客户）点点鼠标就能申请一台虚机或是一台网关；二是命令行界面，让喜欢命令行的人可以直接或者写脚本调用；三是API，让程序员可以写程序任意编排操作。这样，各种不同技能基础的人，都能够尽自己能力实现尽可能的自动化。

云原生的本质，就是IT全过程的软件化，也即“软件定义everything”在IT行业得以实现，而且是规模化和自动化的实现。原先冗长、复杂、颇费时费力的技术工作和体力活，现在可以轻轻松松搞定。

说这么多，现在略略见识一下：

kubectl create deployment nginx --image=nginx --replicas=2
kubectl set image deployment/nginx nginx=nginx:latest

以上是两条kubernetes命令，其中，第一条命令部署两个nginx容器，第二条命令则让它们更新成一个最新的镜像版本。

看，这多么简单。

云原生的基础知识

考虑扫盲性质，现在说一点最基础的东西。

1、虚机：虚机是在物理服务器之上虚拟出来的具有完整功能的计算机。人们可以通过云平台创建虚机并安装操作系统，对其扩容，并在不停机的情况下将其迁移到另一台物理机上。

2、裸金属：裸金属即云纳管的物理机。裸金属不参与虚拟化，不提供虚机，但一样可以被云管理，可以被云自动化地分配、回收和管理。

3、存储：云可以提供块存储（如IPSAN）、文件存储（如NAS）、对象存储（OBS）。并且都提供界面、命令行和API给用户，让用户可以非常便利的使用和管理存储。通过对存储的资源池化和虚拟化，抹平了不同设备的差异，用户不再需要学习具体的存储设备知识、指令和配置方法。

比如在openstack中，用如下命令创建一个叫my_volume的卷，大小为10G，然后通过命令将这个创建好的卷连接到虚拟服务器my_server上。

openstack volume create --size 10 my_volume
openstack server add volume myserver my_volume

看，这多么简单！作为一个完全不懂存储的人，我也可以轻而易举做到。

可以说，云的用户，就是在抽象层或者说逻辑层工作，底层细节完全可以不了解。

4、网络：云提供虚拟的网络，用户并不用实际购买和独占网络设备，就可以在云里构建出一个个互相隔离的虚拟网络分区，组织他的多台虚机。这通过创建虚拟私有网络（VPC）、虚拟子网、虚拟路由器、虚拟NAT网关等来实现。用户不再需要和底层的网络设备打交道，用户只需要在云平台里“创建”和“配置”即可。

5、容器：容器可视为轻量级的虚拟机，它把应用“集装箱”化，应用程序和自己需要的依赖（Depends）打包在一起，自成一体。容器可以在各种操作系统中部署，不受具体宿主机影响。比起虚机，它更轻量，更方便、可以秒级启动。

以上这些是最基本的概念，相对靠基础设施一些，再往上走，就会遇到更“云原生”一些的概念：微服务、服务网格、函数计算、DevOps等，这些更靠近开发一些。

下面，我们继续，部分概念会再次说起。

云原生中最重要的概念

搞明白下面这些概念及其关系，你就心里有底了。

1、虚机

虚机（VM，Virtual Machine，或称虚拟机 ）是在一台物理机（又称宿主机）上虚拟出来的计算机，目的是提高计算机硬件资源的利用率。这通过物理机上安装VMM（Virtual Machine Manager，虚拟机管理器）来实现。VMM给虚机分配调度相应的资源（内存、CPU、网络、磁盘等），加载虚机的操作系统，并调度给虚机最终所需的物理资源。大体而言，一台物理机可以虚拟出10台虚拟机。

虚机、VMM、物理机关系示意图

和容器相比，虚机还是有些笨重的，由于虚机镜像包含了整个操作系统，所以通常有几个GB大小。虚机启动时间通常是1分钟或几分钟。

虚机镜像是包含一台计算机的操作系统、安装的软件、数据和配置等信息的文件。镜像文件通常被用来作为虚拟机的模板，以便在需要时快速地创建多台相同内容的虚拟机。

正是因为虚机还不够敏捷便利，速度也不够快，所以才产生了容器技术。

2、容器

在一个操作系统中，通过进程隔离、内存隔离、文件隔离、用户隔离、网络隔离等技术，形成一个个互相隔离的运行空间，每个空间里运行着应用程序和其所依赖的程序及库，这就是容器。

这样，多个容器共享同一个操作系统，但又互相隔离。容器通常不大，可以秒级启动，非常迅捷。

容器实现了完全的可移植性，在支持容器的任何操作系统或环境上都可以兼容运行。因为容器里的软件和所需要的库依赖是封装好的，和所在宿主机的库是互相隔离的，不需要像以前那样，要在宿主机上做各种安装和适配。

在Linux操作系统中，早有通过命名空间（namespace）和控制组（control group）实现应用程序隔离的方法，使得一个或多个进程的CPU，内存，磁盘I / O和网络使用可以隔离开来互不影响，此即Linux容器（LXC）技术。但对用户而言，LXC并不易用。Docker把这些较为复杂的容器功能封装起来，形成对用户友好的操作命令或图形界面，才使得容器流行起来。

3、容器编排

在大型系统中，需要大量的容器同时运行，直接管理一个个容器有点麻烦，如果能以更优雅更自动化的方法就更好了，这就出现了容器编排工具，有好几种容器编排工具，但是毫无疑问，Kubernetes（简称k8s）这些年最流行的容器编排工具。

所谓编排（orchestration），就是统揽全局式的规划、组织、部署、管理等，把众多复杂的元素管理地井然有序，达到管理者所指定和预期的目标。

k8s提供了许多强大的功能，例如部署容器、自动扩容、负载均衡、应用更新、故障恢复和容器监控等。总之，它能让用户更轻松、更便利地部署、调度和监控容器。用户可以通过描述性的文件，描述k8s应部署容器的规格、个数和关系，指定服务端口，将多个容器组织成一个应用，并能根据容器的负载情况自动地扩展容器的数量。

比如下面两句话，就能将nginx容器扩容到5个。

kubectl scale deployment web-server --replicas=5
kubectl rollout restart deployment/web-server

4、VPC

VPC（Virtual Private Cloud，虚拟私有云）是在云中构建出来的一个独立的、隔离的虚拟网络环境，一朵云中，可以有多个VPC。

虽然名字里带个“云”字，但人们更喜欢称之为“虚拟私有网”，因为它更多的特性是网，然后才是其上的虚机、容器等。

用户可以在VPC中自主规划 IP 地址，创建子网，并使用虚拟交换机vSwitch、虚拟路由器vRouter、虚拟负载均衡vLB等网络组件，还能通过网络ACL、安全组、虚拟防火墙vFW等方式，实现网络内虚机的隔离保护。

比起虚机和容器，虚拟网络会更让人难以理解一些，如果想快速扫盲，见我下一篇文章《让人懵懂的云网络，里面原来是这些》。

5、微服务（Microservices）

微服务是一种架构，在这种架构中，把原先应用系统中的各个功能模块独立出来，形成一个个服务，跑在不同的虚机或容器中，然后用标准化的方法互相调用。这些服务原先是耦合在一台机器里的，现在都独立出来了，人们也就能独立地开发、部署和管理它们了。

微服务架构的目标是让每个服务都尽可能简单、单一，每个服务只执行特定的业务逻辑，并且具备良好的横向扩展能力。各服务之间通过简单、轻量的通信协议（如REST、gRPC等）进行通信。

微服务的好处是，一、便于隔离，一个服务坏了也不会影响其他服务，不像以前都在一个机器里，一坏就感染一片；二、便于扩容，一个服务如果形成性能瓶颈，就对那个服务扩容，多弄几个容器运行它。不像以前那样，要对整个应用系统扩容。三、便于维护，每个服务都可以独立地开发、部署、运维，一个服务只由一个小团队专门负责。在另一个层面上讲，小团队的管理，也显然要比大团队容易。

在微服务架构中，常遇到两个概念：API网关和服务网格。

API网关提供集中式的服务请求处理，集成了反向代理、负载均衡、SSL卸载、身份认证、限流熔断、超时重试、流量监控、日志统计等功能，适合处理来自外部的流量（南北向）。在客户端和后台服务之间可以存在一个或多个功能不同的API网关。最受欢迎的网关代理是Nginx、HAProxy和Envoy。

对于系统内部复杂的服务间调用（东西向），为了避免瓶颈，还是以分布式的方法通信比较好，这就是近年来比较火的服务网格。

6、服务网格（Service Mesh）

由于服务总是要处理请求，遇到网络不好的时候，就需要重连或做超时处理，这样，每个服务都需要实现请求重试、超时处理、断路器等机制。如果每个服务都写这样的机制，就有点不经济。如果服务还是用不同语言实现的，这些部分也得用不同语言实现，就很不经济了。

服务网格的想法是将这种通用的功能从每个服务中抽出来，最早的做法是给服务提供SDK(便于服务集成通用功能)，后来逐渐演变为由独立的代理来完成通用功能：在每个服务旁边运行一个代理（sidecar），sidecar作为一个单独的容器与应用容器放在k8s的同一个Pod中（Pod是k8s调度的最小单元，里面可以有1个或多个容器）运行，它们共享相同的网络。sidecar处理流入或流出的请求和响应流量，实现路由、安全和监控等功能。

比如：Istio服务网格在服务的每个应用容器旁运行Envoy代理作为sidecar，所有sidecar都受微服务控制平面管理。

由Sidecar组成的服务网格

注：Sidecar是一种形象的比喻，原意是摩托车旁的边车。

真正的sidecar

这种分离让开发人员能够很集中精力在业务上，而真正不再考虑非业务功能，所有服务所共需的通用能力，都放在sidecar里来做。

就好像开车的就专心开车，通信和作战交给边车上的队友。

7、无服务器（serverless）

“无服务器”并非真的没有服务器，而是说用户（比如开发人员）完全不用关心服务器的事，不用申请服务器、存储和网络。用户只关心自己的程序，所有和资源相关的琐事都由云提供商处理。代码执行时，云提供商会启动资源，代码执行结束时，释放资源。用户只为使用时间付费，而不为闲置容量付费。

这提法更像是一个理念，更像是一个产品营销话术，而不像一项新技术，因为“无服务器”的背后无非还是虚机、容器、微服务这些，只是用户可以不管这些，这些都由云服务商提供，用户把精力放在自己的程序上就好。

函数即服务（Function as a Service，FaaS）是最常被提起的无服务器架构，虽然它只是serverless的一种。使用FaaS，用户将函数放到云上（将代码作为zip文件或容器镜像上传），在需要的时候，通过HTTP调用即可，用户只需为函数的执行时间付费，函数所在容器，以及所需的RunTime，都由云服务商调度和管理。常见的FaaS产品AWS Lambada、Azure Functions和谷歌的Cloud Functions。

显然，这种一会运行一会关闭的函数，只适合那种一过性的运算，那种很简单的、无状态的运算，比如简单计算、更新记录、发送消息、写入数据这种。

除了FaaS，还有别的serverless，比如serverless DB，它不需要用户手动维护和配置服务器资源，而是自动扩展和伸缩。

总之，只要是用户原先要考虑服务器而现在不用考虑服务器的服务，都是Serverless。

8、基础设施即代码（IaC）

程序员大多是不太爱碰硬件的，他们喜欢沉溺在软件的思维里。当他们不得不接触和管理硬件的时候（比如被轮岗或是种种原因），他们就决心用软件的方式来管理这些硬件。

基础设施即代码（Infrastructure as Code，IaC）用编程语言描述他们要运维和管理的基础设施（服务器、网络设备、存储设备等硬件），这样，部署和管理笨重的硬件设备，无非也就是在电脑面前敲几句代码而已，不再需要像以前那样吭哧吭哧地猛干了。

这是硬件维护人员多年以来梦寐以求的自动化。现在，人们只是写一个脚本，用脚本去部署服务器，并配置各种网络、存储、负载均衡器等任何基础设施服务。然后，只是执行这个脚本，就可以在完全不同的AZ（AZ即可用区，后面会介绍）中部署一套高度一致的基础设施。以前，这样的任务需要数人、数周才能完成。现在，几个小时就可以完成。

基础设施即代码，换句话说，即，软件定义基础设施。

9、DevOps

DevOps（它是“Development”和“Operations”的缩写），就是从开发到运维，整个过程自动化。自动化地编译、测试、构建容器、上传容器、部署、发布、监控、告警等，如果发现了Bug或问题，团队能够迅速迭代这一过程，修改代码，然后又是自动化的编译、测试、部署、发布等，一天可以来上这么10次！

在2009年O’Reilly Velocity大会上两个Flickr员工做了题为《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》的演讲¹，引起了轰动，随后得以蓬勃发展。

当然，这需要多种工具和多个脚本的有机衔接。

以前，这一过程冗长，开发团队和运维团队的配合并不容易。因为他们有着不同的部门和领导，有着不同的文化，他们的目标和利益并不一致。从开发到上线，这个过程中，有着各种流程和审批，1天能有10次发布？开玩笑，10天能有1次就不错了。现在可好，全都自动化了，一个小团队，从开发到发布，全都干了，还很快，运维人员几乎都不用动手，或者几乎都不需要出现。

本质上，DevOps是搞开发的人终于帮助搞运维的人，把运维那摊子事给自动化了（搞运维的人，通常不太擅长写代码）。我想，这肯定是哪个公司，非要逼得开发人员去搞运维，所以他们没办法，只能自己拿起看家本事造福自己了。开发那一段的自动化，早在近二十年前，他们搞敏捷开发的时候就搞差不多了，他们早早就搞了CI（持续集成），然后又搞了CD（持续部署），这十年，他们通过前面说的容器、微服务、k8s等技术，再加上一些新方法、新工具，把运维这一段也搞定了，他们终于打通了任督二脉。

崇拜DevOps的人会说远远不止这些，是的，他们往DevOps里装了种种思想、理念和方法论，以至于人们似乎已经忘了它本来想致力于什么。我以前写过一篇文章讲如何从高层把握DevOps²的实质，有兴趣可以看看。

下面这张图有助于你从全貌上概览一下，这只是一种框架，引自³，篇幅有限，此处不细解释。

一种DevOps工作模型

滚动发布是一种发布软件更新的方法。软件新版本先在小范围内发布，没有什么问题的话，再慢慢扩展到更大的范围。这样，一开始如果有问题，受影响的也只是少数用户。类似概念和叫法有灰度发布、金丝雀发布。以前矿工下矿前，为防范探洞里有有毒气体，会先放一只金丝雀进去，看金丝雀能否活下来，金丝雀发布得名于此。

更深一步：云计算背后的东西

下面的内容有点偏底层技术了。

如果你不想了解更多，跳过这章就好。

1、云平台和云管平台

当“云管平台”（Cloud Management Platform）这个说法在n年前第一次介绍给我时，我当时还真有点懵。

我心想，云平台（Cloud Platform）不就是Openstack这些东西吗，怎么又冒出来一个“云管”平台？

后来才弄明白，原来还是有点不同的。

云平台更多是指云计算平台，偏技术层面，提供计算、存储、数据库、网络、安全等基础设施服务，供客户在云上部署和运行应用程序。比如OpenStack提供IaaS，Docker和Kubernetes提供PaaS等，这些都属于云平台。

云管平台从名称上就能看出来，侧重于管理，侧重于多云、混合云、异构云场景下的统一管理。它给用户提供统一的运营控制台和运维控制台。所谓运营控制台，就是为用户提供登录、资源开通、使用、配置等功能，并且达到“自服务”的水平；所谓运维控制台，就是让运维人员可以对物理资源状况进行监控和管理。

所谓“自服务”，是指客户可以通过平台界面或API，自行创建和管理虚拟机、存储空间、网络资源和其他云服务，而无需其他专业人员参与，自己点点鼠标，想要的东西就出现了，就能用了。

两者之间有一个明显的不同是：云管平台可以管理多云以及一朵云中的多个Region，而云平台通常只能管理本Region内的资源。

在我看来，云平台更偏技术一些，更靠近基础设施一些，云管平台则在云平台的基础上又做了一次封装，以更简便易用的方式将云服务提供给用户。

不过，正如“云计算”和“云原生”这两个词已经被人们混用，“云平台”和“云管平台”往往也被混用起来了，你听他说“云平台”，其实他很大概率是在说“云管平台”。

2、地域（Region）

Region即一朵云内某个物理区域中基础设施服务的集合。不同Region之间的物理资源（计算、存储、网络）是完全隔离不共享的。

一朵云里可以有多个Region，每个Region可位于不同的城市的DC（数据中心）中，也可以位于同一个城市的不同DC中。不同DC能否放在一个Region中，关键看时延，如果时延超过 2ms，就应该在不同的Region中，因为同一Region内对时延有较高要求。

不同Region之间的时延也应该在100ms之内⁴，因为云管平台对Region的命令下发和信息上报时延也有要求。

不同Region之间的通信使用“云连接”，通过“专线网关”实现，这个网关可以是软件的，也可以是硬件交换机（又称专线交换机），这块见我下篇关于云网络的文章。

每个Region中包含数个独立的，物理分隔开的AZ，每个AZ可以有独立的供电，制冷。

3、可用区（AZ）

可用区（Available Zone，AZ）可以简单理解（虽然并非总是如此）为机房及其内的计算、存储和网络资源。一个Region内有多个机房，每个机房就是一个AZ。不同AZ使用不同的电力和制冷，使用独立的计算、存储和网络资源（但网络是互通的）。这样，即便一个AZ不可用了，另一个还是可用的。AZ内通信时延要小于0.25ms。

AZ中的A就是可用（Available）的意思，一般而言，不同AZ使用独立的电力、制冷、机房模块等基础环境。应用系统如果要实现高可用，应该同时部署多份在不同的可用区内，这样，一个AZ坏了，还有另一个AZ可以提供服务。

裸金属和不同CPU架构的物理机，通常部署在不同的AZ；同一个AZ内，又可以根据不同性能属性划分不同的主机组（host aggregate），便于管理员进一步按组分发虚机⁵。不同主机组提供不同的主机资源，但存储和网络资源是共享的。

VPC的子网是可以跨AZ的。比如在同一个子网中，VM1在AZ1，VM2在AZ2，他们可以同时承担Web服务器功能，这样，即便整个AZ1不可用了，VM2仍然能够提供服务。

4、SDN

传统的网络设备是分布式和去中心化的，每台设备可以通过自主学习和人工配置，知道如何转发数据包，而不需要一个集中式的控制设备。SDN则像各个网络设备的软件大脑，让各网络设备不再用自主学习和人工配置，而是由大脑下达命令，告诉各设备应该怎么转发数据包。

SDN（Software Defined Network）就是软件定义网络，那个大脑被称为SDN控制器。

SDN为什么要把原先的分布式运行改为集中控制呢？因为如果每个网络设备都要人工配置和管理，就会太麻烦，容易出错，不易于统一集中管控。如果能力足够，那就不如一起管了算了。

在虚拟网络里，像虚拟交换机、虚拟路由器、虚拟网关等等，这些虚拟网络设备，都受SDN统一管理。

5、网络资源池

网络资源池由一组网络硬件设备（如交换机、路由器等）构成，为上层的虚拟网络、虚机、存储等提供底层的通信功能。

说起来有点复杂，大体而言，应用系统在虚拟网络（Overlay）上跑，虚拟网络基于隧道技术在物理网络（Underlay）上跑。

从技术上讲，Overlay的二层数据包封装在Underlay的三层报文中传输，到达目的地之后再解封装得到Overlay的二层报文。实际上，这是一种“L2 over L3”的隧道封装技术，目前主流的隧道封装协议为VxLAN。

如果Overlay的网络数据封装和路由都是软件实现的，那就是软件SDN（又称主机Overlay），如果是硬件网络设备做的，那就是硬件SDN（又称网络Overlay）。

一个Region需要一套网络资源池，提供该Region内共用（多AZ、多VPC共用）的底层数据包转发，该资源池是由跨机房模块（也即跨AZ）的多组Leaf+Spine模块组成，跨机房模块的网络交换通过一组Core节点(Super Spine)交换机实现。

在主机Overlay这种主流场景下，网络资源池中的网络设备并不关心上层是哪个VM要和哪个VM通信，它们只是忠实地转发数据包而已，它们不会去关心隧道里的虚拟网络通信。

通过隧道，在物理网络上构建虚拟网络

上图使用两台Super Spine，四台Spine，八台Leaf，并通过在不同机房部署，提供了一套网络资源池，供多个AZ共同使用。这样，虽然VPC子网和虚机可能在不同AZ和机房内，但通过VxLAN隧道，它们之间的通信就像在一个交换机下面的二层通信。

那么，云原生是什么

看到现在，你大概知道云原生是什么了吧。

整个IT被云化了，不管是搞开发的，还是搞运维的，都在使用云，依靠云，发展云。

IT的一切，都尽可能用软件定义，都尽可能虚拟化，一切都是为了简单、自动、弹性、安全。

所有使用云的人，都只是点点鼠标，就可以完成以前很复杂的事。

IT在给其他行业搞数字化转型的同时，给自己搞了个数字化转型。

本质上，IT人终于把自己给解放了。

他们感叹说，云里原来才是我们生活应有的样子。

文｜卫剑钒

参考链接：

1. 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr(https://www.bilibili.com/video/av929343748/)

2. 如何从高层把握住DevOps的实质


3. 云原生：运用容器、函数计算和数据构建下一代应用(https://e.jd.com/30613841.html)

4. 云Stack中Global、Region、AZ、资源池以及主机组 (https://bbs.huaweicloud.com/blogs/231197)

5. openstack中region、az、host aggregate、cell 概念 (http://t.zoukankan.com/xingyun-p-4703325.html)