云原生时代——投资人视角下的云原生趋势思考

来源：信天创投   作者：蒋宇捷

本文由“成都企业信息化促进会”编纂分享

作者：信天创投合伙人蒋宇捷，专注于企业服务、金融科技等投资领域，已投资多家知名公司，包括美味不用等、法大大、缔联科技、链上科技、知藏科技、飞榴科技、心知科技、司库立方等。创新工场早期代表性明星项目“百度魔图”联合创始人、CTO，公司于2011年被百度成功收购。

今天我们不讲行业和商业，讲讲2019年最热的概念-云原生（Cloud Native）。我认为云原生是未来10年IT发展最重要的趋势，但是它涵盖的概念非常多，需要花很多时间研究，同时浩如烟海的资料分散在网络上各个地方，缺乏系统性的梳理。今年2月我在基金内部做过一个分享，今日成文，希望让更多的人有所了解。

一、云原生及CNCF基金会

1.1从集装箱革命说起

有一本非常有名的书，叫《集装箱改变世界》，说的是看起来平淡无奇的铁箱子，如何从二十世纪起永久性的改变了这个世界，并促进了全球化和全球分工。集装箱的出现和发展是实体货物包装、运输、交付方式的一次革命。

《经济学家》杂志曾经评价说“没有集装箱，不可能有全球化”。集装箱为什么具有革命性？

经济全球化的基础就是现代运输体系,而一个高度自动化、低成本和低复杂性的货物运输系统的核心就是集装箱。集装箱最大的成功在于其产品的标准化及由此建立的一整套运输体系。能够让一个载重几十吨的庞然大物实现标准化，并且以此为基础逐步实现全球范围内的船舶、港口、航线、公路、中转站、桥梁、隧道、多试联运相配套的物流系统，这的确堪称人类有史以来创造的伟大奇迹之一，而撬动这个系统的理念就是标准化和系统化。

改变世界的不仅仅是集装箱本身，还有一整套货物处理的新方法，包括港口、货船、起重机、卡车，还有发货人的自身操作方式等。

云原生在IT领域的意义非常类似于集装箱，只是里面装载的不再是实体货物，而是虚拟世界的二进制代码和软件。我们将在介绍完众多概念之后再来对应解释。

1.2云原生的诞生

随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。

云原生的发展史

来自CNCF基金会执行董事Dan Kohn

云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。

云原生（Cloud Native）这个概念，是由Pivotal的Matt Stine于2013年首次提出，他还在2015年出版了《Migrating to Cloud-Native Application Architectures（迁移到云原生架构）》一书。

Gartner提到云原生的定义尚不明确，但含义丰富。云原生对于不同的人和组织来讲，有着不同的理解。众多顶级技术的铸造者、Matt Stine的东家Pivotal如此定义云原生。

“Cloud native is an approach to building and running applications that fully exploit the advantages of the cloud computing model.”——云原生是一种构建和运行充分利用云计算模型优势的应用程序的方法。

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”

其中服务网格和声明式API是新加入的内容，而不可变基础设施指的是应用的基础设施应是不可变的，是一个自包含、自描述可以完全在不同环境中迁移的东西，容器技术正是这一理念实现的基石。

而CNCF同时把云原生计算定义为：

“Cloud native computing uses an open source software stack to be:

Containerized. Each part (applications, processes, etc) is packaged in its own container. This facilitates reproducibility, transparency, and resource isolation.

Dynamically orchestrated. Containers are actively scheduled and managed to optimize resource utilization.

Microservices-oriented. Applications are segmented into microservices. This significantly increases the overall agility and maintainability of applications.”

——云原生计算使用的开源技术栈包括：

容器化。每个部分（应用、流程等等）都打包在自己的容器中，这有助于提升复用性、透明度以及改善资源隔离。

动态编排。容器受到有效的调度和管理，以便优化资源利用。

以微服务为导向。应用被分割到不同的微服务中，这种分割可以显著的提高应用的整体敏捷性和可维护性。

我个人理解，云原生是指从云的原生应用角度出发，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。

下表列举了云原生应用和传统应用的有哪些主要区别。

要转向云原生应用需要以新的云原生方法开展工作，云原生有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。

云原生的发展脉络

1.2.1云原生背后的价值主张有哪些

• 隔离性：把应用程序打包在容器中加快了代码和组件的重用，并且简化了操作

• 无锁定：开源软件栈支持在任何公共或私有云上或以组合方式进行部署

• 无限扩展：为能够扩展到数万个自修复多租户节点的现代分布式系统环境而优化

• 灵活性和可维护性：将应用程序拆分为具有明确描述的依赖关系的微服务

• 提高效率和资源利用率：动态管理和调度微服务的中央编排流程降低了与维护和操作相关的成本

• 应用的弹性：以应对单个容器甚至数据中心的故障，以及不同级别的需求

2019年，Gartner曾经发布报告表示云原生时代已经到来，在未来三年中将有75%的全球化企业将在生产中使用容器化的应用。

请注意，云原生相关技术不仅仅能用于云计算，即便是和云计算即对立又协同的边缘计算，微服务、容器、Kubernetes依然是事实上的杀手应用和标准。如由著名的Kubernetes管理平台创业公司Rancher所贡献的K3s项目，就是Kubernetes（K8s）的最轻量级版本，以满足边缘计算和IOT环境中，在x86、ARM64和ARMv7处理器上运行小型、易于管理的Kubernetes集群日益增长的需求。

1.3云原生计算基金会CNCF

提到云原生，就不能不介绍云原生计算基金会CNCF（Cloud Native Computing Foundation）。CNCF于2015 年7月由Google 牵头成立，隶属于 Linux 基金会，初衷是围绕云原生服务云计算，致力于培育和维护一个厂商中立的开源生态系统，维护和集成开源技术，支持编排容器化微服务架构应用，通过将最前沿的模式民主化，让这些创新为大众所用。

CNCF的使命包括以下三点：

• 容器化包装

• 通过中心编排系统的动态资源管理

