云原生的定义

关于什么是云原生，不同的人定义不同，Pivotal公司的Matt Stine认为云原生是一个思想的集合，云原生既包含技术（微服务，敏捷基础设施），也包含管理（DevOps、持续交付、康威定律以及重组等），云原生也可以说是一系列云技术、企业管理方法的集合；CNCF基金会也在2018年6月11日给出了云原生定义1.0版本，即云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

实际上，云原生是一条最佳路径或者最佳实践，云原生的最大价值和愿景，就是认为未来的软件，会从诞生起就生长在云上，并且遵循一种新的软件开发、发布和运维模式，从而使得软件能够最大化地发挥云的能力，包括“自包含”，敏捷，可扩展，可复制。

云原生技术的核心底盘正是容器技术。

云原生技术发展简史

• 2000年的物理服务器

以Sun公司为代表的物理服务器产品，包括基于Intel Xeon、Itanium和AMD Opteron处理器的中高端服务器，以及刀片服务器（每个“刀片”基本上都是1个，最多2个处理器）。

这个时代采购物理服务器的厂商一般有以下痛点：成本高，性能溢出还需要支付托管费用、带宽费用等等；其次是运维难，远程运维几乎不可能，服务器故障基本要跑到机房操作；扩展难，CPU扩展就基本不可能，除非新购置机器。

• 2001年vmware虚拟化

虚拟机通过“伪造”一个硬件抽象接口，将一个操作系统以及操作系统层以上的层嫁接到硬件上，实现和真实物理机几乎一样的功能。比如我们在一台 Windows 系统的电脑上使用 Android 虚拟机，就能够用这台电脑打开 Android 系统上的应用。即使用逻辑来表示资源，从而摆脱物理限制的约束，提高物理资源的利用率。

优点便是可以极致利用服务器的硬件资源，并易于管理；缺点就是过于笨重，每台虚拟机要包含完整的操作系统，程序加载运行时间较专用服务器要慢，一台服务器上可能承载太多站点，从而导致负担过重；

• 2006年IaaS

IaaS（Infrastructure as a Service），即基础设施即服务，最有代表性的公司就是AWS。指把IT基础设施作为一种服务通过网络对外提供，并根据用户对资源的实际使用量或占用量进行计费的一种服务模式。

IaaS可以按公司需求（质量、数量、需求）提供资源，即定制化解决方案。IaaS也能有效地增强公司数据中心的服务：扩展容量、增加带宽、防火墙布置等，同样也会负责公司的服务器网络等问题。

• 2009年PaaS

假如我们现在需要一个业务，提供一个很简单的"hello world"服务，那么需要的资源有哪些呢，看下图：

之前，IaaS帮我们节省了红线所涉及的部分，包括IDC、网络、服务器、甚至包括部分操作系统，而PaaS帮我们节省了除了IaaS节省的部分外，还节省了服务软件和代码的部分，换句话说，PaaS提供了一个完整的业务开发、运行环境，我们无需关心怎么安装Apache、怎么配置缓存、怎么配置数据库读写分离，所有这些已经以服务的方式(注意：不是以机器的方式)提供好了，我们需要做的，只是把业务代码放上来就好了。

PaaS对比IaaS虚拟化的计费粒度更细，更贴近用户的实际需要，因为用户真正需要的并不是虚拟机，而是满足业务运行需求。总之，IaaS提供的还是虚拟机资源，而PaaS提供的是实际业务的开发、运行环境。但PAAS的缺点也很明显部署过程难免会碰到云端虚拟机和本地环境不一致的问题，“上云”体验很差，一旦用上了 PaaS，用户就必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在 PaaS 里运行起来。而这些修改和配置，并没有什么经验可以借鉴，基本上得靠不断试错，直到你摸清楚了本地应用和远端 PaaS 匹配的“脾气”才能够搞定。

• 2013年Docker降维打击

