云原生：打造「阿拉丁神灯式」应用厨房-InfoQ



 写点什么

编者按：

《2001 太空漫游》的作者、英国科幻作家 Clarke 曾提出著名的“克拉克三定律”，最后一条说的是「足够先进的科技与魔法无异」。在近年兴起的云原生领域，这个观点有望得到再一次证明。

在云原生赋能下，未来企业的 IT 基础架构将从以资源为核心转变为以应用为核心，应用开发的效率和体验将获得根本性改善，终极愿景甚至是用简单的语义表达就能实现应用功能开发。

面对云原生「神器」，本期晨思尝试回答以下几个问题：如何理解云原生和云计算的差异，云原生代表技术价值何在、是如何运作的，云原生江湖有哪些主要玩家，中国云原生发展现状，以及初创公司可能的突破方向。

阅读愉快。

如果说云计算给了企业一台可以弹性伸缩、按需配置的“集成灶”，那么云原生就是给了企业一张可以随意组合、心随意动的“做菜台”。
强大的核心技术、深刻的企业级产品理解能力和庞大的生态群是奠定云原生企业成功的“三座大山”。
初创公司想要杀出重围，不仅要学会避开大厂的舒适区域，更要构建自己在服务或技术上的护城河。

理念先行：以应用为核心的云计算 2.0

云计算的时代从 2006 年 Eric Schmidt 首次提出、同年 Amazon 推出 AWS 云服务至今，已没有人再怀疑它是否只是昙花一现。随着全球和国内 IaaS 市场格局的逐渐尘埃落定，巨头间的厮杀也已接近尾声。就在所有人觉得大局已定，准备平静地接受云计算时代洗礼的时候，“云原生”这个词悄然出现在了大众的视野里，并在这些年随着容器、K8S 等技术的成熟愈演愈烈，似乎正在掀起另一波 IT 基础架构创新的浪潮。

不同于云计算从一开始就有着清晰而系统化的认识，云原生这个词直到今天都很难出现一个统一的描述，如果我们引用 CNCF（Cloud Native Computing Foundation）的官方定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。
结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

似乎依然很难用非常通俗的方式去理解？

好的，那我们来用一个比较形象的例子来阐述吧！

假如我们把企业的整个开发体系比作饭店做菜的厨房，它的内部有着一个个厨师们使用的工作台，工作台的结构如图所示：

我们一层层来看——

底层

燃气、管道和灶台代表企业底层的 IT 资源，包括计算、存储和网络。传统的形态和配置方式所带来的的问题包括：

1. 资源浪费。每个工作台炒菜所需的资源各有不同，大锅菜的燃气需要给足一些，管道要粗一些，家常小炒则火候要小一些，容易造成给多了或者给少了的情况，而且每一个工作台的资源配置都各不相同，无法复用。

配置效率低。每当需要新增工作台的时候，得一个一个按部就班地布置新的燃气、灶台和管道。

所以理想化的状态应该是，实现燃气、灶台、管道的资源池化并统一管理，每一个做菜工作台按配置、按需求配套提供做菜工作基础资源。

现实中，计算、存储、网络这些 IT 基础资源，以前都被锁定在一个个孤立的主机或者服务器之中，云计算通过虚拟化技术将这些资源池化；而以 Openstack 为代表的云计算管理框架，对这些资源实现高效、统一的管理，用户于是可以按需来快速创建自己的虚拟主机。

中间层

中间层则是针对不同的做菜方式（蒸、炒、煎、炸）所需的厨具以及针对具体菜品所需的配菜，代表了企业针对不同的应用开发类型所需要的的配置、运行环境、组件插件等。

应用层

类似的，在企业 IT 上云并拥有可以弹性伸缩、按需配置的工作台之后，应用开发就成了下一个需要解决的问题。为了拥有灵活、简单但又强大的业务开发能力，云原生这一概念也就应运而生，让我们来看它是如何解决这些问题的。