• 面向微服务

全球主流的科技企业和云计算厂商绝大部分都是CNCF会员，其中不乏多家来自中国的科技巨头。

CNCF黄金、白金会员

截止2020年4月，CNCF 基金会共托管49个云原生项目，每个CNCF项目都对应一个成熟度等级，申请成为CNCF项目的时候需要确定项目的成熟度级别，Kubernetes和 Envoy等项目基于生产可用和高稳定性首先成为毕业项目（9个），其他项目则根据其成熟度分别位于孵化（17个）和沙箱（23个）阶段。CNCF目前托管的项目共同构成了云原生生态的基石。

值得注意的是其中有三个来自中国的项目：VMware中国团队为企业用户设计的 Registry Server开源项目Harbor，PingCap贡献的分布式事务键值数据库TiKV以及阿里自研的P2P文件分发系统Dragonfly。

CNCF项目成熟度等级划分

对于企业在复杂的基础架构之上如何推动云原生应用的更好落地，从而更好地适应环境与业务的发展，CNCF给出了路线图（Trail Map）用于对用户在整体上给出指导建议，共分成十个步骤（容器化；CI/CD；应用定义及编排；监控及分析；服务代理、发现和网格；网络、策略及安全；分布式数据库及存储；流与消息；镜像库与运行时；软件分发）进行实施，而在不同的步骤都可以结合CNCF全景图（Landscape）中列出的产品或服务进行选择。

1.4云原生涵盖的主要概念

上面提到云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。另外一种比较主流的说法是云原生=微服务+DevOps+持续交付+容器化，广泛的见诸于各种文章和资料。

在接下来的《云原生时代》系列报告中，我们将依照这些概念，分成DevOps与CI/CD；微服务、API管理与集成；容器与Docker；Kubernetes与容器编排之战四个部分全面介绍云原生各个组成部分。

二、DevOps与CI/CD

2.1 DevOps

DevOps（Development & Operations，开发和运维）是09年提出来的概念，但一直没有太火。直到14年，容器与微服务架构的提出，DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。

对于DevOps，微服务不是必须的，但微服务为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。所以，也有人称微服务是DevOps架构。

DevOps流程示意图

DevOps与下面提到的CI、CD不同，DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。DevOps的概念似乎与持续交付的概念有些类似，两者均旨在促进开发与运维之间的协作，但是实际上两者差别很大：DevOps 更偏向于一种文化的构建，在DevOps文化指导下，团队中将包含了具有不同技能的人员（开发、测试等），并通过自动化测试与发布的手段，更快、更高质量的生产软件。

2.2持续集成

持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。

持续集成流程示意图

持续集成带来的好处是：

• 易于定位错误

• 易于控制开发流程

• 易于Code Review

• 易于减少不必要的工作

2.3持续交付

与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。

持续交付流程示意图

持续交付带来的好处是：

• 繁琐的部署工作没有了。团队不再需要花费几天的时间去准备一个发布

• 可以更快的进行交付，这样就加快了与客户之间的反馈环

• 轻松应对小变更，加速迭代

2.4持续部署

持续部署（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

持续部署流程示意图

持续部署带来的好处是：

• 发布频率更快，因为不需要停下来等待发布。每一处提交都会自动触发发布流

• 在小批量发布的时候，风险降低了，发现问题可以很轻松的修复

• 客户每天都可以看到持续改进和提升，而不是每个月或者每季度，或者每年

自动实时的部署上线，是最优的解决办法，但持续部署的要求是团队非常成熟，并且上线前是需要经过QA测试的，所以实际情况下很难实现，一般的团队也很难接受，挑战和风险都很大。

我们总结下，DevOps、持续集成、持续交付、持续部署并不是某种技术栈或者框架，而是开发文化、流程、理念和操作方式。

三、微服务、API管理与集成

3.1什么是微服务

微服务（Microservice）概念最早出现于2012年，2015年以后受到越来越多的关注，并且逐渐开始流行开来。其中著名技术大神Martin Fowler功不可没，他于2014年发表的一篇博客《Microservices: a definition of this new architectural term》（微服务：新技术架构的定义）清晰的定义和阐述了微服务概念。

“要开始解释什么是微服务之前，先了解单体（Monolithic）应用是很有用的：作为一整个单元构建的应用程序。企业应用由三个重要部分组成：客户端界面（由HTML、Javascript组成，使用浏览器访问）、数据库、服务端程序。服务端程序处理HTTP请求、执行业务逻辑、检索并更新数据库中的数据、选择和填充HTML视图发送给客户端。这个服务端程序是一个单一结构也即一个整体，系统中的任何修改都将导致服务端重新编译和布署一个新版本。

这样一个单体应用很自然的被构建成为一个系统，虽然可以使用开发语言的基本特性把应用封装成类、函数、命名空间，但是业务中所有请求都要在单一的进程中处理完成，在某些场景中，你可以在开发人员的笔记本电脑中运行和测试，并且通过布署通道将测试通过的程序布署到生产环境中，你还可以水平扩展，利用负载均衡将实例布署到多台服务器中。

的确，单体应用也非常成功，但是越来越多的人感觉到了不妥，特别是应用程序被发布到云的时候，变更周期被捆绑在一起-对应用程序一小部分所做的变更，都需要重新编译和部署整个应用。随着时间的推移，软件开发者很难保持一个好的模块架构，使得单个模块的变更不会影响到其它模块，而且扩展时也只能进行整体扩展，而不能根据需求进行部分扩展。”——Martin Fowler

下图是传统单体应用的技术及对应的组织架构，Martin Fowler称之为大家已熟知的Siloed Architectures-烟囱式（也称为谷仓）架构。

传统单体应用的架构及对应的职能型组织架构

综上，传统的单体应用有很大的局限性，应用程序随着业务需求的迭代、功能的追加扩展，最终成为一个庞然大物。单体应用的局限性大体包括以下几方面：

• 复杂性高：业务规模和团队规模发展的一定阶段，模块耦合严重，代码难以理解，质量变差