早年Docker公司还没有改名，叫dotCloud，也是PAAS热潮的一份子，也不过公司实在是太微不足道了，而它的主打产品由于跟主流的 Cloud Foundry 社区脱节，长期以来也无人问津，所以dotCloud决定开源自己的项目Docker。显然，这个决定在当时根本没人在乎。“容器”这个概念从来就不是什么新鲜的东西，也不是 Docker 公司发明的。Docker的隔离技术实际是调用操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在“沙盒”中启动这些应用进程。即使在当时最热门的 PaaS 项目 Cloud Foundry 中，容器也只是其最底层、最没人关注的那一部分。

Docker真正降维打击的方式是Docker 镜像，所谓 Docker 镜像，其实就是一个压缩包。但是这个压缩包里的内容，比 PaaS 的应用可执行文件 + 启停脚本的组合就要丰富多了。实际上，大多数 Docker 镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完全一样的。即本地环境和云端环境的高度一致！

dotCloud 公司则在 2013 年底大胆改名为 Docker 公司。

• 2014 年CaaS

谈到 Docker 项目的定位问题，就不得不说说 Docker 公司的老朋友和老对手CoreOS了，CoreOS 是一个基础设施领域创业公司。 它的核心产品是一个定制化的操作系统，用户可以按照分布式集群的方式，管理所有安装了这个操作系统的节点。从而用户在集群里部署和管理应用就像使用单机一样方便了。

Docker 项目发布后，CoreOS 公司很快就认识到可以把“容器”的概念无缝集成到自己的这套方案中，从而为用户提供更高层次的 PaaS 能力。CoreOS 在短时间内成为了 Docker 项目中第二重要的力量。

但很快1年的时间双方就决裂了，这次决裂的根本原因，正是源于 Docker 公司对 Docker 项目定位的不满足。因为，即使Docker 项目备受追捧，但用户们最终要部署的，还是他们的网站、服务、数据库，甚至是云计算业务。这就意味着，只有那些能够为用户提供平台层能力的工具，才会真正成为开发者们关心和愿意付费的产品。

2014 年底的 DockerCon 上，Docker 公司雄心勃勃地对外发布了自家研发的“Docker 原生”容器集群管理项目 Swarm，不仅将这波"CaaS"热（Container-as-a-Service）推向了一个前所未有的高潮，更是寄托了整个 Docker 公司重新定义 PaaS 的宏伟愿望，即让开发者把应用部署在我的项目上。

//单机 Docker 项目：docker run " 我的容器//多机 Docker 项目：docker run -H " 我的 Swarm 集群 API 地址 " " 我的容器 "

• 2015年Docker生态

在 2014 年到 2015 年这段时间里，Docker 项目的迅速走红催生出了一个非常繁荣的“Docker 生态”。在这个生态里，围绕着 Docker 在各个层次进行集成和创新的项目层出不穷。而此时已经大红大紫到“不差钱”的Docker 公司，开始及时地借助这波浪潮通过并购来完善自己的平台层能力。收购的公司包括：

有热度就会有竞争，当时就是老牌集群管理项目 Mesos 和它背后的创业公司 Mesosphere。Mesos 作为 Berkeley 主导的大数据套件之一，是大数据火热时最受欢迎的资源管理项目Mesos 社区却拥有一个独特的竞争力：超大规模集群的管理经验。早在几年前，Mesos 就已经通过了万台节点的验证，2014 年之后又被广泛使用在 eBay 等大型互联网公司的生产环境中。而这次通过 Marathon 实现了诸如应用托管和负载均衡的 PaaS 功能之后，Mesos+Marathon 的组合实际上进化成了一个高度成熟的 PaaS 项目，同时还能很好地支持大数据业务。

所以，在这波容器化浪潮中，Docker Swarm 和Mesosphere不分伯仲，CoreOS和RedHat已无招架之力。

• 2016~2018年Kubernetes与CNCF

Docker 公司在 Docker 开源项目的发展上，始终保持着绝对的权威和发言权，并在多个场合用实际行动挑战到了其他玩家（比如，CoreOS、RedHat，甚至谷歌和微软）的切身利益。Google 公司，向 Docker 公司表示想和 它共同推进一个中立的容器运行时（container runtime）库作为 Docker 项目的核心依赖。不过，Docker 公司并没有认同这个明显会削弱自己地位的提议，还在不久后，自己发布了一个容器运行时库 Libcontainer。