如果说云原生是一棵大树，那容器/K8S 就是它的根和土壤，微服务就是它四通八达的树枝，服务网格就是它内部输送养分的管道，无服务器就是它最后结出的果实。

容器和 K8S

当我们在实际配置和炒菜的过程中，首先会遇到这样一些问题：

1. 效率问题。比如土豆烧牛肉，如果要做一百份，那就要一个一个地准备一百份土豆烧牛肉的配菜、锅具和锅铲。

2. 兼容问题。比如普通炒菜需要炒锅，东北铁锅炖需要炖锅，广式点心需要蒸笼，互相之间难以兼容。

3. 版本问题。不同厨师对于同一道菜的配菜和做法，甚至同一个厨师做同一道菜每一次可能都有或大或小的差别。

4. 历史版本记录问题。比如三个月前某一个版本的土豆烧牛肉特别受欢迎，希望现在可以快速推广，却很难做到快速、完美的复刻。

而容器和 K8S 可以完美解决这些问题，容器对每道菜的每一个版本所需的所有炒菜环境、配菜等进行封装，使其可以在任何类型的工作台制作；而 K8S(kubernetes)作为容器的调度和编排框架，则实现了对容器的统一管理，包括容器的自动化部署和复制、自动伸缩集群规模、容器间的负载均衡、版本升级等。

微服务

假设厨房又租了一台切土豆机，现在的收费模式是按天或者按年去收费。如果机器某个部分坏了，那么首先整个机器就不能用了，而且很有可能需要对整个机器进行维修或者更换；如果有性能更好的刀片或者容量更大的土豆盒子，那么需要推出新的产品系列；如果厨房土豆实在太多或者客人要得急，那只能多租几台。

这个时候市场上出现了一款全新切土豆机，它把切土豆机解耦成了土豆盒子和切片器两个功能。这样用户如果觉得土豆太多放不下，或者土豆盒子够用但希望能切快一点，只需要分别增加土豆盒子或者换更好的切片器就可以，并基于盒子的大小或刀片的质量阶梯式付费。如果盒子或者切片器坏了，另一个部分还能正常工作，只需要分别更换或维修即可。

这其实就是应用的微服务化，微服务松耦合的特性使得应用能够实现开发阶段的快速响应，部署上线后一个服务出现问题不会影响整个应用。还能更大程度地实现按需付费、节约成本。团队能够更关注自己的工作成果，聚焦指定的业务功能或业务需求，大大提高了开发效率。

服务网格(Service Mesh)

现在整个饭店都被你微服务化了，每一个厨房员工就是一个微服务，比如洗菜（青菜、鸡肉、鱼肉等等）、切菜、炒菜......结果问题又来了：很多员工是从别的饭店雇来的，有的讲英语、有的讲中文、有的讲方言，甚至就算语言相通，不同饭店来的各自的沟通方式也完全不一样，互相无法高效交流；之前为整个饭店量身制定了很多规章制度和考核指标，但现在具体到个人，如何实现透明化高效管理呢？

这时候一种叫服务网格的沟通器出现了，它可以很方便地分发给所有人，所有的指令和沟通都可以通过这个翻译器进行传达。这样整个饭店的信息沟通就被沟通器给抽象了，方便饭店进行统一的管理。

所以服务网格的理念就是希望通过 Sidecar（边车模式）这种无侵入的方式运行在每个应用旁边，独立部署于业务之外，形成抽象的应用网络网格。当基础设施中的所有服务流量通过 Sidecar 网格流动时，不仅可以通过一致的可观察性进行高效监控，还可以实现统一的网络策略配置。

无服务器(Serverless)

基于以上打造的这些能力，你终于可以实现阿拉丁神灯式的饭店了，今后每一次做菜你只需要告诉厨房你需要什么菜，没有配置和管理灶台、柴火、锅碗瓢盆的烦恼，也不需要去关心后厨人员之间的筛选跟配合，短短数秒，菜品就会来到你面前。

无服务器(Serverless)就代表了这样一种终极理想，让开发者专注于业务代码的开发，无需关注平台运行的差异性，也不需要关心应用逻辑以外服务相关的事情，包括管理、配置、运维。