• 交付效率低：构建和部署耗时长，难以定位问题，开发效率低，全量部署耗时长、影响范围广、风险大，发布频次低

• 伸缩性差：单体只能按整体横向扩展，无法分模块垂直扩展

• 可靠性差：一个bug有可能引起整个应用的崩溃

• 阻碍技术创新：受技术栈限制，团队成员使用同一框架和语言

“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API)。这些服务要基于业务场景，并使用自动化布署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。”—— Martin Fowler

微服务架构将单体应用，按照业务领域拆分为多个高内聚低耦合的小型服务，每个服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，如HTTP RESTful API，独立自动部署，可以采用不同的语言及存储方式。微服务体现去中心化、天然分布式，是中台战略落地到IT系统的具体实现方式的技术架构，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。

下图左边是传统的单体应用，右边是微服务模式，图中每种颜色代表一种可拆分的微服务应用。

单体应用和微服务

一个比较形象的例子是装配式建筑。传统建筑（单体应用）的施工周期（开发时间）很长，往往依赖于建筑公司（开发团队）的能力和水平，修建完成后难以搬迁和复用，而装配式建筑（微服务）的梁、板、柱、墙等构件（单个服务）可以事先批量化的在工厂（容器）生产，而在建造过程中，我们可以把构件想象成一块块乐高积木，在施工现场只需把它们拼合在一起，大大提升了施工进度和建筑质量。

装配式建筑：乐高积木

微服务的特征包括：

• 小：粒度小，专注于一件事

• 独：单独的进程。微服务不等于组件，服务是可以直接使用的商品，组件是待加工的原材料

• 轻：轻量级通信机制，通常是HTTP Restful的接口。此处区别于传统的SOA（面向服务的架构）

• 松：松耦合，可以独立部署。每个微服务可以独立编译、独立部署、独立运行

微服务采用独立的数据库服务，数据去中心化

微服务运行在独立的进程中，部署去中心化

微服务架构的好处是：

• 易于开发与维护：微服务相对小，易于理解

• 独立部署：一个微服务的修改不需要协调其它服务

• 伸缩性强：每个服务都可按硬件资源的需求进行独立扩容

• 与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力

• 技术异构性：使用最适合该服务的技术，降低尝试新技术的成本

• 企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡

微服务的实践有两个重要问题：什么时候选择微服务架构，以及颗粒度如何拆分，与经验和实际情况息息相关。

3.2微服务基础设施及案例

微服务架构最常见、最广泛使用的框架是基于Java的Spring Cloud（集成了上图里的Netflix OSS技术栈），提供了服务发现、负载均衡、故障转移、动态扩展和数据分区等功能，已经成为微服务的最佳实践。

但是Spring Cloud构建在Java虚拟机之上，不能满足高并发下的性能要求，所以许多开源产品层出不穷，其中也包括中国互联网企业所贡献的微服务框架，例如华为的ServiceComb、阿里的Dubbo等等。

下面我们举一个例子。传统的电商的技术架构如下图所示，这是一个单体应用。

所带来的常见问题包括：

• 不同客户端产品之间，例如小程序、App、网站端有许多相同业务逻辑的重复代码，每个产品都要各自维护一份代码，修改的时候所有地方要一起修改。

• 单个应用经常需要给其他应用提供接口，渐渐地越来越复杂，包含了很多本来不属于它的逻辑，代码变得臃肿，功能边界模糊。

• 系统代码耦合性高，相互之间逻辑复杂，一旦出现开发离职的情况，继任者需要花很长时间review代码，才有可能搞清楚整体架构和逻辑关系。

• 多个应用使用一个数据库，依赖性严重，很难重构和优化。所有应用都在一个数据库上操作，数据库很容易出现性能瓶颈。同时数据库成为单点，出现意外整个系统都会受到影响。

• 即使只改动一个小功能，也需要整个应用一起发布，发布流程繁琐、上线时间长。并且很容易出现一个小bug影响整个系统，每次发布都是胆战心惊，很容易出现开发、运维和测试之间的矛盾。

下面我们用微服务重构整个系统：

改造之后，去除了大量冗余代码，系统复用性得到提升；不同的团队专注于不同的微服务，代码和工程质量得到保证；数据库不再存在单点问题，系统健壮性得以提升；前后端分离，业务逻辑更加清晰；降低了系统耦合性，不同的微服务可以分开部署上线，相互之间并不影响。

3.3组织挑战、康威定律与蜂群理论

请注意，微服务理念不仅反映了技术架构的变化，也反映了组织内部沟通结构为了应对更加灵活、快速、碎片化的需求和环境而变化的结果。例如液态组织就是组织形态应对当前市场环境快速变化的一种输出形式，但实际应该如何构建？

曾经有一张非常有名的组织架构图，如下图所示。

对一家企业来说，能一步步不断发展壮大，进入一个领域就能迅速突破，这其中的根本核心必然是组织模式。在粗放发展的年代，很少有企业强调内部效率，组织模式绝大部分都类似单体应用，按照职能划分的方式进行管理，从而创造了无数的烟囱/谷仓。

单体架构和职能型组织模式相似

一张著名的图：技术组织造就了难以逾越的谷仓

新的组织设计理念认为传统的烟囱形式会成为创建有效增长和盈利途径的障碍，需要解构组织孤岛，采用跨职能组织的形式以支持增长。企业组织设计是非常专业的领域，有许多文章讨论，例如《战胜组织孤岛的战略之路》。

职能组织与跨职能组织

我们可以看到单体应用和职能组织，微服务与跨职能组织，在形式上是高度相似的，这引申出微服务背后的理论基础。

“当希望把一个大型应用拆分成多个部分时，管理层通常将重点放在技术层面。而如果组织架构还按UI团队、服务端逻辑团队和数据库团队的标准设立，甚至一个非常简单的变更都将导致跨团队间的项目协作，从而耗费时间和预算审批。一个高效的团队会针对这种情况进行优化，关注它们所涉及的应用逻辑，并从中做出更好的选择。换句话说，逻辑无处不在。这是康威定律的一个实例。”—— Martin Fowler