可谓天下苦秦久矣，这种情绪在 2015 年达到了一个小高潮，容器领域的其他几位玩家开始商议“切割”Docker 项目的话语权。而“切割”的手段也非常经典，那就是成立一个中立的基金会。于是，2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。OCI 的成立更多的是这些容器玩家出于自身利益进行干涉的一个妥协结果。所以，尽管 Docker 是 OCI 的发起者和创始成员，它却很少在 OCI 的技术推进和标准制定等事务上扮演关键角色，也没有动力去积极地推进这些所谓的标准。

在这个领域里，像 Google 和 RedHat 这样的成熟公司，都拥有着深厚的技术积累；而像 CoreOS 这样的创业公司，也拥有像 Etcd 这样被广泛使用的开源基础设施项目。所以这次，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。

CNCF 社区就需要至少确保两件事情：

1. Kubernetes 项目必须能够在容器编排领域取得足够大的竞争优势；
2. CNCF 社区必须以 Kubernetes 项目为核心，覆盖足够多的场景。

Kubernetes大多来自Google公司的Borg 和 Omega 系统的内部特性，这些特性落到 Kubernetes 项目上，就是 Pod、Sidecar 等功能和设计模式。这些超前的思想是 Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华。这正是 Kubernetes 项目能够从一开始就避免同 Swarm 和 Mesos 社区同质化的重要手段。就这样，Kubernetes 项目在 GitHub 上的各项指标开始一骑绝尘，将 Swarm 项目远远地甩在了身后。

而在看到了 CNCF 社区对用户表现出来的巨大吸引力之后，大量的公司和创业团队也开始专门针对 CNCF 社区而非 Docker 公司制定推广策略。面对这样的竞争态势，Docker 公司决定更进一步。在 2016 年，Docker 公司宣布了一个震惊所有人的计划：放弃现有的 Swarm 项目，将容器编排和集群管理功能全部内置到 Docker 项目当中。在面对这种独裁式的方式，Kubernetes 的应对策略则是反其道而行之，开始在整个社区推进“民主化”架构，即：从 API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入到 Kubernetes 项目的每一个阶段。

Kubernetes 项目的这个变革的效果立竿见影，很快在整个容器社区中催生出了大量的、基于 Kubernetes API 和扩展接口的二次创新工作，比如：

• 目前热度极高的微服务治理项目 Istio；
• 被广泛采用的有状态应用部署框架 Operator；
• 还有像 Rook 这样的开源创业项目，它通过 Kubernetes的可扩展接口，把 Ceph 这样的重量级产品封装成了简单易用的容器存储插件。

就这样，在这种鼓励二次创新的整体氛围当中，Kubernetes 社区在 2016 年之后得到了空前的发展。

2017 年 10 月，Docker 公司出人意料地宣布，将在自己的主打产品 Docker 企业版中内置 Kubernetes 项目，这标志着持续了近两年之久的“编排之争”至此落下帷幕。

云原生技术生态现状

CNCF 有一张云原生全景图（
https://github.com/cncf/landscape），在这个全景图里已经有 200 多个项目和产品了，这些项目和产品也都是和 CNCF 的观点所契合的。所以如果以这张全景图作为背景，加以思考就会发现，我们今天所讨论的云原生其实主要谈论了以下几点：

1. 云原生基金会 —— CNCF；
2. 云原生技术社区，比如像 CNCF 目前正式托管的 20 多个项目共同构成了现代云计算生态的基石，其中像 Kubernetes 这样的项目已经成为了世界第四活跃的开源项目；
3. 除了前面两点之外，现在全球各大公有云厂商都已经支持了 Kubernetes。此外，还有 100 多家技术创业公司也在持续地进行投入。现在阿里巴巴也在谈全面上云，而且上云就要上云原生，这也是各大技术公司拥抱云原生的一个例子。

云原生的技术范畴