综上，通过云原生的赋能，我们认为在云原生的时代，企业 IT 基础架构将实现从以资源为核心到以应用为核心的转变，同时应用开发的效率和体验将会获得根本性的改善，最终甚至实现：

用简单的语义表达就能实现一个应用功能开发
用拖拉拽的方式就可以实现业务的组合开发
底层和运维对用户完全透明
应用的计费可以精确基于功能的实际调用和资源的实际消耗

在这样一种愿景中，开发和产品之间的界限或许会越来越模糊，产品经理可以通过高效、简易的开发方式直接实现业务需求。

云原生的江湖史

在亚马逊的 AWS 确立了云计算各个部分的边界，IaaS 层尘埃落定的时候，大家争夺的焦点终于转到了 PaaS 层面。如果说 IaaS 层的核心是围绕着资源（计算、存储、网络），那么 PaaS 层的核心就是应用。而目前以 K8S 为核心主导江湖的现状是如何逐渐形成的呢，这其中其实经历了两次 PK，主要玩家包括：Cloud Foundry、Mesos（现更名为“D2IQ”）、Docker Swarm 以及 K8S。

K8S 与 Cloud Foundry

K8S(Kubernetes)脱胎于 Google 内部的分布式集成管理系统 Borg，在开源之后大受欢迎，目前已经是绝对主导的容器集群管理方案。

Cloud Foundry 包括它内置的容器引擎 Warden 的出现还要略早于 K8S 与 Docker，是第一个开源 PaaS 云平台，最初由 VMware 开发，后来转入了 Pivotal。

与 K8S 相比，Cloud Foundry 的步子迈得更大一些，它让开发人员更专注于应用的开发而屏蔽了底层的资源管理，同时采用类似 Spring 的框架，对于不同的开发语言定制了固定的开发模板，同时提供了一个服务市场，可以在上面很方便绑定一些开箱即用的服务，比如数据库、监控工具和消息代理。

但最终 Cloud Foundry 还是落于下风，并且开始向 K8S 生态靠拢，要原因在于三个方面：

第一，对于 Docker 没有及时接纳，固执坚持底层使用自己的容器引擎，忽视了 Docker 在容器引擎中的带来的变革性优势，以至于当 Docker 倒向 K8S 之后，二者原本就广阔的生态群体产生的叠加效应一下子就拉开了差距。

第二，梦想太过美好以至于左脚迈得太大，右脚却没有跟上。虽然 CF 的概念更符合 PaaS 的定义，完全屏蔽了资源层，希望让开发人员专注于应用层，但事实上在开发过程中，你很难去定义哪些是开发者要做的，哪些是 IT 管理员要做的，尤其是在 DevOps 这个概念提出之后。

第三，类似 Spring 框架的开发模式对开发人员的限制过多，对于已经有比较固定的开发框架或流程的大型企业来说在初期会比较有优势，但是却很限制其他广大开发人员的发挥和创造力，也极大程度限制了生态的发展。

K8S 与 Docker Swarm、Mesos

业界一般称 Cloud Foundry 为上一代的 PaaS 平台，而这一代的 PaaS 平台注重于对容器的编排和管理，在最初则有三位主要玩家：Google 的 K8S、Docker 自己推出的 Docker Swarm，以及 Mesosphere 公司推出的 Mesos + Marathon。

由于在最早的时候，虽然 Google 内部有自己的一套针对内部容器集群的调度和编排流程 Borg，但出于对暴露自己的基础架构风险考虑，选择了针对市面上的开源容器引擎重新编写形成了 K8S，并且慧眼识珠的拥抱了 Docker。

而 Docker 在自己的容器引擎大火之后，也有了自己的野心，推出了配套的一系列工具，包括调度平台 Docker Swarm。然而由于自身并没有大规模节点的调度经验（上千或者上万），以至于在性能上很难满足企业需求，只能供个人或实验场景下使用，最终在宣布停止维护 Docker Swarm、全面拥抱 K8S 之后，这场竞争也终于落下了帷幕。