设计系统的架构受制于产生这些设计的组织的沟通结构（Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）—— Melvyn Conway, 1967

康威定律可谓软件架构设计中的第一定律，本质是对商业世界的规律总结，但是因为投稿到编程相关的杂志，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。

例如微服务的团队间应该是inter-operate，not integrate（互操作、不集成）。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本也就能减低。

康威定律可以上升到哲学的高度进行讨论，但是过于复杂。简言之，微服务架构与组织模式互相决定和影响，协同才能发挥出最大价值。

微服务理念对应的组织模式包括蜂巢型组织，它具有突出的稳定性和抗弯曲能力，特点是：

• 跨组织：它不一定是一个独立的法人实体，而是为了特定目标或项目形成的联盟

• 相对统一：蜂巢组织不是一成不变的，当市场需求或组织目标发生变化时立即变化

• 分享性：它改变了传统的等级分明的金字塔结构，允许信息横向传递与交流，使信息利用更为充分及时

在这样一个以蜂巢为理念搭建的企业圈层里面，各个独立团队能够得到更好的协助与支撑，不断扩大视野，提高眼界，掌握话语权，团队成员也会更有归属感。这样的团队乃至蜂巢本身，也一定会更有活力和变革力，更加能适应市场的变化。蜂巢型组织有四个突出特点，所谓活系统的特质也正是由此而来：没有强制性的中心控制；次级单位具有自治的特质；次级单位之间彼此高度连接；点对点间的影响通过网络形成了非线性因果关系。

微服务：筑巢

蜂巢型组织的典型案例之一是华为。除了组织架构去中心化的管理模式之外，华为的著名的轮值CEO制度正是由此而来，华为有三位轮值CEO，每六个月轮换一次，这体现了依靠集体民主决策而非一人独裁的理念。

再例如国美蜂巢式组织变革的实践是将由四个大区管辖54个分公司，调整为七个大区直接管辖200家分公司的结构，即将原来二级市场里的146家分公司独立出来，直接划归大区管辖，而原来四个大区变成七个大区。实践证明，组织扁平化是国美提升供应链效率，提升消费者消费体验的重要战略。

国外著名的代表案例是微服务先驱Netflix。Netflix是一家技术强大的互联网公司，但是它却没有CTO职位，产品团队和技术团队(包括UI前端工程团队、Discovery搜索工程团队和Platform平台团队等)全部汇报首席产品CPO，产品驱动是该公司的核心文化要素之一，Netflix称其为BusDevOps组织架构。

Netflix：BusDevOps组织

在整个系列第二部分中，我们介绍了DevOps，现在我们可以理解，DevOps是配合微服务的理念组织构建团队协作的方式，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。全部业务、研发和运维围绕产品开展工作，统一目标，大家都是产品驱动，分别服务于内外不同客户，避免技术驱动 vs 业务驱动的陷阱。

传统水平组织 vs DevOps驱动的垂直组织

在某些文章中，认为微服务的切割应该按照组织架构来划分，我反而觉得应该按微服务的分割方式来划分组织架构，因为归根结底，组织架构应该为业务服务，而不是业务为组织服务，组织需要贯彻执行微服务的理念，就必须由微服务驱动组织业务的不断迭代演进。

3.4微服务与中台

可能有人会问，中台的目标不也是为了解决企业内部业务系统烟囱林立，数据孤岛严重，各自为战，缺乏复用性，所以要充分提取业务共性，从而及时应对需求变化，听起来和微服务的目标和理念非常相似，那它们之间有什么异同呢？

阿里巴巴中台战略架构图

来自阿里官方的定义，“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”

中台架构，简单地说，就是企业级能力的复用，一种方法论，企业治理思想。

微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。

所以中台并不是微服务，中台是一种企业治理思想和方法论，偏向于宏观，微服务是技术架构方式，偏向于微观。而中台化的落地，离不开使用微服务架构。

中台强调核心基础能力的建设，基础能力以原子服务的形式来建设，并通过将原子服务产品化，支撑业务端各种场景的快速迭代和创新；原子服务和微服务所倡导的服务自闭环思想不谋而合，使得微服务成为实现原子服务的合适架构。支撑业务场景的应用也是通过服务来实现，其生命周期随业务变化需要非常灵活的调整，这也和微服务强调的快速迭代高度一致，所以业务应用服务也适合通过微服务来实现。

3.5 API管理与API集成

3.5.1全生命周期API管理

上文提到微服务各个服务对外都是以Restful API形式提供服务。再加上企业越来越多地使用云服务，各种云服务也提供了众多API。

这就导致企业拥有的API越来越多，那就当然需要有一个系统把这些API统一管理起来。同时，如果能够顺便把这些API的权限认证、安全审计等等机制也一并统一了，那就更好了，这样其它系统调用起来就方便多了。能管了以后，当然又会冒出来更多的想法。比如，能不能改一下原有API的格式内容？能不能把两个API合成一个API？能不能让一个API直接调用另一个API？能不能把这些API的调用自动化串起来？

简单来说，API管理就是解决以上这些问题的。我们来看看Gartner全生命周期API管理领域魔力象限，许多巨头都在里面。值得注意的是，Google之所以排名第一，是因为它在2016年用6.5亿美元收购了刚上市一年左右的Apigee。

3.5.2 API网关：微服务基础设施

全生命周期API管理里一个细分的领域是API网关（API Gateway），它是微服务1.0时代最重要的基础设施。

API网关顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，主要起到隔离外部访问与内部系统的作用，并处理常见的南北向流量。在微服务概念的流行之前，API网关的实体就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。

API网关的流行，源于近几年来，移动应用与企业间互联需求的兴起。移动应用、企业互联，使得后台服务支持的对象，从以前单一的Web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的标配组件。