CNCF给出了目前云原生包含的开源项目及云原生的技术的路线图，旨在为云原生应用者提供一个资源地图，帮助企业和开发人员快速了解云原生体系的全貌。

1. 容器化（Containerization）

目前最流行的容器化技术是Docker，你可以将任意大小的应用程序和依赖项，甚至在模拟器上运行的一些程序，都进行容器化。随着时间的推移，你还可以对应用程序进行分割，并将未来的功能编写为微服务。

2. 持续集成&发布（CI/CD）

创建CI/CD环境，从而使源代码上的任意修改，都能够自动通过容器进行编译、测试，并被部署到预生产甚至生产环境中。

Argo:云原生的工作流引擎 - 知乎 (zhihu.com)

3. 编排&应用定义（Orchestration&Application Definition）

Kubernetes是目前市场上应用编排领域被最广泛应用的工具，Helm Charts可以用来帮助应用开发和发布者用于升级Kubernetes上运行的应用。

Kubernetes（k8s）中文文档 Kubernetes概述_Kubernetes中文社区
Helm | Docs

4. 监控&分析（Observability&Analysis）

在这一步中，用户需要为平台选择监控、日志以及跟踪的相关工具，例如将Prometheus用于监控、Fluentd用于日志、Jaeger用于整个应用调用链的跟踪。

通俗易懂：什么是 Jaeger 软件？优势及作用一览 (redhat.com)
Introduction · Prometheus中文技术文档
Fluentd简介_LiangIter的博客-CSDN博客_fluentd

5. 服务代理、发现、网格化（Service Proxy、Discovery、Mesh）

CoreDNS、Envoy和LInkerd可以分别用于服务发现和服务治理，提供服务的健康检查、请求路由、和负载均衡等功能。

史上最全的高性能代理服务器 Envoy 中文实战教程 ！(强烈建议收藏) - 云+社区 - 腾讯云 (tencent.com)
CoreDNS 简单介绍 - 简书 (jianshu.com)
Linkerd 初探 - 简书 (jianshu.com)

6. 网络策略&安全（Networking，Policy，Security）

Calico、Flannel以及Weave Net等软件用于提供更灵活的网络功能。

calico网络原理、组网方式和使用 - 云+社区 - 腾讯云 (tencent.com)
一篇文章带你了解Flannel - Flannel - 操作系统 - 深度开源 (open-open.com)
Weave系列之Weave Net安装与探索 | SDNLAB | 专注网络创新技术

7. 分布式数据库&存储（Distributed Database&Storage）

分布式数据库可以提供更好的弹性和伸缩性能，但同时需要专业的容器存储予以支持。

ETCD 简介 + 使用_菲宇的博客-CSDN博客_etcd

8. 流&消息传递（Streaming&Messaging）

当应用需要比JSON-REST这个模式更高的性能时，可以考虑使用gRPC或者NATS。gRPC是一个通用的RPC（远程调用）框架（类似各种框架中的RPC调用），NATS是一个发布/订阅和负载均衡的消息队列系统。

高性能消息中间件——NATS - 知乎 (zhihu.com)
gRPC详解 - 简书 (jianshu.com)

9. 容器注册&运行（Container Registry&Runtime）

Harbor是目前最受欢迎的容器镜像库，同时，你也可以选择使用不同的容器运行环境用于运行容器程序。

harbor搭建及使用 - 浪淘沙& - 博客园 (cnblogs.com)

10. 软件发布

最后可以借助Notary等软件用于软件的安全发布。

Notary项目 - 云+社区 - 腾讯云 (tencent.com)

Reference

深入剖析Kubernetes (豆瓣) (douban.com)

Google 艺术与文化

CNCF x Alibaba 云原生技术公开课 - 云原生教程 - 阿里云全球培训中心 (aliyun.com)

什么是云原生？ - 云+社区 - 腾讯云 (tencent.com)

[云原生]CNCF Trail Map 云原生路线图 - SkyBiuBiu - 博客园 (cnblogs.com)

【IaaS&PaaS】为什么选择PaaS？-阿里云开发者社区 (aliyun.com)