《2001太空漫游》的作者、英国科幻作家Clarke曾提出著名的“克拉克三定律”，最后一条说的是「足够先进的科技与魔法无异」。在近年兴起的云原生领域，这个观点有望得到再一次证明。在云原生赋能下，未来企业的IT基础架构将从以资源为核心转变为以应用为核心，应用开发的效率和体验将获得根本性改善，终极愿景甚至是用简单的语义表达就能实现应用功能开发。面对云原生「神器」，本期文章回答以下几个问题：如何理解云原生和云计算的差异，云原生代表技术价值何在、是如何运作的，云原生江湖有哪些主要玩家，中国云原生发展现状，以及初创公司可能的突破方向。阅读愉快。
作者 | 钱进 晨山资本投资经理
❶ 如果说云计算给了企业一台可以弹性伸缩、按需配置的“集成灶”，那么云原生就是给了企业一张可以随意组合、心随意动的“做菜台”。
❷ 强大的核心技术、深刻的企业级产品理解能力和庞大的生态群是奠定云原生企业成功的“三座大山”。
❸ 初创公司想要杀出重围，不仅要学会避开大厂的舒适区域，更要构建自己在服务或技术上的护城河。
理念先行：以应用为核心的云计算2.0
云计算的时代从2006年Eric Schmidt首次提出、同年Amazon推出AWS云服务至今，已没有人再怀疑它是否只是昙花一现。随着全球和国内IaaS市场格局的逐渐尘埃落定，巨头间的厮杀也已接近尾声。就在所有人觉得大局已定，准备平静地接受云计算时代洗礼的时候，“云原生”这个词悄然出现在了大众的视野里，并在这些年随着容器、K8S等技术的成熟愈演愈烈，似乎正在掀起另一波IT基础架构创新的浪潮。
不同于云计算从一开始就有着清晰而系统化的认识，云原生这个词直到今天都很难出现一个统一的描述，如果我们引用CNCF（Cloud Native Computing Foundation）的官方定义：
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。
结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
假如我们把企业的整个开发体系比作饭店做菜的厨房，它的内部有着一个个厨师们使用的工作台，工作台的结构如图所示：
燃气、管道和灶台代表企业底层的IT资源，包括计算、存储和网络。传统的形态和配置方式所带来的的问题包括：
1. 资源浪费。每个工作台炒菜所需的资源各有不同，大锅菜的燃气需要给足一些，管道要粗一些，家常小炒则火候要小一些，容易造成给多了或者给少了的情况，而且每一个工作台的资源配置都各不相同，无法复用。
2.配置效率低。每当需要新增工作台的时候，得一个一个按部就班地布置新的燃气、灶台和管道。
所以理想化的状态应该是，实现燃气、灶台、管道的资源池化并统一管理，每一个做菜工作台按配置、按需求配套提供做菜工作基础资源。
现实中，计算、存储、网络这些IT基础资源，以前都被锁定在一个个孤立的主机或者服务器之中，云计算通过虚拟化技术将这些资源池化；而以Openstack为代表的云计算管理框架，对这些资源实现高效、统一的管理，用户于是可以按需来快速创建自己的虚拟主机。
中间层则是针对不同的做菜方式（蒸、炒、煎、炸）所需的厨具以及针对具体菜品所需的配菜，代表了企业针对不同的应用开发类型所需要的的配置、运行环境、组件插件等。
类似的，在企业IT上云并拥有可以弹性伸缩、按需配置的工作台之后，应用开发就成了下一个需要解决的问题。为了拥有灵活、简单但又强大的业务开发能力，云原生这一概念也就应运而生，让我们来看它是如何解决这些问题的。
如果说云原生是一棵大树，那容器/K8S就是它的根和土壤，微服务就是它四通八达的树枝，服务网格就是它内部输送养分的管道，无服务器就是它最后结出的果实。
当我们在实际配置和炒菜的过程中，首先会遇到这样一些问题：
1. 效率问题。比如土豆烧牛肉，如果要做一百份，那就要一个一个地准备一百份土豆烧牛肉的配菜、锅具和锅铲。
2. 兼容问题。比如普通炒菜需要炒锅，东北铁锅炖需要炖锅，广式点心需要蒸笼，互相之间难以兼容。
3. 版本问题。不同厨师对于同一道菜的配菜和做法，甚至同一个厨师做同一道菜每一次可能都有或大或小的差别。
4. 历史版本记录问题。比如三个月前某一个版本的土豆烧牛肉特别受欢迎，希望现在可以快速推广，却很难做到快速、完美的复刻。
而容器和K8S可以完美解决这些问题，容器对每道菜的每一个版本所需的所有炒菜环境、配菜等进行封装，使其可以在任何类型的工作台制作；而K8S(kubernetes)作为容器的调度和编排框架，则实现了对容器的统一管理，包括容器的自动化部署和复制、自动伸缩集群规模、容器间的负载均衡、版本升级等。
假设厨房又租了一台切土豆机，现在的收费模式是按天或者按年去收费。如果机器某个部分坏了，那么首先整个机器就不能用了，而且很有可能需要对整个机器进行维修或者更换；如果有性能更好的刀片或者容量更大的土豆盒子，那么需要推出新的产品系列；如果厨房土豆实在太多或者客人要得急，那只能多租几台。
这个时候市场上出现了一款全新切土豆机，它把切土豆机解耦成了土豆盒子和切片器两个功能。这样用户如果觉得土豆太多放不下，或者土豆盒子够用但希望能切快一点，只需要分别增加土豆盒子或者换更好的切片器就可以，并基于盒子的大小或刀片的质量阶梯式付费。如果盒子或者切片器坏了，另一个部分还能正常工作，只需要分别更换或维修即可。
这其实就是应用的微服务化，微服务松耦合的特性使得应用能够实现开发阶段的快速响应，部署上线后一个服务出现问题不会影响整个应用。还能更大程度地实现按需付费、节约成本。团队能够更关注自己的工作成果，聚焦指定的业务功能或业务需求，大大提高了开发效率。
现在整个饭店都被你微服务化了，每一个厨房员工就是一个微服务，比如洗菜（青菜、鸡肉、鱼肉等等）、切菜、炒菜......结果问题又来了：很多员工是从别的饭店雇来的，有的讲英语、有的讲中文、有的讲方言，甚至就算语言相通，不同饭店来的各自的沟通方式也完全不一样，互相无法高效交流；之前为整个饭店量身制定了很多规章制度和考核指标，但现在具体到个人，如何实现透明化高效管理呢？
这时候一种叫服务网格的沟通器出现了，它可以很方便地分发给所有人，所有的指令和沟通都可以通过这个翻译器进行传达。这样整个饭店的信息沟通就被沟通器给抽象了，方便饭店进行统一的管理。
所以服务网格的理念就是希望通过Sidecar（边车模式）这种无侵入的方式运行在每个应用旁边，独立部署于业务之外，形成抽象的应用网络网格。当基础设施中的所有服务流量通过Sidecar网格流动时，不仅可以通过一致的可观察性进行高效监控，还可以实现统一的网络策略配置。
基于以上打造的这些能力，你终于可以实现阿拉丁神灯式的饭店了，今后每一次做菜你只需要告诉厨房你需要什么菜，没有配置和管理灶台、柴火、锅碗瓢盆的烦恼，也不需要去关心后厨人员之间的筛选跟配合，短短数秒，菜品就会来到你面前。
无服务器(Serverless)就代表了这样一种终极理想，让开发者专注于业务代码的开发，无需关注平台运行的差异性，也不需要关心应用逻辑以外服务相关的事情，包括管理、配置、运维。
综上，通过云原生的赋能，我们认为在云原生的时代，企业IT基础架构将实现从以资源为核心到以应用为核心的转变，同时应用开发的效率和体验将会获得根本性的改善，最终甚至实现：
-
用简单的语义表达就能实现一个应用功能开发
-
-
-
应用的计费可以精确基于功能的实际调用和资源的实际消耗
在这样一种愿景中，开发和产品之间的界限或许会越来越模糊，产品经理可以通过高效、简易的开发方式直接实现业务需求。
在亚马逊的AWS确立了云计算各个部分的边界，IaaS层尘埃落定的时候，大家争夺的焦点终于转到了PaaS层面。如果说IaaS层的核心是围绕着资源（计算、存储、网络），那么PaaS层的核心就是应用。而目前以K8S为核心主导江湖的现状是如何逐渐形成的呢，这其中其实经历了两次PK，主要玩家包括：Cloud Foundry、Mesos（现更名为“D2IQ”）、Docker Swarm以及K8S。
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框架的开发模式对开发人员的限制过多，对于已经有比较固定的开发框架或流程的大型企业来说在初期会比较有优势，但是却很限制其他广大开发人员的发挥和创造力，也极大程度限制了生态的发展。
业界一般称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管理）。
同时我们认为在云原生体系里，开源模式可能会比以往发挥更大的作用，原因主要包括：开源项目更容易被其它产品支持和集成；云原生架构早期使用者以开发者为主，开源项目更容易快速建立口碑和影响力；在社区支持下，开源项目质量更容易得到保证。
相信在不久的将来，云原生将成为在云计算时代的二级火箭，助推企业和社会在数字化时代中，真正实现数据驱动的产业互联网。我们也期待着越来越多的初创企业，能够一起构建中国在基础设施领域的强大竞争力。
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）