API网关作为企业能力开放的一个门户，除了具备基本的请求转发、协议转换、路由等功能，以及高性能和高稳定性外，还需具备良好的扩展性，已便于网关能力的不断增强。在网关实施过程中，要规划好网关层与服务层的交互方式，尽量使得网关层与服务层解耦，便于各个团队工作的独立性。另外，在API的管理上，需要提供API全生命周期的发布、配置、鉴权、流控、监控等配套的管理功能。

API网关：微服务基础设施

例如Uber，在传统的单体架构遇到越来越大挑战的时候，决定改变自己的架构，效仿亚马逊、Netflix、Twitter等其他超级增长公司，将其整体架构拆分为多个代码库，以形成一个微服务架构。其主要变化是引入了API网关，所有的司机和乘客都是通过这个网关连接的。从API网关，所有的内部点都连接在一起，如乘客管理、司机管理、行程管理等。每个单元是单独的可部署单元，执行单独的功能。例如：如果你想在账单微服务中更改任何内容，那么只需部署账单微服务，而不必部署其他服务。所有的功能都是单独扩展的，即每个特征之间的相互依赖被移除。

API网关带来的的好处包括：

• 网关层对外部和内部进行了隔离，保障了后台服务的安全性

• 对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本

• 减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射

• 通过网关层聚合，减少外部访问的频次，提升访问效率

• 节约后端服务开发成本，减少上线风险

• 为服务熔断，灰度发布，线上测试提供简单方案。

• 便于扩展

3.6微服务2.0：服务网格与Serverless

3.6.1服务网格

微服务当前遇到的挑战包括：

• 技术门槛高：开发团队在实施微服务的过程中，除了基础的服务发现、配置中心和鉴权管理之外，团队在服务治理层面面临了诸多的挑战，包括负载均衡、熔断降级、灰度发布、故障切换、分布式跟踪等，这对开发团队提出了非常高的技术要求。

• 代码侵入性强：Spring Cloud、Dubbo等主流的微服务框架都对业务代码有一定的侵入性，技术升级替换成本高，导致开发团队配合意愿低，微服务落地困难。

为了解决上述问题，号称微服务2.0的服务网格（Service Mesh）应运而生。服务网格这个词最早由著名开源服务网格项目Linkerd所在的Buoyant公司CEO William Morgan所提出。按照他的定义，服务网格是一个软件基础设施层，用于控制和监视微服务应用程序中的内部、服务到服务的流量。

服务网格架构

Sidecar是服务网格中的核心组成部分，可以看到，上图中每一个微服务都配备了一个Sidecar。此时用户只需要关心业务逻辑，而不用关心服务治理等非业务功能，非业务功能都由Sidecar负责，接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流等功能从服务中抽离到Sidecar中。

服务网格和API网关是两个联系非常紧密的概念，它们的用途既不同，但是在某些方面又相互重叠。在某种程度上，我们可以认为服务网格是一个分布式的、微观层面的API网关，解决微服务服务发现、负债均衡、流量控制等需求。在具体用途上，API网关处理的是所谓南北向流量即内外部请求；而服务网格处理的是东西向流量即内部服务相互间的访问。

3.6.2 Serverless

Serverless（无服务器架构）这个概念在2012年时便已经存在，比微服务和服务网格的概念出现都要早，但是直到微服务概念大红大紫之后，Serverless才重新又被人们所关注。

Serverless是一种构建和管理基于微服务架构的完整流程，它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态、暂存的计算容器内。Serverless相关的重要概念包括FaaS（Functions as a Service，函数即服务）。开发者把函数上传到云厂商的FaaS平台，函数只在被请求时才实例化运行，然后被销毁，其它时候不占用任何服务器资源，完全实现按需使用，大幅度降低了服务器占用和成本。

Serverless通常适用于实时性要求不高、无状态的场景，例如突发事件处理、数据统计分析、视频解码、离线批量计算等等，像AWS FaaS平台Lambda限制用户功能必须在15分钟内完成。

相较服务网格，Serverless概念更为超前，虽然AWS Lambda、阿里云等许多平台都已经提供对其的支持，但是目前仍处于发展早期，无论是成熟项目数量和企业应用程度都相对有限。

FaaS Landscape

CNCF Serverless Landscape

3.7微服务 vs 宏服务：新的抉择

最近，Uber支付体验平台的工程经理Gergely Orosz发布推文表示他们的架构方向已经发生了变化。“声明一下，在Uber，我们正将许多微服务转移到@copyconstruct所称的Macroservices宏服务（大小适中的服务）。确切地说，B/C测试和维护成千上万的微服务不仅很难——它可能会带来更多的长期麻烦，而不是解决短期问题。”

微服务确实可以帮助团队在早期快速推进。等你意识到服务越少越好时，已为时已晚。你需要解决很多服务的“困难”部分。我们在不断增加更多的服务，但也在停止使用服务，并且会更慎重的思考新的服务。

微服务的理念不同的团队有不同的实践，例如微服务如何拆分、组织架构如何搭建、技术栈如何选择。

我们理解，微服务是云原生的核心，后面要介绍到的容器（Docker）和Kubernetes是实现的技术方法和手段，DevOps是配合的文化和研发流程，但是微服务带来的启发，更多是思维方式上的转变。

四、容器与Docker

4.1虚拟化与容器

在容器技术之前，业界的网红是虚拟机。虚拟机技术的代表是VMWare和OpenStack，我在虚拟化与超融合系列里做过介绍。很多人都用过虚拟机，就是在操作系统里安装一个软件，然后通过这个软件，再模拟一台甚至多台“子电脑”出来。在“子电脑”里，可以和正常电脑一样运行程序，例如微信、Word。“子电脑”和“子电脑”之间，相互隔离互不影响。

虚拟机虽然可以隔离出很多“子电脑”，但占用空间大，启动慢，虚拟机软件可能还要花钱（例如VMWare）。而容器技术恰好没有这些缺点，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”），启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个Docker容器）。此外它占的空间很小，虚拟机一般要几GB到几十GB的空间，而容器只需要MB级甚至KB级。虚拟机和以Docker为代表的容器都是虚拟化技术，不过容器属于轻量级的虚拟化。下面是两者的主要对比。