Mesos 本身其实是一个通用的资源管理平台，它选择了 Marathon 作为容器调度方案，在技术上最初是具有一定的领先性的，但最终的失败主要是由于 K8S + Docker 生态的建立，最终使得自己失去了市场中的地位。

Docker 在最重要的容器编排之战中失败，可以借鉴的教训包括：

开源并不是免费，开源作为一种商业模式，需要时刻思考组织和项目的生存问题，要保持自己被普遍使用且不可替代
开源技术在成功的路上不可避免会走向商业，包括 Docker，提前思考企业市场的挑战是非常重要的
开源项目在企业级市场中，优势与劣势并存，优势就是它所裹挟的庞大的开发者生态，而劣势则是对于企业级产品的理解
Docker 的失利，乍一看可能是时机和生态构建的问题，但归根结底是基因和能力问题

中国云原生进行时

目前在 CNCF 的全景图中，各个领域已经拥有超过 1500 个知名项目，总计吸引超过 650 亿美元的融资规模，创造了超过 19 万亿美元的市场规模；而中国在其中扮演着越来越重要的角色：

从数量上来看，共有 50 位来自中国的 CNCF 成员，超过总成员数的 10%，其中白金会员 3 位，黄金会员 6 位，银牌会员 37 位
从代码贡献来看，中国是世界 Top3 的项目贡献国家，PingCAP 和华为作为国内两个最大的项目贡献单位，总计提交 105,482 次项目贡献，分别名列全球第 6 和第 8
从社区来看，2019 年总共有 3,500 名来自中国的程序员参加了全球 K8S+云原生大会，中国累计完成 K8S 和云原生官方课程的人员数量已超过 20,000 人

除此之外，云计算带来的 IT 基础设施的变革已经从根本上为云原生的发展提供了强大的驱动力和稳定的基础支撑。到 2022 年，预计将有多达 60％的组织使用外部服务提供商的云托管服务产品，这个比例是 2018 年的两倍，云原生能力将成为技术产品经理的重要差异化因素。

对于云计算未来新技术展望方面，云原生的两大主流方向 Serverless 以及 Service Mesh 分列第一第二位，而 Kubeflow 也代表了云原生在应用端赋能的机会。

公有云 PaaS 市场规模继续保持高速增长，市场规模为 41.9 亿元，同比增长 92.4%。云原生产业作为现阶段云计算 PaaS 市场的重要支点，也延续了高速增长态势，根据中国信息通信研究院相关调研数据显示，2019 年中国云原生市场规模已达 350.2 亿元。

初创公司的机会在哪？

巨头型企业以大型云厂商和大型科技厂商为代表，比如华为、阿里、腾讯等，它们对于敏捷开发流程全生命周期的管理有着深刻的理解，在大规模集群化管理有无法替代的实践经验。但相对的，从产品上看则更多是围绕自己的公有云平台进行开发，基于这样的认知，我们认为初创型公司可从以下两个角度进行突破：

解决方案式

通过提供基于新技术或框架实现企业级产品矩阵和解决方案，以解决方案的完整性和底层多云环境的兼容性作为自己的产品壁垒，同时实现高效、强大的服务质量。

单点突破式

拥有绝对领先的核心技术能力，从价值和延展性很高的领域入手，以点带面，典型例子有 HashiCorp(CI/CD)、Kong（API 管理）。

同时我们认为在云原生体系里，开源模式可能会比以往发挥更大的作用，原因主要包括：开源项目更容易被其它产品支持和集成；云原生架构早期使用者以开发者为主，开源项目更容易快速建立口碑和影响力；在社区支持下，开源项目质量更容易得到保证。

相信在不久的将来，云原生将成为在云计算时代的二级火箭，助推企业和社会在数字化时代中，真正实现数据驱动的产业互联网。我们也期待着越来越多的初创企业，能够一起构建中国在基础设施领域的强大竞争力。

作者介绍：