4.2 Docker的源起

我们再来看看Docker，Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。虽然Docker 把容器技术推向了巅峰，但容器技术却不是Docker发明的。实际上，容器技术连新技术都算不上，因为它的诞生和使用有些年头了，像最早的容器LXC发布于2008年。

Docker本来是做PaaS的公司，原来叫做DotCloud，成立于2010年。但比起Pivotal、Red Hat等著名企业，DotCloud运营并不成功。眼看就要失败的时候，2013年DotCloud决定开源自己的容器项目Docker。但是短短几个月，Docker迅速崛起，吸引大量的开发者使用。随着Docker在开发者中越来越流行，2013年10月，DotCloud公司正式更名为Docker，2014年8月，Docker 宣布把PaaS业务出售，开始专心致志做Docker。

Docker一词意为码头工人，而它的logo则是一个托着许多集装箱的鲸鱼，非常形象：Docker是鲸鱼，而集装箱则是一个个的容器。在Docker的官网上，对于容器有一个一句话的解释“A standardized unit of software”，即“软件的一个标准化单元”。

下面的图片比较了Docker和传统虚拟化的不同之处，容器是在操作系统层面上实现虚拟化，而传统方式是在硬件层面实现，所以导致两者的特性有很大区别，Docker更小更轻。

Docker vs 虚拟化

而Docker与传统的Linux容器也并不完全一致。Docker技术最初是建立在LXC技术之上的，大多数人都把LXC技术与传统的Linux容器联系在一起，尽管后来它已经摆脱了这种依赖性。LXC作为轻量级虚拟化很有用，但它没有很好的开发人员或用户体验。Docker技术带来的不仅仅是运行容器的能力，它还简化了创建和构建容器、加载镜像和镜像版本控制等过程。传统的Linux容器使用可以管理多个进程的init系统，这意味着整个应用可以作为一个整体运行。Docker鼓励将应用程序分解为它们各自的进程，并提供了实现这一点的工具，这种粒度有不少优点。

4.3 Docker解决的问题

众所周知，Linux上我们不愉快的经历之一就是安装软件。因为系统硬件、操作系统环境不一样，软件包有不同的依赖性，所以必须要安装完软件依赖路径上的所有包，这个链条之长，往往要耗费几小时甚至几天的时间。例如下面的案例，我要安装Docker，系统提示我必须要先安装selinux-policy、selinux-policy-base、selinux-policy-targeted三个相关模块。

这就是由于环境不统一带来的巨大问题，每天在世界各地的数千万台机器上都会重复上演无数次。那么，如果服务器环境能够标准化，那我们安装任何软件只需要一个版本就可以解决问题。

同时，如果所有服务器环境统一、标准化，还能保留上面的配置、安装的软件和应用，对于我们来讲就更加有用。Docker正是在操作系统之上实现了这个标准化、统一化的运行环境，并且把各种不同的配置和应用存储成镜像，供未来使用。这有点类似于我们熟悉的Ghost或者虚拟光驱，把需要的环境和状态保留为镜像，随时恢复、随时使用。

不过Ghost基于操作系统，镜像是一个大文件，管理起来并不方便，恢复速度也很慢，同时不支持跨平台的镜像恢复；而虚拟光驱则是基于软件层面，使用范围有限；而Docker正处于两者之间，能完成更多功能的同时，还实现了镜像的快速加载和运行。

我们在上一部分讲微服务的时候，将其比喻成装配式建筑。把这个比喻用在Docker上的话，我们只要提前设计好模板（配置环境、部署软件或服务），就能在工厂（Docker）里批量化生产（说复制可能更加合适）出楼板、墙板、楼梯、阳台等构件和配件（容器所装载的、不同的微服务），这些构件在建筑施工现场经过组装拼合（API访问），就能成为各种各样的建筑（各种类型的产品和应用）。

装配式建筑由各种构件组成

Docker与各种概念的关系

所以，Docker曾经有一句Slogan叫做“Build once，Run anywhere（搭建一次，随处可用）”。

4.4 Docker的核心概念

Docker技术的三大核心概念，分别是：

• 镜像（Image）

• 容器（Container）

• 仓库（Repository）

上面的例子里，设计出来的模板就是Docker镜像，生产（复制）出来的构件就是Docker容器，而Docker仓库则是集中放置管理Docker镜像的地方。

Docker镜像是一个特殊的文件系统。它除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的配置参数（例如环境变量）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

每一种模板（镜像）能够创建出一种构件，但是模板可以由不同的设计师来设计，提供不同用途、不同风格，例如斜顶式阳台、嵌入式阳台、包豪斯风格、蒙德里安风格等等，所有人相互之间可以共享，这就形成了大的公共仓库。

Docker官方提供了Docker Hub（https://hub.docker.com）来维护管理所有的镜像，只是对于免费用户而言,只能创建一个私有仓库。Docker Hub里提供了大量高质量的官方镜像，例如Oracle、MySQL、redis、Ubuntu、Nginx、python、Docker（Docker in Docker！）等等，开发人员需要一个环境的时候，可以直接到Docker镜像仓库去查找，减少了大量无谓的环境安装工作。

4.5 Docker的好处

Docker给我们带来的好处非常多，下面简单列举几点：

4.5.1更高效的利用系统资源

有了Docker，我们可以在一台服务器上运行很多应用，充分利用硬件资源。例如现在我们有一台Linux服务器，可以构建不同版本的Ubuntu镜像启动，并且为不同的用户分配不同的容器。这样用一台服务器就能虚拟出许多运行不同操作系统的虚拟服务器，而对于用户来说，这些都是透明的。许多公有云采用了容器技术为用户提供服务，所以虚拟化与容器共同成为了现代云计算的基石。

4.5.2更快速的启动时间

传统的虚拟机技术启动应用服务往往需要数分钟，而Docker容器应用，由于直接运行于宿主内核，无须启动完整的操作系统，因此可以做到秒级甚至毫秒级的启动时间，大大的节约了开发、测试、部署的时间。

4.5.3保证环境一致性

开发过程中常见的问题之一是环境一致性问题，由于开发环境、测试环境、生产环境不一致，导致有些bug并未在开发过程中被发现，而Docker的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，再也不会有在线下开发环境中运行正常，而部署到线上有各种错误的情况了。

4.5.4持续交付和部署

对于开发和运维人员来说，最希望的是一次创建或配置，可以在任意地方正常运行。开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接使用这个容器来部署代码，无论在多少台服务器中部署都是如此。Docker可以快速创建容器，快速迭代应用程序，并让整个过程全程可见。

4.5.6更轻松的迁移

由于Docker确保了执行环境的一致性，使得应用的迁移更加容易，Docker可以在很多平台上运行，无论是物理机、虚拟机、公有云、私有云，其运行结果是一致的，因此用户可以很轻易的将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。

4.5.7提升复用性，降低耦合性，维护和扩展更轻松

Docker使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。安装Docker后，我们可以从Docker Hub上获取各种各样的操作系统镜像，这个操作很简单，只需要拉取相应的镜像到本地然后运行即可。另外我们可以将数据库、Web服务器、缓存服务器运行在不同的容器中，降低了各个服务之间的耦合性、便于扩展，Docker Hub上有各种各样的优秀镜像，我们可以直接拿来使用，不需要自己搭建，应用的部署就像搭积木一样简单。

4.5.8实现沙盒机制，提高了安全性

由于应用运行在容器中，与操作系统隔离开，从而使操作系统基本不可能受到破坏。另外如果应用因为攻击而瘫痪，并不需要重启服务器，直接重启容器或者再启动一个镜像就可以了。

4.6容器与微服务

容器是微服务和云原生架构的最佳实现载体。微服务与容器几乎是完美的搭配。单体式架构（Monolithic）变成微服务架构（Microservices），相当于一个全能型变成N个专能型，每个专能型分配一个隔离的容器，赋予了最大程度的灵活。

服务器势必会走上虚拟化的道路，因为虚拟化有太多的优势，例如前文所说的低成本、高利用率、充分灵活、动态调度等等。而采用容器之后，只需要一台服务器，创建十几个容器，用不同的容器，来分别运行不同用途的服务程序。这些容器，随时可以创建，也可以随时销毁。还能够在不停机的情况下，随意变大，随意变小，随意变强，随意变弱，在性能和功耗之间动态平衡。所以容器化是云计算的终极形态。

如果把传统IT架构比作传统工厂，容器化比作现代化工厂，那么下一部分我们要讲到的Kubernetes则会将现代化工厂进一步提升为智能化无人工厂。那么当Docker遇到Kubernetes之后将会发生什么有趣的事情？让我们拭目以待。

五、Kubernetes与容器编排之战

5.1容器编排与Kubernetes

在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势。所以企业需要一套管理系统，对Docker及容器进行更高级更灵活的管理，按照用户的意愿和整个系统的规则，完全自动化的处理好容器之间的各种关系，这叫做编排（Orchestration）。

Orchestration这个词来自于音乐领域，是指一种将不同乐器、音色加以合理的编排等手法营造出一个听感交融、平衡的艺术，它完美地描述了容器编排的含义：为单个应用程序（乐队中的每种乐器）提供协同工作的模式。

在IT领域编排可以理解为一种工作流，它能把整个IT系统都串接起来，然后自动化运作。在云原生时代，整体式的应用早已成为过去时，应用一般由单独容器化的组件即微服务组成，而这些组件需要通过相互间的协同合作，才能使既定的应用按照设计运作。

2014年6月，IT基础设施领域的领先者Google发布了Kubernetes（简写为K8S）。编排概念并不是由Kubernetes第一个提出的，Kubernetes这个单词来自于希腊语，含义是舵手或领航员。

Kubernetes是基于Docker的开源容器集群管理系统，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，因为容器本身可移植，所以Kubernetes容器集群能跑在私有云、公有云或者混合云上。

Kubernetes属于主从的分布式集群架构，包含Master和Nodes。Master作为控制节点，调度管理整个系统；Nodes是运行节点，负责运行应用。Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（Container）、存储资源（Volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。

Kubernetes的主要功能包括：

• 资源调度：资源调度是一套分布式系统最基本的核心指标

• 资源管理：控制Pod对计算资源、网络资源、存储资源的使用

• 服务发现：管理外在的程序或者内部的程序如何访问Kubernetes里面的某个Pod

• 健康检查：监控检测服务是否正常运行非常重要

• 自动伸缩：因为涉及到环境的快速迁移和复制，虚拟机时代之前都非常难实现。容器化时代很自然的解决了这个问题，Kubernetes保证了资源的按需扩容

• 更新升级：Kubernetes为服务的滚动和平滑升级提供了很好的机制

5.2容器编排之战

意识到容器编排的重要性，Docker在2014年发布了Docker Swarm（Swarm是蜂群的意思），以一个整体来对外提供集群管理功能，最大的亮点就是全部使用Docker项目原来的容器管理API来完成集群管理。

同时从2014年底开始，Docker收购了最先提出容器编排概念的Fig项目，并改名为Compose（Compose是作曲的意思），它可以用来组装多容器的应用，并在Swarm集群中部署分布式应用。

2014年Kubernetes发布之后，为了与Swarm竞争，在容器编排地位取得绝对的优势，Google、RedHat等开源基础设施公司共同发起了CNCF基金会，希望以Kubernetes为基础，建立一个由开源基础设施领域厂商主导、按照独立基金会方式运营的平台社区，来对抗以Docker公司为核心的容器商业生态。

一方面Kubernetes脱胎于Google内部久负盛名的大规模集群管理系统Borg，是Google在容器化基础设施领域十余年实践经验的沉淀和升华，Google利用Kubernetes的架构和设计思想成功将其所有应用（搜索、地图、视频、金融、社交、人工智能）运行在超过100万台服务器、超过80个数据中心，每周的20亿个容器上，所以Kubernetes是唯一具有超过10年以上大规模容器生产使用的技术经验和积淀的开源项目。

并且Kubernetes采用了非常优雅的软件工程设计和开源开放的态度，使得用户可以根据自己的使用场景、通过灵活插拔的方式，采用自定义的网络、存储、调度、监控、日志等模块，所以在Github上的各项指标一路飙升，将较为简单、并且生态自闭的Swarm项目远远地甩在了后边。CNCF社区也迅速增加了一系列容器生态的知名工具和项目，大量的公司和初创团队将注意力投向CNCF社区而不再是Docker，CNCF本质上成为了以Kubernetes为核心的生态系统。

企业服务大厂也纷纷加入Kubernetes平台战局，在公有云或者私有PaaS平台上来发展自己的Kubernetes产品。像微软直接找来Kubernetes联合创始人Brendan Burns负责领导Azure容器服务团队，自身的混合云产品Azure Stack也大力支持Kubernetes。

IBM同样也靠以Kubernetes为核心的PaaS软件IBM Cloud Private来抢占企业私有云容器平台市场，尤其是微服务的管理需求。很早就支持Kubernetes的Redhat，在2015年推出的OpenShift 3.0版中，不惜放弃自己的容器调度工具，开始支持Kubernetes，现在更成为了支持跨多云、混合云架构，以及裸机、容器和虚拟机的企业级通用应用管理平台。而虚拟化龙头VMware也改为力推主打通吃多家IaaS和Kubernetes集群管理的容器服务软件，甲骨文也在旗下云端服务支持Kubernetes。

在用户、社区和大厂的支持中，Kubernetes逐步成为企业基础架构的部署标准和新一代的应用服务层。

2016年，面对CNCF的竞争优势，Docker公司宣布放弃现有的Swarm项目，将容器编排和集群管理功能转到Docker项目当中。然而这种改变带来的技术复杂度和维护难度，给Docker项目造成了非常不利的局面。不同于Docker，Kubernetes推进的民主化架构从API到容器运行的每一层，都给开发者暴露出了可扩展的插件机制，鼓励用户通过代码的方式介入每一个阶段。Kubernetes的变革非常有效，很快在整个容器社区中催生出了大量的、基于Kubernetes API和扩展接口的二次创新产品，例如前文提到的Istio等等。Docker公司在Kubernetes社区崛起和壮大后，败下阵来。

2017年，Docker公司将容器运行时部分Containerd捐献给CNCF社区，并在自己主打产品Docker企业版中内置Kubernetes项目，持续了两年的容器编排之争终于落下帷幕，Kubernetes成为了最后的胜利者，而Docker输掉了最关键的一仗，失去了成为云原生时代操作系统的机会。

Docker在最重要的容器编排之战中失败，带给我们的教训包括：

• 开源不等于免费，开源是一种商业模式，一个开源组织和开源项目要想生存下去，最重要的基础就是普遍被使用，不然很快就会被竞争者替代

• 开源技术终将走向商业，包括Docker，必然面临企业市场的挑战

• Docker进入企业级市场，有优势也有劣势，优势是挟Docker的大量开发者，劣势是没有做过企业级市场，开发者市场和企业级市场的做法完全不同

• Docker在竞争中失利，看起来是时机和生态构建的问题，但归根结底是基因和能力问题

六、思考与机会

每一次IT产业架构的变革都会带来巨大的机遇和行业洗牌的挑战。过去的三四十年间，IT业经历了多次重大的变革，包括20世纪七八十年代从大型机向小型机的转移、九十年代C/S架构的普及，以及21世纪初互联网的兴起，先后造就了IBM、思科、惠普、Oracle、EMC、SAP等巨头企业。

历次IT技术革命还有个共同特点：无论原有的基础软硬件公司此前有多么牢不可破的垄断地位，一旦不能符合新的IT技术变革的趋势，洗牌在所难免。

现代云计算的浪潮开始于2000年以后，已经造就了VMware、ServiceNow、Salesforce、Shopify等数百亿美金的明星企业，以及无数的独角兽公司。

云计算是通过互联网的方式按需交付基础设施（硬件/服务器）、存储、数据库和各种应用服务，通常这些服务是由AWS、Azure等公有云或者私有云平台提供的。

而云原生是一种理念和架构，用于以针对云环境优化的方式组装上述所有基于云的组件。因此云原生也是一个目的地：对于那些希望实现基础设施和流程现代化，甚至组织文化现代化的企业来说，最终的目标是仔细选择最适合其具体情况的云技术。

要从云计算中获得最佳效果，需要使用云原生架构；云原生的普及又会促进云计算的加速发展。

从统计数据和发展趋势来看，云原生被接受的程度和普及速度正在大大加快，例如下图显示，自从2016年以来容器的使用量每年都在快速上升。IDC预计，到2022年90%的应用程序将采用微服务架构和第三方代码，35%的生产应用程序将诞生于云端。

由于容器和敏捷方法的采用，预计2018-2023年间将诞生5亿个新应用程序。由数字化转型，以及接受和采用新技术的需求驱动，云原生将更深入地渗透到大型企业组织中。这意味着云原生技术和方法可能会遵循敏捷和DevOps的模式，越来越多地吸引更多的利益相关者，包括管理者和业务线领导人，在未来几年内覆盖一半或更多的组织。

各种场景容器使用量都在逐步上升

但目前不是所有的云计算技术和产品都能很好的满足云原生架构分布式、自动化、轻量化的要求，传统的IT基础设施正在受到越来越大的冲击，例如传统集中式数据库正在逐渐被分布式数据库所取代，虚拟机技术受到了容器的巨大冲击，分布式监控系统完全替代了传统的监控产品，而传统的安全产品也远远无法满足云原生安全性的要求。

还需要注意的是，云原生的概念不仅仅只意味着容器、Kubernetes或Serverless，也为下一项技术留下了足够的空间。