今天我们不讲行业和商业，讲讲2019年最热的概念——云原生（Cloud Native）。
我认为云原生是未来10年IT发展最重要的趋势，但是它涵盖的概念非常多，需要花很多时间研究，同时浩如烟海的资料分散在网络上各个地方，缺乏系统性的梳理。今年2月我在基金内部做过一个分享，今日成文，希望让更多的人有所了解。
本文试图解答：
- 为什么云原生概念具有革命性？
- 什么是微服务？
- 微服务和中台的关系
- 容器和微服务为什么是最佳搭档？
- 容器化与虚拟化的区别
- API管理与API集成的区别
- Kubernetes是做什么用的？
- 开源软件商业化遇到的典型问题是什么？
涉及到的概念包括云原生、DevOps、持续集成、持续交付、持续部署、微服务、API管理、iPaaS、Service Mesh、Serverless、容器、Docker、Kubernetes等等，我争取用比较形象和通俗的方式把这些技术概念讲清楚。
本文内容较多，共分为六个章节。
- 第一部分：云原生及CNCF基金会
- 第二部分：DevOps与CI/CD
- 第三部分：微服务、API管理与集成
- 第四部分：容器与Docker
- 第五部分：Kubernetes与容器编排之战
- 第六部分：思考与机会
第一部分：云原生及CNCF基金会
从集装箱革命说起
有一本非常有名的书，叫《集装箱改变世界》，说的是看起来平淡无奇的铁箱子，如何从二十世纪起永久性的改变了这个世界，并促进了全球化和全球分工。集装箱的出现和发展是实体货物包装、运输、交付方式的一次革命。
《经济学家》杂志曾经评价说“没有集装箱，不可能有全球化”。集装箱为什么具有革命性？
经济全球化的基础就是现代运输体系,而一个高度自动化、低成本和低复杂性的货物运输系统的核心就是集装箱。集装箱最大的成功在于其产品的标准化及由此建立的一整套运输体系。能够让一个载重几十吨的庞然大物实现标准化，并且以此为基础逐步实现全球范围内的船舶、港口、航线、公路、中转站、桥梁、隧道、多试联运相配套的物流系统，这的确堪称人类有史以来创造的伟大奇迹之一，而撬动这个系统的理念就是标准化和系统化。
改变世界的不仅仅是集装箱本身，还有一整套货物处理的新方法，包括港口、货船、起重机、卡车，还有发货人的自身操作方式等。
云原生在IT领域的意义非常类似于集装箱，只是里面装载的不再是实体货物，而是虚拟世界的二进制代码和软件。我们将在介绍完众多概念之后再来对应解释。
云原生的诞生
随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。
云原生的发展史，来自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.”——云原生是一种构建和运行充分利用云计算模型优势的应用程序的方法。
CNCF云原生计算基金会如此定义云原生：
“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格（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.”
——云原生计算使用的开源技术栈包括：
- 容器化。每个部分（应用、流程等等）都打包在自己的容器中，这有助于提升复用性、透明度以及改善资源隔离。
- 动态编排。容器受到有效的调度和管理，以便优化资源利用。
- 以微服务为导向。应用被分割到不同的微服务中，这种分割可以显著的提高应用的整体敏捷性和可维护性。
我个人理解，云原生是指从云的原生应用角度出发，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。
下表列举了云原生应用和传统应用的有哪些主要区别。
要转向云原生应用需要以新的云原生方法开展工作，云原生有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
云原生的发展脉络
云原生背后的价值主张有哪些？
- 隔离性：把应用程序打包在容器中加快了代码和组件的重用，并且简化了操作；
- 无锁定：开源软件栈支持在任何公共或私有云上或以组合方式进行部署；
- 无限扩展：为能够扩展到数万个自修复多租户节点的现代分布式系统环境而优化；
- 灵活性和可维护性：将应用程序拆分为具有明确描述的依赖关系的微服务；
- 提高效率和资源利用率：动态管理和调度微服务的中央编排流程降低了与维护和操作相关的成本；
- 应用的弹性：以应对单个容器甚至数据中心的故障，以及不同级别的需求
2019年，Gartner曾经发布报告表示云原生时代已经到来，在未来三年中将有75%的全球化企业将在生产中使用容器化的应用。
请注意，云原生相关技术不仅仅能用于云计算，即便是和云计算即对立又协同的边缘计算，微服务、容器、Kubernetes依然是事实上的杀手应用和标准。如由著名的Kubernetes管理平台创业公司Rancher所贡献的K3s项目，就是Kubernetes（K8s）的最轻量级版本，以满足边缘计算和IOT环境中，在x86、ARM64和ARMv7处理器上运行小型、易于管理的Kubernetes集群日益增长的需求。
云原生计算基金会CNCF
提到云原生，就不能不介绍云原生计算基金会CNCF（Cloud Native Computing Foundation）（https://www.cncf.io）。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）中列出的产品或服务进行选择。
CNCF全景图则列举了和云原生相关的产品及服务的完整名单，这1381个项目共同构成了恢弘庞大的云原生世界。整个全景图按照功能分为29个模块，分别归属于9种大的类别（应用定义与开发、编排与管理、运行时、配置、平台、可观察性与分析、Serverless、会员和其它）。值得注意的是其中专门有一种分类是Cards from China，列举了来自中国的145个项目，其中不乏许多大家耳熟能详的知名项目，可惜的是数据并不完整。感兴趣的朋友可以自行研究。
从CNCF的理念及野心来看，基于云原生的基础设施正在壮大和蚕食非云的市场，未来极有可能成为整个IT生态事实上的意见领袖和领导者。
云原生涵盖的主要概念
上面提到云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。另外一种比较主流的说法是云原生=微服务+DevOps+持续交付+容器化，广泛的见诸于各种文章和资料。
在接下来的《云原生时代》系列报告中，我们将依照这些概念，分成DevOps与CI/CD；微服务、API管理与集成；容器与Docker；Kubernetes与容器编排之战四个部分全面介绍云原生各个组成部分。
第二部分：DevOps与CI/CD
DevOps
DevOps（Development & Operations，开发和运维）是09年提出来的概念，但一直没有太火。直到14年，容器与微服务架构的提出，DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。
对于DevOps，微服务不是必须的，但微服务为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。所以，也有人称微服务是DevOps架构。
DevOps流程示意图
DevOps与下面提到的CI、CD不同，DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。DevOps的概念似乎与持续交付的概念有些类似，两者均旨在促进开发与运维之间的协作，但是实际上两者差别很大：DevOps 更偏向于一种文化的构建，在DevOps文化指导下，团队中将包含了具有不同技能的人员（开发、测试等），并通过自动化测试与发布的手段，更快、更高质量的生产软件。
持续集成
持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。
持续集成流程示意图
持续集成带来的好处是：
- 易于定位错误
- 易于控制开发流程
- 易于Code Review
- 易于减少不必要的工作
持续交付
与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。
持续交付流程示意图
持续交付带来的好处是：
- 繁琐的部署工作没有了。团队不再需要花费几天的时间去准备一个发布
- 可以更快的进行交付，这样就加快了与客户之间的反馈环
- 轻松应对小变更，加速迭代
持续部署
持续部署（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。
持续部署流程示意图
持续部署带来的好处是：
- 发布频率更快，因为不需要停下来等待发布。每一处提交都会自动触发发布流
- 在小批量发布的时候，风险降低了，发现问题可以很轻松的修复
- 客户每天都可以看到持续改进和提升，而不是每个月或者每季度，或者每年
自动实时的部署上线，是最优的解决办法，但持续部署的要求是团队非常成熟，并且上线前是需要经过QA测试的，所以实际情况下很难实现，一般的团队也很难接受，挑战和风险都很大。
我们总结下，DevOps、持续集成、持续交付、持续部署并不是某种技术栈或者框架，而是开发文化、流程、理念和操作方式。下一部分，我们将介绍云原生最重要的概念之一：微服务。
第三部分：微服务、API管理与集成
什么是微服务
微服务（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（面向服务的架构）
- 松：松耦合，可以独立部署。每个微服务可以独立编译、独立部署、独立运行
微服务采用独立的数据库服务，数据去中心化
微服务运行在独立的进程中，部署去中心化
微服务架构的好处是：
- 易于开发与维护：微服务相对小，易于理解
- 独立部署：一个微服务的修改不需要协调其它服务
- 伸缩性强：每个服务都可按硬件资源的需求进行独立扩容
- 与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力
- 技术异构性：使用最适合该服务的技术，降低尝试新技术的成本
- 企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡
微服务的实践有两个重要问题：什么时候选择微服务架构，以及颗粒度如何拆分，与经验和实际情况息息相关。
上图来自Martin Fowler另一篇叫《微服务进阶》的文章，揭示了生产率和复杂度的一个关系。在复杂度较小时采用单体应用的生产率更高，复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化的拆分才是合算的。
我个人建议是除非在可见的将来，复杂度都不会显著提高的情况下，才选择单体应用，否则其它时候都应提前为微服务架构做好设计和准备。
微服务基础设施及案例
下图是一个典型的微服务技术架构图。
微服务架构最常见、最广泛使用的框架是基于Java的Spring Cloud（集成了上图里的Netflix OSS技术栈），提供了服务发现、负载均衡、故障转移、动态扩展和数据分区等功能，已经成为微服务的最佳实践。
但是Spring Cloud构建在Java虚拟机之上，不能满足高并发下的性能要求，所以许多开源产品层出不穷，其中也包括中国互联网企业所贡献的微服务框架，例如华为的ServiceComb、阿里的Dubbo等等。
下面我们举一个例子。传统的电商的技术架构如下图所示，这是一个单体应用。
所带来的常见问题包括：
- 不同客户端产品之间，例如小程序、App、网站端有许多相同业务逻辑的重复代码，每个产品都要各自维护一份代码，修改的时候所有地方要一起修改。
- 单个应用经常需要给其他应用提供接口，渐渐地越来越复杂，包含了很多本来不属于它的逻辑，代码变得臃肿，功能边界模糊。
- 系统代码耦合性高，相互之间逻辑复杂，一旦出现开发离职的情况，继任者需要花很长时间review代码，才有可能搞清楚整体架构和逻辑关系。
- 多个应用使用一个数据库，依赖性严重，很难重构和优化。所有应用都在一个数据库上操作，数据库很容易出现性能瓶颈。同时数据库成为单点，出现意外整个系统都会受到影响。
- 即使只改动一个小功能，也需要整个应用一起发布，发布流程繁琐、上线时间长。并且很容易出现一个小bug影响整个系统，每次发布都是胆战心惊，很容易出现开发、运维和测试之间的矛盾。
下面我们用微服务重构整个系统：
改造之后，去除了大量冗余代码，系统复用性得到提升；不同的团队专注于不同的微服务，代码和工程质量得到保证；数据库不再存在单点问题，系统健壮性得以提升；前后端分离，业务逻辑更加清晰；降低了系统耦合性，不同的微服务可以分开部署上线，相互之间并不影响。
组织挑战、康威定律与蜂群理论
请注意，微服务理念不仅反映了技术架构的变化，也反映了组织内部沟通结构为了应对更加灵活、快速、碎片化的需求和环境而变化的结果。例如液态组织就是组织形态应对当前市场环境快速变化的一种输出形式，但实际应该如何构建？
曾经有一张非常有名的组织架构图，如下图所示。
对一家企业来说，能一步步不断发展壮大，进入一个领域就能迅速突破，这其中的根本核心必然是组织模式。在粗放发展的年代，很少有企业强调内部效率，组织模式绝大部分都类似单体应用，按照职能划分的方式进行管理，从而创造了无数的烟囱/谷仓。
单体架构和职能型组织模式相似
一张著名的图：技术组织造就了难以逾越的谷仓
我在我的知识星球里提出过企业级产品设计所面临的重要挑战，其中一个问题是：
- 版本。企业级产品现在经常涉及多个平台和不同的版本，例如Web、PC、App、钉钉、企业微信、微信小程序、飞书的版本等等，第一会面临重复开发的问题，第二业务逻辑非常复杂，很容易造成产品逻辑和体验的不统一，以及不同版本产品之间逻辑的缺失。例如登录和注册微信小程序可能用的是手机号，而通过邮件注册需要使用的却是邮箱。如何设计一套比较好的产品流程和组织架构，来保证统一完善的产品逻辑及用户体验？
是的，这不仅仅是产品和技术问题，还是组织问题。现在越来越多的企业意识到了最大的挑战在于组织内部，无论是增长黑客还是MVP的理念都需要快速灵活的机制来配合。为什么有的组织效率高、能力强，能及时响应客户的需求和环境变化？
新的组织设计理念认为传统的烟囱形式会成为创建有效增长和盈利途径的障碍，需要解构组织孤岛，采用跨职能组织的形式以支持增长。企业组织设计是非常专业的领域，有许多文章讨论，例如《战胜组织孤岛的战略之路》，本文不延伸讨论。
职能组织与跨职能组织
我们可以看到单体应用和职能组织，微服务与跨职能组织，在形式上是高度相似的，这引申出微服务背后的理论基础。
“当希望把一个大型应用拆分成多个部分时，管理层通常将重点放在技术层面。而如果组织架构还按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），因此得以推广。
只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四项：
- 第一定律 组织沟通方式会通过系统设计表达出来（Communication dictates design）
- 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情（There is never enough time to do something right, but there is always enough time to do it over）
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性（There is a homomorphism from the linear graph of a system to the linear graph of its design organization）
- 第四定律 大的系统组织总是比小系统更倾向于分解（The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems）
例如微服务的团队间应该是inter-operate，not integrate（互操作、不集成）。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本也就能减低。
康威定律可以上升到哲学的高度进行讨论，但是过于复杂。简言之，微服务架构与组织模式互相决定和影响，协同才能发挥出最大价值。
跨职能组织-微服务架构/团队边界强化服务边界
凯文·凯利在《失控》中提出了著名的“蜂群理论”，利用蜂巢思维比喻人类的协作带来的群体智慧：依靠成千上万个发条一起驱动一个并行的系统，进行生产，进行自维持。蜂巢思维就是“群体思维”（Collective consciousness）。作为“超级有机体”的蜂群，被称为“分布式系统”，是以生物逻辑建立起来的群集模型。由此形成的蜂巢思维这四个理念至关重要：
微服务理念对应的组织模式包括蜂巢型组织，它具有突出的稳定性和抗弯曲能力，特点是：
- 跨组织：它不一定是一个独立的法人实体，而是为了特定目标或项目形成的联盟
- 相对统一：蜂巢组织不是一成不变的，当市场需求或组织目标发生变化时立即变化
- 分享性：它改变了传统的等级分明的金字塔结构，允许信息横向传递与交流，使信息利用更为充分及时
在这样一个以蜂巢为理念搭建的企业圈层里面，各个独立团队能够得到更好的协助与支撑，不断扩大视野，提高眼界，掌握话语权，团队成员也会更有归属感。这样的团队乃至蜂巢本身，也一定会更有活力和变革力，更加能适应市场的变化。蜂巢型组织有四个突出特点，所谓活系统的特质也正是由此而来：没有强制性的中心控制；次级单位具有自治的特质；次级单位之间彼此高度连接；点对点间的影响通过网络形成了非线性因果关系。
微服务：筑巢
蜂巢型组织的典型案例之一是华为。除了组织架构去中心化的管理模式之外，华为的著名的轮值CEO制度正是由此而来，华为有三位轮值CEO，每六个月轮换一次，这体现了依靠集体民主决策而非一人独裁的理念。
再例如国美蜂巢式组织变革的实践是将由四个大区管辖54个分公司，调整为七个大区直接管辖200家分公司的结构，即将原来二级市场里的146家分公司独立出来，直接划归大区管辖，而原来四个大区变成七个大区。实践证明，组织扁平化是国美提升供应链效率，提升消费者消费体验的重要战略。
国外著名的代表案例是微服务先驱Netflix。Netflix是一家技术强大的互联网公司，但是它却没有CTO职位，产品团队和技术团队(包括UI前端工程团队、Discovery搜索工程团队和Platform平台团队等)全部汇报首席产品CPO，产品驱动是该公司的核心文化要素之一，Netflix称其为BusDevOps组织架构。
Netflix：BusDevOps组织
在整个系列第二部分中，我们介绍了DevOps，现在我们可以理解，DevOps是配合微服务的理念组织构建团队协作的方式，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。全部业务、研发和运维围绕产品开展工作，统一目标，大家都是产品驱动，分别服务于内外不同客户，避免技术驱动 vs 业务驱动的陷阱。
传统水平组织 vs DevOps驱动的垂直组织
在某些文章中，认为微服务的切割应该按照组织架构来划分，我反而觉得应该按微服务的分割方式来划分组织架构，因为归根结底，组织架构应该为业务服务，而不是业务为组织服务，组织需要贯彻执行微服务的理念，就必须由微服务驱动组织业务的不断迭代演进。
微服务与中台
可能有人会问，中台的目标不也是为了解决企业内部业务系统烟囱林立，数据孤岛严重，各自为战，缺乏复用性，所以要充分提取业务共性，从而及时应对需求变化，听起来和微服务的目标和理念非常相似，那它们之间有什么异同呢？
阿里巴巴中台战略架构图
来自阿里官方的定义，“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”
中台架构，简单地说，就是企业级能力的复用，一种方法论，企业治理思想。
微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。
所以中台并不是微服务，中台是一种企业治理思想和方法论，偏向于宏观，微服务是技术架构方式，偏向于微观。而中台化的落地，离不开使用微服务架构。
中台强调核心基础能力的建设，基础能力以原子服务的形式来建设，并通过将原子服务产品化，支撑业务端各种场景的快速迭代和创新；原子服务和微服务所倡导的服务自闭环思想不谋而合，使得微服务成为实现原子服务的合适架构。
支撑业务场景的应用也是通过服务来实现，其生命周期随业务变化需要非常灵活的调整，这也和微服务强调的快速迭代高度一致，所以业务应用服务也适合通过微服务来实现。
API管理与API集成
下面我们讲讲微服务相关的两个具体领域，API管理与API集成。
1、全生命周期API管理
上文提到微服务各个服务对外都是以Restful API形式提供服务。再加上企业越来越多地使用云服务，各种云服务也提供了众多API。
这就导致企业拥有的API越来越多，那就当然需要有一个系统把这些API统一管理起来。同时，如果能够顺便把这些API的权限认证、安全审计等等机制也一并统一了，那就更好了，这样其它系统调用起来就方便多了。能管了以后，当然又会冒出来更多的想法。比如，能不能改一下原有API的格式内容？能不能把两个API合成一个API？能不能让一个API直接调用另一个API？能不能把这些API的调用自动化串起来？
简单来说，API管理就是解决以上这些问题的。我们来看看Gartner全生命周期API管理领域魔力象限，许多巨头都在里面。值得注意的是，Google之所以排名第一，是因为它在2016年用6.5亿美元收购了刚上市一年左右的Apigee。
2019年全生命周期API管理魔力象限
2、API网关：微服务基础设施
全生命周期API管理里一个细分的领域是API网关（API Gateway），它是微服务1.0时代最重要的基础设施。
API网关顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，主要起到隔离外部访问与内部系统的作用，并处理常见的南北向流量。在微服务概念的流行之前，API网关的实体就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。
API网关的流行，源于近几年来，移动应用与企业间互联需求的兴起。移动应用、企业互联，使得后台服务支持的对象，从以前单一的Web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的标配组件。
API网关作为企业能力开放的一个门户，除了具备基本的请求转发、协议转换、路由等功能，以及高性能和高稳定性外，还需具备良好的扩展性，已便于网关能力的不断增强。在网关实施过程中，要规划好网关层与服务层的交互方式，尽量使得网关层与服务层解耦，便于各个团队工作的独立性。另外，在API的管理上，需要提供API全生命周期的发布、配置、鉴权、流控、监控等配套的管理功能。
API网关：微服务基础设施
例如Uber，在传统的单体架构遇到越来越大挑战的时候，决定改变自己的架构，效仿亚马逊、Netflix、Twitter等其他超级增长公司，将其整体架构拆分为多个代码库，以形成一个微服务架构。其主要变化是引入了API网关，所有的司机和乘客都是通过这个网关连接的。从API网关，所有的内部点都连接在一起，如乘客管理、司机管理、行程管理等。每个单元是单独的可部署单元，执行单独的功能。例如：如果你想在账单微服务中更改任何内容，那么只需部署账单微服务，而不必部署其他服务。所有的功能都是单独扩展的，即每个特征之间的相互依赖被移除。
Uber的微服务架构
API网关带来的的好处包括：
- 网关层对外部和内部进行了隔离，保障了后台服务的安全性
- 对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本
- 减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射
- 通过网关层聚合，减少外部访问的频次，提升访问效率
- 节约后端服务开发成本，减少上线风险
- 为服务熔断，灰度发布，线上测试提供简单方案。
- 便于扩展
API网关常见的解决方案包括Spring Cloud Gateway、Zuul、Tyk以及下文要介绍的Kong。
CNCF Landscape：API Gateway
3、Kong：API网关独角兽
Kong是我去年起就在关注的一家公司，它的创业历程非常有意思。“Kong的创始人Augusto Marietti（简称Aghi）出生在罗马，因为意大利创业环境很弱，在2009年飞来了旧金山。Aghi刚来就参加了一个早期创业者的小聚会，聚会上参加的人不多，但现在都是如雷贯耳的名字：Uber的创始人Travis，Airbnb的CEO Brian，Dropbox的CEO Drew和Box的CEO Aaron。Aghi当时为了省钱，借住在Uber创始人Travis家，每天睡沙发。
后来Travis搬了家，Aghi又去了当时只有十多个人的Airbnb办公室里借住，当时的Airbnb虽然Bug很多，但订单量一天天疯涨。在Travis的帮助下拿到天使投资后，Aghi做了一个把云端的组件连接起来的PaaS公司，一做就是五六年。由于时机不对，公司濒临破产，Aghi告诉团队，这么多年公司写了很多小功能，现在可以把代码开放出去，放在网上看看有没有人用，给社区做点贡献。没想到这看似濒死的挣扎，却给公司带来了巨大的转机。
后来，公司关于API管理的代码模块，在GitHub上被疯狂下载，Kong也接到客户要求，希望购买相应的付费企业版。Kong敏锐地发现了这个大机会，迅速转型成了一个开源软件公司。”如果在CSDN博客上搜索，关于Kong开源版本的教程比比皆是。这是一个成功的开源软件商业化的案例，听起来经历和Docker非常相似。
Kong开源版本Github主页
Kong成长的大背景是软件开发技术正在经历革命性变化，全球5000强公司都在转向新的分布式软件架构，因为现代应用程序需要有高度可扩展性、跨平台支持以及处理实时数据流的能力。IDC预计，到2022年90%的应用程序将采用微服务架构和第三方代码，35%的生产应用程序将诞生于云端。由于容器和敏捷方法的采用，预计2018-2023年间将诞生5亿个新应用程序。
同时开源软件初期具有的优势也在逐渐显现。Kong本身基于开源的Openresty（Nginx+lua），但比Nginx提供了更简单的配置方式，数据采用了Apache Cassandra/PostgreSQL存储，由于底层使用Nginx，所以性能比基于Java的Spring Cloud Gateway及Zuul更为出色。Kong另外一个非常诱人的地方就是提供了大量的插件来扩展应用，通过设置不同的插件可以为服务提供各种增强的功能。Kong默认插件包括：身份认证、安全、流量控制、分析监控、转换等等。
Kong的插件功能
Kong提供开源的Kong Gateway和商业版Kong Enterprise两个产品。例如在插件功能上，商业版本提供更多的选择。
Kong的部分插件功能
Kong通过云原生、混合和本地部署无缝连接API和微服务，便于程序员开发可扩展的微服务应用，推动业务增长。凭借高性能的开源内核和AI技术以及机器学习，Kong将实现全方位的服务生命周期管理，覆盖前期到后期全过程，帮助客户搭建和管理创新产品及服务。它服务于全球5000强企业，帮助程序员更方便地开发和管理高性能、可扩展的微服务应用，推动业务增长。
从业务和融资上来讲，2018年，Kong订单大幅增加，公司员工数翻倍，已服务超过100家企业客户，包括雅虎日本、法拉利、SoulCycle、WeWork等，开源软件下载量超过5400万次，收入为500万美元。2019年，Kong完成了Index Ventures领投，GGV纪源资本、World InnovationLab跟投，老股东Andreessen Horowitz、Charles Rivers Ventures追加的4300万美元C轮融资，至此Kong累计融资共计7100万美元。
4、RapidAPI：全球最大API市场
和Kong紧密相关的另外一家企业是RapidAPI，2017年，Kong的母公司Mashape将其API市场业务与RapidAPI合并，从而组成了世界上最大的API市场。
市场研究机构Ovum Research曾经表示，API经济在迅迅猛发展，到2018年将成为产值高达2.2万亿美元的市场。合并后，RapidAPI成为了这个市场的主要提供商之一。
RapidAPI的首席执行官吉纳在宣布合并的博文中表示，“软件相互连接起来后，其功效就要大得多。不妨想一想。你使用Facebook登录到某个游戏应用程序，就能看到玩游戏的所有朋友。当亚马逊的购买门户网站与仓库存货连接起来后，你就能实时获得发货估计日期。如果你在订购机票呢？已经在你的谷歌日历中预定了航班。”吉诺补充道，API正是让那些连接成为可能的秘诀。“它们让不同的软件得以彼此联系，共享信息，并且简化我们的生活。”
吉纳在博文中表示这只是开了个头。API正在迅速发展，打开之前紧闭的许多大门。使用API，开发人员就有可能从任何地方来访问服务，比如IBM公司的超级计算机和谷歌的机器学习模型，这就意味着他们能够充分利用比以前处理的任何资源丰富得多的资源。
吉纳说：“我们想要让广大开发人员更容易寻找、测试和连接API。我们的计划始终未变，那就是将世界上的所有API统统集中到一个地方。将Mashape API市场合并到RapidAPI让我们离实现这个目标比以往更近了一步。现在我们每月总共有370000名开发人员在调用3000亿次API。也就是说，每秒的API调用超过100000次。”
RapidAPI的市场里包括各种各样类型的API，例如天气、体育、科技、通讯、图像处理等等，例如获取新闻信息、实时体育比赛比分、天气信息，甚至还包括新冠病毒API分类。
开发商可以自由的为自己的API接口定价，下图是Twilio SMS接口的报价方案。
2019年，RapidAPI完成了由微软领投、A16Z等跟投的2500万美元B轮融资，历史累计融资达到3750万美元。RapidAPI表示，它将利用这笔新筹集的资金扩大其API市场规模，并推动其新发布的RapidAPI for Teams产品。它是一个自助服务平台，使开发人员能够发布，管理和协调API和微服务，这些是用于构建现代应用程序的常用组件。
5、Mulesoft：API集成/iPaaS/API管理领头羊
1）从SOA讲起
讲API管理之前，我们得先来说说前文提到过的SOA（Service-Oriented Architecture，面向服务的架构）。
简单地说，一个企业建设了许多业务系统，每个系统都拥有自己的数据，那么如何将这些分散各处的数据打通，从而可以进一步加以利用呢？
这就涉及到企业应用集成（EAI，Enterprise Application Integration）这个领域了。
传统上，企业应用集成很多是利用ETL（Extract-Transform-Load，抽取转换加载）工具，把不同系统里的数据经过抽取、过滤、转换，最终导入到一个集中的数据仓库里，然后再做整合应用。但是这种做法也存在很多问题。
一是只认数据，没有脑子。在数据汇集的过程中，只能针对数据格式本身进行一些处理，很难利用业务系统原有的业务逻辑。
二是随着各个系统数据体量越来越大，把所有系统的数据都汇到一个数据仓库里就变得越来越困难。
为了解决这样的问题，SOA应运而生，就是企业中每个系统都对外发布自己的服务，那么系统之间的集成，就可以通过调用对应系统的服务来解决了。
但是，随着企业拥有的系统越来越多，这种系统之间相互调用服务接口的集成方式又遇到了新麻烦。
可能每两个系统之间都需要相互调用服务，这最终就会演变成一个复杂的蜘蛛网结构，使得整个集成变得越来越脆弱，难以维护。
为了解决这个新问题，ESB（Enterprise Service Bus，企业服务总线）的概念被提出来了，就是把每个系统的服务接口都对接到ESB上，这样在系统集成的时候，只需要跟总线打交道，而不再需要直接跟所有其它系统打交道了，从而大大简化了集成的复杂度。
使用ESB前后
2）Mulesoft
2018年3月，美国SaaS巨头Salesforce花费65亿美元收购iPaaS代表企业Mulesoft，Mulesoft于2017年在纽交所上市，市值约30亿美元。Mulesoft的核心产品是企业软件集成平台Anypoint Platform（旧称Mule ESB），客户可以在Anypoint上集成所有业务系统的服务，实现本地系统与云、以及云与云服务的集成。Anypoint Platform/Mule ESB是世界上使用最广泛的开源ESB产品，已拥有超过数百万的下载量，以及来自世界各地数十万个开发人员，财富500强中35%的企业、全球10大银行中的5家均使用了该平台。
Mule ESB
尽管只有一个产品，但从Gartner的划分标准来看，Mulesoft同时踩在了两个领域里：全生命周期API管理和企业集成平台即服务（iPaaS，Enterprise Integration Platform as a Service）。
Gartner魔力象限：全生命周期API管理
Gartner魔力象限：企业集成平台即服务
Mule ESB同时包括开源和商业版本，在各个技术论坛上遍布其技术教程。
Mule开源版讨论文章
Mulesoft的成长历程非常具有参考意义，他们瞄准了一个有7000亿美元空间的市场，目标是解决一个十分困难的IT问题-集成。在摸索过程中Mulesoft不断优化其产品形态和销售方式，例如针对大客户需要的不仅是平台提供的通用功能，还需要更复杂的综合服务。于是MuleSoft把他们的销售方式从出售可靠的集成功能，变成了向高级管理人员出售提升企业连接能力的愿景和相应的解决方案，客单价也从10-30000美元提升到了500万美元。
3）应用场景与案例
Mule ESB的常见应用场景例如：
- 旧系统改造，开放系统的服务能力。举个例子，企业有一个电商系统，需要调用SAP ERP的订单接口来创建订单，这个时候需要将SAP的订单服务暴露成流行的Restful API，以方便电商系统调用。使用Mule ESB可以轻松实现。
- 系统集成。企业之间的数据交换，竟然有一半以上是文件的形态进行的，这在互联网思维普及的今天，是不容易想象的。在10年前，企业间交换数据采用文件形态的比重占60%，当时普遍认为这个比重会迅速下降，最终以接口服务形态进行交换的比重会占绝大多数。然而10年后直至今天，采用文件形态的依然占51%的比重。其实仔细想想，也不无合理。两个对等企业之间，行业上下游多个企业之间，不同系统之间的进行数据交换，采用文件的形式，可能是最简单便捷的方式。举个例子，很多系统之间数据交互可能还是用FTP目录。尤其是企业跟企业之间的数据交互，比如，A企业丢一个EDI文件到B企业的FTP目录，然后B企业会从FTP目录下载解析并放置到数据库。这个场景用Mule ESB实现也很方便。
4）Salesforce为什么收购Mulesoft
Salesforce最初为中小企业提供SaaS的CRM，而随着大客户越来越多，定制化、个性化的需求也越来强烈，所以就需要提供PaaS平台解决个性化、定制化的问题。
而这个定制化，最开始只是以Salesforce为核心的功能延伸及简单扩展，而随着个性化需求的不断深入，这种定制已经逐步演变为更大规模的多个骨干数据源之间的数据集成与交换，Salesforce可能只是多个数据源之一。
所以也可以说，数据集成是PaaS平台的上层建筑，Salesforce需要帮助客户解决整合不同数据源所带来的挑战。
收购之后，Salesforce会将MuleSoft植入进Salesforce Integration Cloud，从而帮助客户连接多个数据源，并计划在之后推出集成云。
所以，可以看出Salesforce其实更在乎的是集成（Integration）这个词。
5）iPaaS、API管理与API集成
iPaaS的集成不光是针对云服务，也包括本地系统，这样就解决了混合云模式下的集成问题。iPaaS集成的范畴，除了API接口之外，一般还会包括更多种类的协议（比如FTP、数据库），也包括对于文件数据的集成。
从这个角度来理解，API管理更关注API的治理与整合，iPaaS关注更大范畴的集成，包含API集成的概念。
6）SOA、ESB与微服务的关系
微服务架构和SOA架构非常类似，微服务是SOA的升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用，这些小应用间通过服务化完成交互和集成。
ESB是一种集中式服务治理的架构，看上去微服务中不需要ESB，Martin Fowler也不赞同在微服务架构中继续用ESB。
我们下面要介绍到的下一代微服务架构核心-服务网格*，则可以视为分布式的ESB。*
微服务2.0：服务网格与Serverless
1、服务网格
微服务当前遇到的挑战包括：
- 技术门槛高：开发团队在实施微服务的过程中，除了基础的服务发现、配置中心和鉴权管理之外，团队在服务治理层面面临了诸多的挑战，包括负载均衡、熔断降级、灰度发布、故障切换、分布式跟踪等，这对开发团队提出了非常高的技术要求。
- 代码侵入性强：Spring Cloud、Dubbo等主流的微服务框架都对业务代码有一定的侵入性，技术升级替换成本高，导致开发团队配合意愿低，微服务落地困难。
为了解决上述问题，号称微服务2.0的服务网格（Service Mesh）应运而生。服务网格这个词最早由著名开源服务网格项目Linkerd所在的Buoyant公司CEO William Morgan所提出。按照他的定义，服务网格是一个软件基础设施层，用于控制和监视微服务应用程序中的内部、服务到服务的流量。
服务网格架构
Sidecar是服务网格中的核心组成部分，可以看到，上图中每一个微服务都配备了一个Sidecar。此时用户只需要关心业务逻辑，而不用关心服务治理等非业务功能，非业务功能都由Sidecar负责，接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流等功能从服务中抽离到Sidecar中。
服务网格和API网关是两个联系非常紧密的概念，它们的用途既不同，但是在某些方面又相互重叠。在某种程度上，我们可以认为服务网格是一个分布式的、微观层面的API网关，解决微服务服务发现、负债均衡、流量控制等需求。在具体用途上，API网关处理的是所谓南北向流量即内外部请求；而服务网格处理的是东西向流量即内部服务相互间的访问。想深入了解两者区别的读者可以仔细阅读《Service Mesh和API Gateway关系深度探讨》这篇文章。
南北向流量 vs 东西向流量
服务网格相关的著名项目包括Linkerd、Envoy和最受欢迎的服务网格框架Istio。Kong也于2019年发布了基于Envoy的开源服务网格产品Kuma。
Kong的服务网格产品：Kuma
下图是CNCF Landscape里服务网格分类所罗列的项目，其中Linkerd正由CNCF进行孵化。
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
微服务 vs 宏服务：新的抉择
最近，Uber支付体验平台的工程经理Gergely Orosz发布推文表示他们的架构方向已经发生了变化。
“声明一下，在Uber，我们正将许多微服务转移到@copyconstruct所称的Macroservices宏服务（大小适中的服务）。
确切地说，B/C测试和维护成千上万的微服务不仅很难——它可能会带来更多的长期麻烦，而不是解决短期问题。
微服务确实可以帮助团队在早期快速推进。
等你意识到服务越少越好时，已为时已晚。你需要解决很多服务的“困难”部分。
我们在不断增加更多的服务，但也在停止使用服务，并且会更慎重的思考新的服务。“
全部的上下文可以在这里阅读。有一篇英文文献中这样描述Macroservices宏服务：宏服务应该定义为运行2-20个单独服务的应用程序体系结构，每个服务代表一个中等大小的代码库，可处理业务中定义明确的部分。宏服务的关键是拆分服务，最大程度地从拆分中获得收益，同时最大程度地降低运行多个服务的开销。通俗点讲，宏服务介于单体服务到微服务之间，关注的不再是某一个细节点，而是一个业务点。
实际上，宏服务目前的定义并不清晰，影响和实践相当有限，也并非比微服务更优的解决方案，本质还是不同企业和团队在架构演进中对于系统复杂性的不同度量。
总结
微服务的理念不同的团队有不同的实践，例如微服务如何拆分、组织架构如何搭建、技术栈如何选择。
我们理解，微服务是云原生的核心，后面要介绍到的容器（及Docker）和Kubernetes是实现的技术方法和手段，DevOps是配合的文化和研发流程，但是微服务带来的启发，更多是思维方式上的转变。
第四部分：容器和Docker
虚拟化与容器
在容器技术之前，业界的网红是虚拟机。虚拟机技术的代表是VMware和OpenStack，我在虚拟化与超融合系列里做过介绍。很多人都用过虚拟机，就是在操作系统里安装一个软件，然后通过这个软件，再模拟一台甚至多台“子电脑”出来。在“子电脑”里，可以和正常电脑一样运行程序，例如微信、Word。“子电脑”和“子电脑”之间，相互隔离互不影响。
虚拟机虽然可以隔离出很多“子电脑”，但占用空间大，启动慢，虚拟机软件可能还要花钱（例如VMware）。而容器技术恰好没有这些缺点，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”），启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个Docker容器）。此外它占的空间很小，虚拟机一般要几GB到几十GB的空间，而容器只需要MB级甚至KB级。虚拟机和以Docker为代表的容器都是虚拟化技术，不过容器属于轻量级的虚拟化。下面是两者的主要对比。
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鼓励将应用程序分解为它们各自的进程，并提供了实现这一点的工具，这种粒度有不少优点。
传统Linux容器 vs Docker
Docker解决的问题
众所周知，Linux上我们不愉快的经历之一就是安装软件。因为系统硬件、操作系统环境不一样，软件包有不同的依赖性，所以必须要安装完软件依赖路径上的所有包，这个链条之长，往往要耗费几小时甚至几天的时间。例如下面的案例，我要安装Docker，系统提示我必须要先安装selinux-policy、selinux-policy-base、selinux-policy-targeted三个相关模块。而我安装selinux-policy的时候，又提示要先安装python；安装python的时候，又提示我要先安装_bz2、_curses、_curses_panel等等模块…
这就是由于环境不统一带来的巨大问题，每天在世界各地的数千万台机器上都会重复上演无数次。那么，如果服务器环境能够标准化，那我们安装任何软件只需要一个版本就可以解决问题。
同时，如果所有服务器环境统一、标准化，还能保留上面的配置、安装的软件和应用，对于我们来讲就更加有用。Docker正是在操作系统之上实现了这个标准化、统一化的运行环境，并且把各种不同的配置和应用存储成镜像，供未来使用。这有点类似于我们熟悉的Ghost或者虚拟光驱，把需要的环境和状态保留为镜像，随时恢复、随时使用。不过Ghost基于操作系统，镜像是一个大文件，管理起来并不方便，恢复速度也很慢，同时不支持跨平台的镜像恢复；而虚拟光驱则是基于软件层面，使用范围有限；而Docker正处于两者之间，能完成更多功能的同时，还实现了镜像的快速加载和运行。
Ghost软件
虚拟光驱软件
我们在上一部分讲微服务的时候，将其比喻成装配式建筑。把这个比喻用在Docker上的话，我们只要提前设计好模板（配置环境、部署软件或服务），就能在工厂（Docker）里批量化生产（说复制可能更加合适）出楼板、墙板、楼梯、阳台等构件和配件（容器所装载的、不同的微服务），这些构件在建筑施工现场经过组装拼合（API访问），就能成为各种各样的建筑（各种类型的产品和应用）。
装配式建筑由各种构件组成
Docker与各种概念的关系
所以，Docker曾经有一句Slogan叫做“Build once，Run anywhere（搭建一次，随处可用）”。
Docker的核心概念
Docker技术的三大核心概念，分别是：
- 镜像（Image）
- 容器（Container）
- 仓库（Repository）
上面的例子里，设计出来的模板就是Docker镜像，生产（复制）出来的构件就是Docker容器，而Docker仓库则是集中放置管理Docker镜像的地方。
Docker镜像是一个特殊的文件系统。它除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的配置参数（例如环境变量）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。
每一种模板（镜像）能够创建出一种构件，但是模板可以由不同的设计师来设计，提供不同用途、不同风格，例如斜顶式阳台、嵌入式阳台、包豪斯风格、蒙德里安风格等等，所有人相互之间可以共享，这就形成了大的公共仓库。
Docker官方提供了Docker Hub来维护管理所有的镜像，只是对于免费用户而言,只能创建一个私有仓库。Docker Hub里提供了大量高质量的官方镜像，例如Oracle、MySQL、redis、Ubuntu、Nginx、python、Docker（Docker in Docker！）等等，开发人员需要一个环境的时候，可以直接到Docker镜像仓库去查找，减少了大量无谓的环境安装工作。
Docker Hub
Docker创始人曾经公布过一个相关数据，Docker Hub里镜像的下载数量从2014年的100万次，3年内猛增到了120亿次。
下面是我从Docker Hub上拉取一个hello world演示镜像，并且运行的示例。
Docker的好处
Docker给我们带来的好处非常多，下面简单列举几点：
- 更高效的利用系统资源
有了Docker，我们可以在一台服务器上运行很多应用，充分利用硬件资源。例如现在我们有一台Linux服务器，可以构建不同版本的Ubuntu镜像启动，并且为不同的用户分配不同的容器。这样用一台服务器就能虚拟出许多运行不同操作系统的虚拟服务器，而对于用户来说，这些都是透明的。许多公有云采用了容器技术为用户提供服务，所以虚拟化与容器共同成为了现代云计算的基石。
- 更快速的启动时间
传统的虚拟机技术启动应用服务往往需要数分钟，而Docker容器应用，由于直接运行于宿主内核，无须启动完整的操作系统，因此可以做到秒级甚至毫秒级的启动时间，大大的节约了开发、测试、部署的时间。
- 保证环境一致性
开发过程中常见的问题之一是环境一致性问题，由于开发环境、测试环境、生产环境不一致，导致有些bug并未在开发过程中被发现，而Docker的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，再也不会有在线下开发环境中运行正常，而部署到线上有各种错误的情况了。
- 持续交付和部署
对于开发和运维人员来说，最希望的是一次创建或配置，可以在任意地方正常运行。开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接使用这个容器来部署代码，无论在多少台服务器中部署都是如此。Docker可以快速创建容器，快速迭代应用程序，并让整个过程全程可见。
- 更轻松的迁移
由于Docker确保了执行环境的一致性，使得应用的迁移更加容易，Docker可以在很多平台上运行，无论是物理机、虚拟机、公有云、私有云，其运行结果是一致的，因此用户可以很轻易的将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。
- 提升复用性，降低耦合性，维护和扩展更轻松
Docker使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。安装Docker后，我们可以从Docker Hub上获取各种各样的操作系统镜像，这个操作很简单，只需要拉取相应的镜像到本地然后运行即可。另外我们可以将数据库、Web服务器、缓存服务器运行在不同的容器中，降低了各个服务之间的耦合性、便于扩展，Docker Hub上有各种各样的优秀镜像，我们可以直接拿来使用，不需要自己搭建，应用的部署就像搭积木一样简单。
- 实现沙盒机制，提高了安全性
由于应用运行在容器中，与操作系统隔离开，从而使操作系统基本不可能受到破坏。另外如果应用因为攻击而瘫痪，并不需要重启服务器，直接重启容器或者再启动一个镜像就可以了。
容器与微服务
容器是微服务和云原生架构的最佳实现载体。微服务与容器几乎是完美的搭配。单体式架构（Monolithic）变成微服务架构（Microservices），相当于一个全能型变成N个专能型，每个专能型分配一个隔离的容器，赋予了最大程度的灵活。
服务器势必会走上虚拟化的道路，因为虚拟化有太多的优势，例如前文所说的低成本、高利用率、充分灵活、动态调度等等。而采用容器之后，只需要一台服务器，创建十几个容器，用不同的容器，来分别运行不同用途的服务程序。这些容器，随时可以创建，也可以随时销毁。还能够在不停机的情况下，随意变大，随意变小，随意变强，随意变弱，在性能和功耗之间动态平衡。所以容器化是云计算的终极形态。
如果把传统IT架构比作传统工厂，容器化比作现代化工厂，那么下一部分我们要讲到的Kubernetes则会将现代化工厂进一步提升为智能化无人工厂。那么当Docker遇到Kubernetes之后将会发生什么有趣的事情？让我们拭目以待。
第五部分：Kubernetes与容器编排之战
容器编排与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为服务的滚动和平滑升级提供了很好的机制
Kubernetes使用案例：滚动发布
下面我们举一个Kubernetes的应用场景，帮助大家更好的理解Kubernetes的用途。
应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布（金丝雀发布）和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。
在微服务架构盛行的时代，用户希望应用程序时时刻刻可用，为了满足不断变化的新业务，需要不断升级更新应用程序，有时可能需要频繁的发布版本。实现"零停机"、“零感知”的持续集成和持续交付/部署应用程序，一直都是软件升级换代必须面对的难题和追求的理想方式，也是DevOps诞生的目的。
滚动发布/滚动更新（Rolling Update Deployment）是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级成为新版本。在整个滚动发布期间，保证始终有可用的副本在运行，从而平滑的发布新版本，实现零停机、用户零感知，是云原生时代非常主流的发布方式。
下图是滚动发布的流程示意图，Load Balance是前端的负载均衡器，橙色是正在运行旧版本服务的节点，紫色是正在更新及更新完毕新版本服务的节点。
滚动发布流程示意图
可以看到，滚动发布开始后（Step 2），负载均衡器将服务器A从集群里摘除，服务器A进行新版本的发布，由服务器B和服务器C对外提供版本1.0的服务；Step 3，服务器A更新完毕，部署验证成功，负载均衡器将其加入集群，开始和服务器C一起对外提供不同版本的服务，同时服务器B开始发布；直至服务器ABC全部发布完成（Step 5），服务都更新到最新的2.0版本。
滚动发布的优点是用户无感知，平滑过渡，同时不需要冗余服务器，节省资源。不足是部署时间慢，取决于每阶段的更新时间；发布策略较复杂；同时涉及自动化的更新策略、部署验证、回滚机制等等，自动化程度比较高，通常需要复杂的发布工具支撑，而Kubernetes正好可以完美的支持这个任务。
Kubernetes通用的编排模式是控制循环，用伪代码表示如下：
解释一下，Kubernetes集群本身状态就是实际状态，而期望状态来自于用户提交的配置文件。滚动发布的时候，Kubernetes将会根据这个控制循环，使用一个叫做Deployment的控制器，通过创建新的集群（下图中的v2版本ReplicaSet复制集）将其控制的Pod副本从0个逐渐变成3个，与此同时旧的集群（下图中v1版本的ReplicaSet）管理的Pod副本数则从3个逐渐变成0个，以此将一个集群中正在运行的多个Pod交替的逐一升级，实现滚动发布的效果。
如果在发布刚开始的时候，集群里只有1个新版本的Pod，这个Pod有问题启动不起来，那么滚动发布就会停止，开发和运维可以及时介入解决问题。而应用本身还有旧版本的集群和Pod在线，所以服务不会受到任何影响。关于滚动发布的详细介绍和互动教程可以阅读这里。
下面这张图展示了使用Kubernetes，配合代码仓库GitLab、Docker镜像仓库Harbor、构建工具Jenkins，实现自动化的CI/CD流程。
上一部分结束时我们提到，传统IT架构好比传统工厂，容器化好比现代化工厂，而Kubernetes则是智能化的无人工厂，让容器和应用能够高效自动、井然有序的被控制和管理；Kubernetes还实现了服务的抽象、解耦、高扩展、统一调度与集中化管理，例如用户可以专注用同样的方式在不同硬件上的应用，比如GPU节点池和低优先级的CPU节点池。Kubernetes不仅解决了容器的编排问题，让容器应用进入大规模工业生产，更进一步对云原生应用提供了定义规范，CNCF整个技术栈都是围绕Kubernetes建立，所以Kubernetes是云原生生态最重要的基石，可以说“Kubernetes是云原生时代的Linux”，即云原生应用的操作系统。
高扩展的Kubernetes：兼容不同的硬件节点
Kubernetes：云原生应用的大规模工业生产
回到本文第一部分，我们曾经用集装箱革命比喻云原生。现在大家已经理解，货船可以类比操作系统，集装箱类比容器，里面装的货物则是一个个的微服务，吊臂、吊桥、起重机等自动化操作设备是Kubernetes，而一整套集装箱的操作方法和流程则是DevOps。所有这些加起来构成了现代PaaS所具备的能力：操作系统、集群管理、应用编排、应用发布、持续集成等等。
容器编排之战
意识到容器编排的重要性，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在竞争中失利，看起来是时机和生态构建的问题，但归根结底是基因和能力问题
此系列文章的前五部分，我们详细介绍了云原生的各种理念和技术。在最后一部分，我们将展开总结和思考，分析云原生时代的机遇与挑战。
第六部分：机会与思考
上文主要介绍了Kubernetes与容器编排之战，本文的最后一部分将系统性的总结云原生能带给我们什么样的未来，相关的创业和投资机会在哪里。
每一次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，也为下一项技术留下了足够的空间。
云原生投资的分层
对于大多数软件开发组织来说，仍然处于采用微服务和容器的早期阶段。新机遇一方面源自于云原生在各行各业的应用，一方面则是云原生相关新的基础设施。
CNCF全景图呈现了比较完整的云原生项目和分类，我们可以将其简化成如下图所示的几种大的分类：
一共分为AppDev & DevOps；Management；Runtimes；Infrastructure and Services；Serverless；Observability；Security八个大的模块。
从广义的角度来讲，云原生应用的设计、开发、管理、运维、分析与传统应用有非常大的不同，生态的每个环节、技术的每个领域都会有许多机会，例如云原生应用的设计、咨询、开发、培训，需要有方案商、供应商、实施商；在基础设施层面，数据库、开发工具、核心中间件、安全产品等等都会有巨大市场需求，例如Service Mesh+安全、Serverless+安全、容器+安全、多云+安全，例如云原生数据的分析处理，例如云原生架构的灾备管理。
我个人将云原生的生态分为三层：
- 技术层
技术层包括云原生技术相关的基础设施，主要分为两种类型：
- 应用层
应用层主要是云原生在各行业的具体应用。
- 服务层
包括云原生相关的培训、咨询、认证等相关服务。
下面我重点讲讲技术层和应用层。
云原生技术层
下面的表格里代表性的列举了云原生技术层的几个领域及相关项目。
下图展示了当前这些项目的市场占有率情况。
可以看到技术层涉及的范围非常广，机会非常多，本文仅展开介绍其中我比较看好的一个领域-云原生安全。
据CNCF统计，采用容器技术的挑战中，开发团队面临的文化挑战、安全性、复杂性、就绪性和监控分别排在前五位。
使用容器的挑战
在云原生架构中，安全问题显得尤其突出的原因有以下几点：
为了在云本机环境中保护业务资产，组织必须将安全实践和技术与它们要保护的系统纳入体系结构中。正如DevOps支持持续开发和部署一样，“DevSecOps”也必须支持持续的安全管道。这意味着要建立全新的方法、功能和工具，以确保旨在保护云原生系统的解决方案呈现以下基本特征：
- 全局的实时可见性：局部的或事后的可见性是不够的。无论位于何处，基础架构层和应用程序都必须可见。
- 快速、迭代的反馈循环：反馈循环允许安全措施不断适应快速变化的环境。
- 解决安全问题的工程方法：自动化、连续测量和受控实验将是解决整个企业安全问题的主要方法，取代手动分析和控制更新。
因此，像Netflix、Lyft和Square等组织已经开始将云原生安全作为工程问题来处理，使用自动化来避免这些陷阱，并使安全团队更加有效。他们还规避了将检测、响应和开发团队分开的烟囱式结构，在构建安全检测机制并将它们与响应编排集成时遵循DevOps的思想。
来自Netflix的安全检测组件示例
Kubernetes官网
云原生的安全分为4C，即代码、容器、集群、云四个层级。
CNCF全景图中安全与合规子分类里包含的项目如下图所示。
像在我多篇文章里曾经提及的新一代云安全公司，市值189亿美金的CrowdStrike，直接将自己定义为云原生的端点保护平台（Cloud-Native Endpoint Protection Platform），以此同传统的端点保护产品区分开来。
下面我介绍几家和云原生安全相关的初创企业。
1、Capsule8（B轮）
Capsule8是一家由经验丰富的黑客和安全企业家创建的高新科技初创型企业，总部位于纽约布鲁克林，成立于2016年秋季，在2018年8月获得1500万美元的B轮融资。
Capsule8开发了业界第一个也是唯一一个针对Linux的实时0day攻击检测平台，可主动保护用户的Linux基础设施免受攻击。Capsule8实时0day攻击检测平台可显著改善和简化当今基础架构的安全性，同时为未来的容器化环境提供弹性的支持。
混合云架构已经成为企业IT基础设施的重要架构，但其复杂性也使企业面临多种攻击的风险，根据Capsule8与ESG Research赞助的一项新研究表明，仅2017一年就有42%的企业报告了混合云环境受到攻击，28%的企业表示0day攻击是这些攻击的起源。
混合云环境由于存在多云服务商，缺乏中心控制和完整的合规性规划，存在边界模糊，访问策略不一致等问题，加上公有云的暴露面增大，攻击者容易通过攻击薄弱点进入，这也是近年来如软件定义边界SDP、移动目标防护MTD等新方案兴起的原因。
无论是传统环境，还是混合环境，防护利用0day漏洞的高级威胁需要企业安全团队全方位持续防护资产、获得环境的可视性，检测恶意行为。
Capsules8平台整体架构图如下所示：
假设客户生产环境是一个混合云环境，服务器部署于客户侧数据中心、公有云AWS和Azure中。Capsule8的整个工作流程主要分为感知、检测、阻断、调查四步。
2、Aqua Security（C轮）
Aqua Security成立于2015年，它为基于容器、Serverless和云原生应用提供保护解决方案。2019年，Aqua Security完成了6200万美金的C轮融资，累计融资超过1亿美元。它的客户包括能源、航空航天、互联网、媒体、旅游、零售、制药和酒店业的100多家知名企业。
Aqua Security的云原生安全平台使用现代化的零接触方法来检测和预防威胁，在整个应用程序生命周期内提供全面的可见性和安全自动化。例如在漏洞管理方面，Aqua可以实现：
扫描镜像和功能：Aqua几乎与所有CI/CD工具集成在一起，可在构建镜像和功能时主动扫描，及早发现问题并允许快速修复。
关注应用风险：下一个挑战是大规模提供安全性。这种情况是指可能要扫描成千上万个镜像的漏洞。但是，其中许多镜像实际上并未在生产中部署，因此即使处于脆弱状态风险也不高。Aqua提供了对正在运行的工作负载中易受攻击组件的实例化的可见性，这使安全团队可以集中精力修复最容易遭受利用风险的那些组件。
提供可行建议：Aqua提供了有关漏洞的具体可行建议，通常是建议升级到特定的版本或者改变配置和环境变量。
3、Twistlock（被收购）
位于CNCF全景图里的Twistlock创立于2015年。曾经在以色列著名的网安黄埔8200部队服役，并在微软企业安全部门工作的Ben Bernstein以不到30万美元的种子轮开始起家，定位容器安全。Twistlock自己贴的标签除了容器安全，就是云原生安全。Twistlock的融资节奏很好，2015年5月天使轮280万美元，2016年7月A轮1000万美元，2017年4月B轮1700万美元，2018年8月C轮3300万美元，2019年就被Palo Alto Networks以4.1亿美金的价格收购。
Twistlock产品界面
现在，Twistlock已经能为Amazon ECS、Azure、Docker、GCP、Pivotal、OpenShift、Istio等多个平台提供安全方案。Twistlock的自己一句话介绍是“领先的全栈，全生命周期容器安全解决方案，保护容器环境及其中运行的应用程序，具有轻量级，可扩展和自动化特性，自动化的策略构建和全开发生命周期内的无缝集成”。
截至目前，Twistlock总结了6方面的核心能力，分别是漏洞管理、合规、运行时防护、持续集成和持续交付、云原生防火墙和访问控制。像运行时防护包括网络和应用程序防火墙，支持Docker和AWS Fargate运行安全以及主机防护，可以通过机器学习为每个应用程序进行自动建模，保护网络，文件系统，进程和系统调用。云原生防火墙方面，Twistlock包括3层防火墙和7层防火墙，它可以自动学习应用程序的网络拓扑，并为所有微服务提供应用程序的微分段，可以检测和阻止XSS攻击、SQL注入等威胁，还可以自动模拟所有微服务之间的所有流量，并允许安全团队集中查看和实施安全流量，同时自动阻止异常，无需手动创建和管理规则。
除了云原生安全领域，以及前文介绍过的Kong、RapidAPI之外，我再介绍三家知名的云原生技术层创业企业。
1、Rancher（D轮）
在本文第一部分我们提过Rancher（中文意思是放牧人）这家公司，它的创始人梁胜职业生涯贯穿软件开发与云计算的发展历史。作为耶鲁大学计算机博士、Java语言J2SE平台核心组件JNI的作者、JVM的领导设计与开发者，梁胜2000年离开Sun创办了应用防火墙软件公司Teros Networks并担任CTO，2001年公司被Citrix收购。2008年梁胜第二次创业创建了Cloud.com，并推出了著名的云计算管理软件CloudStack，他也因此被誉为“CloudStack之父”，2011年Cloud.com被Citrix又以2亿美金收购，他成为Citrix首位华人CTO。随后2014年梁胜创立了容器管理公司Rancher Labs。这是他创建公司的初衷。
Rancher是一个容器管理平台，通过Rancher可以实现Docker和Kubernetes的轻松部署。Rancher由基础设施编排、容器编排与调度、应用商店、企业级权限管理组成。下图展示了Rancher的主要组件和功能。
今年3月份，Rancher对外公布了4000万美元的D轮融资，由此Rancher累计融资高达9500万美元。
2、HashiCorp（E轮）
HashiCorp（简称为Hashi，日语“桥梁”的含义）是我一直非常看好的一家云原生技术企业，不过最近因为禁止中国企业使用其商业产品而被刷屏。它成立于2012年，主要开发DevOps和云管理基础设施相关产品，日裔创始人及CTO Mitchell Hashimoto从12岁就开始创业，目前年仅30岁，公司主要产品都出自于他的手笔。
HashiCorp旗下包含多款知名的云原生相关开源产品，我们自上而下的来看：
- Nomad：程序自动化，集群管理器和调度器，专为微服务和批量处理工作流设计。与Kubernetes相比，Nomad通用性更强。
- Vault：安全自动化，企业级私密信息管理工具。
- Terraform：基础架构自动化，安全有效地构建、更改和版本控制基础设施的工具。
- Packer：镜像工具，旨在通过简易的方式自动化构建镜像。
- Vagrant：用于创建和部署虚拟化开发环境的工具，由Mitchell Hashimoto在23岁时开发，并成为其创建HashiCorp的基石。
- Consul：网络自动化、服务网格解决方案，它提供了一个功能齐全的控制平面，主要功能包括服务发现、健康检查、键值存储、安全服务通信、多数据中心等等。
今年3月HashiCorp对外公布了1.75亿美元的E轮融资，投后估值为51亿美元。
3、Snowflake（G轮）
Snowflake成立于2012年，创始人Bob Muglia曾在微软工作23年，拥有丰富的数据库经验。Bob Muglia认为，NoSQL型数据库并不能完全适应业务要求，基于云端的数据仓库省去了相关软硬件的设置需要，降低了使用门槛。Snowflake包括数据引擎在内的几乎所有技术都是自己研发的，在数据库和数据处理方面拥有非常多的专利，它是一个云原生的SQL数据仓库，完全针对云计算特点设计，部署在AWS等云端平台上，可以将用户所有的数据集中在一个地方，用户只需加载数据然后运行查询就可以查找到各种结构化或半结构化的数据。
为什么要使用云原生数据仓库？
作为一个类别，云原生的数据仓库提供了许多好处。首先，它们使公司摆脱了对设备和机器的担忧：在过去的物理服务器时代，公司需要操心服务器机房，或者至少是运行软件或存储数据的特定机器。构建这个物理基础设施是启动或扩展软件公司的一个巨大障碍。现在，服务器成本要低得多，只需点击几下鼠标就可以创建云端数据仓库。公司只需要按需处理和存储数据，并为他们使用的东西付费。云的使用还可以为公司提供更多的冗余和支持，因为他们不再需要担心单个服务器的故障和整个操作的崩溃。大型云服务提供商拥有多个备份系统，可以在全球数据中心之间自动扩展，以保持一切正常运行。这对客户公司来说是双赢的。
作为一个基于云的数据仓库，Snowflake具有很强的灵活性和可伸缩性。Snowflake基于订阅的模型将存储和计算服务分离，允许它们独立运行。当用户构建插入Snowflake的新解决方案时，他们只支付存储数据或根据需要分析数据的费用。此外，该系统还构建了一个相互连接的云服务器阵列，将数据分散，允许组织内的单个用户或组访问他们需要的特定数据，而无需复杂的数据传输，简化了连接和分析。
对于云原生数据仓库来说，能够在不影响底层的情况下快速查询数据并使用实时数据执行分析是一个强大的功能。由于数据不断地被各种各样的系统所创建，其中许多系统最初都是云端固有的，因此实时分析这些数据的能力对现代公司至关重要。实时分析会根据需要，只对特定实例和项目收费而不产生更高的成本。
Snowflake在今年2月份完成了4.79亿美元的G轮融资，估值高达124亿美元，投资机构包括Salesforce Ventures，Snowflake还由此宣布了与Salesforce的战略合作伙伴关系。Snowflake在《福布斯》最新的“云100强”榜单中位列第二，仅次于Stripe。
云原生技术层的机会我还在《信天研报 | 虚拟化与超融合（一）》系列里提到过，由于容器技术对于传统虚拟机的冲击，众多创业公司正在解构VMware，这将在该系列详细讨论。
云原生应用层
云原生能广泛应用在所有的行业，并发挥其快速、灵活、弹性、扩展性强、迁移能力强等多种优势。在这里我仅抛砖引玉，分析下云原生游戏的优点。
围绕云游戏的许多讨论都集中在其“杀死控制台”的潜力上，从而消除了本地硬件玩游戏的需求。但是，对硬件的持续关注未能抓住云游戏的真正潜力。云游戏的真正创新不仅仅在于我们怎么玩游戏方式，还在于我们玩什么游戏：“云原生”游戏将完全颠覆游戏体验本身，以及这些游戏的销售和销售方式。
云原生游戏是专门为云开发的游戏，其中客户端和服务器托管在同一架构中，有可能产生全新的游戏体验和商业模式。
病毒式传播
大多数MMO（Massively Multiplayer Online，大型多人在线）游戏具有固有的网络效应，这意味着与更多玩家一起玩游戏会更加有趣。然而，MMO通常会遇到冷启动问题：一开始，没有足够的参与者来创造积极的体验，从而导致新用户的流失。与朋友合作玩耍是最好的招募和留住新用户的方式，但是在此过程中可能会遇到很多障碍。例如，用户可以在不同时间或在不同平台上玩。由于不透明的配对规则和服务器限制，在游戏中寻找朋友可能很麻烦。
利用云原生开发的MMO游戏本质上是跨平台的，因此可以从任何设备上访问。没有下载、安装，或者加载时间，用户不用再为了补丁或者一个游戏的副本需要等待三个小时。
为了简化入门过程，云原生游戏可以使用深层链接来无缝地允许新玩家加入朋友的游戏会话。同时，想要获得更轻松体验的用户可以实时选择确切的时点来参加比赛或作为旁观者。
这些支持云的功能共同加速了多人游戏固有的网络效果。如果成功的话，第一个云原生MMO游戏可能会完全通过玩家主导的招募而快速发展，其病毒增长曲线比传统的MMO更类似于Facebook。
创造视频营销机会
除了更强大的病毒性之外，云原生游戏还将为AAA（3A大作，高成本、高体量、高质量）游戏提供新的营销形式。传统上AAA游戏依赖于广告牌和展示广告等营销方式。在没有安装时间的情况下，潜在玩家将能够单击链接立即尝试一款游戏—这是一个巨大的进步。
随着云游戏的普及，视频和有影响力的营销将变得越来越重要。销售佣金和“点击加入”可能会成为云游戏经济中网络大V收入的最大来源。
实现AI驱动的实时内容生成
由于客户端和服务器在同一个网络中，云原生游戏可以方便的跟踪和收集用户旅程中几乎所有的数据，这使得我们可以以开创性的方式在游戏中增强人工智能和机器学习能力。
例如，游戏长期以来通过出售改变玩家外观或周围世界的化妆品来赚钱。由于云提供无限的数据、处理能力和最小的客户端-服务器延迟，人工智能可以实时生成完全动态的环境。以下是基于Nvidia深度学习系统的剪辑，显示用户在AI的帮助下修改了一个逼真的虚拟环境：
将来，实时内容生成可能会催生新的、沉浸式的故事讲述方法。下一代的“选择你自己的冒险”可能是一个虚拟世界，实时适应你的选择。为了使这些虚拟世界货币化、个性化，自发性的广告可能会出现，类似于《少数派报告》中的生物识别广告。
更远的未来，AI驱动、程序生成的世界可以为用户提供一个无尽的游乐场，那时距离《头号玩家》里的绿洲世界或者著名的网络世界-元界（Metaverse）已经不远。
预计我们将在两三年内看到第一款云原生游戏上市，在谷歌、微软、亚马逊和其他许多公司的投资推动下，下一代云原生游戏将有潜力重塑我们所知道的游戏体验。
在上述认知的推动下，A16Z、腾讯、淡马锡投资了免费沙盒MMO游戏Roblox的1.5亿美金的G轮，相应估值高达40亿美元，他们认为未来游戏将不再只是游戏，甚至将比电影和音乐加在一起的规模还大。游戏的发展也将推动技术革新，而Roblox作为世界上最大的社交平台和多人游戏平台之一，接下来将有望成为未来的Metaverse。
写在最后
至此，这篇接近4万字的《云原生时代》已接近尾声。
我们再来梳理下本文的核心观点：
- 云原生、中台、微服务、CI/CD、Devops、SaaS背后的理念是一致的
- 即更快速、更灵活、更轻量、更自动，从开发开始，不断实现企业的产品目标和业务目标
- 类似理念涉及的维度包括开发、产品、运维、销售，从产品、服务到组织结构
如何判断云原生技术层的项目？
- 是否拥有核心技术是关键
- 单点产品的价值和延展性要足够强。参照Rancher、HashiCorp、Kong
- 面向客户提供一整套产品化的解决方案具有更大价值
- 在云原生体系里，开源项目比普通商业项目更占优势。开源项目更容易被其它产品支持和集成；云原生架构早期使用者以开发者为主，开源项目更容易快速建立口碑和影响力；在社区支持下，开源项目质量更容易得到保证
- 尽量选择成熟和被市场验证的技术和产品
国内的创业机会是否已经到来？
国内已经出现了像PingCap、Kylin、SkyWalking、Dubbo、ServiceComb等优秀的开源项目，在云原生技术不断成熟和普及、国内开源文化和社区逐渐兴起、去IOE和自主可控的时代背景下，国内对标海外的创业机会将会不断涌现。不过由于国内企业IT水平参差不齐，像API集成、API管理等领域的创业时机尚早，所以选择合适的产品切入点和行业将成为成败的关键，另外团队对软件本质的理解、销售和客户服务能力也是相当重要的因素。
最后，我真心希望未来3到5年中国新一代的基础软件企业能够高举国产化的大旗，灯火辉煌。
参考
- 绿盟科技解读2019创新沙盒
- 被Palo Alto 4.1亿美元收购的Twistlock是一家什么公司？
- DETECTION ENGINEERING FOR CLOUD-NATIVE SECURITY
- 一文搞懂蓝绿发布、灰度发布和滚动发布
- 深入剖析Kubernetes学习笔记：“控制器”模型（16）
- 技术专栏 | 云原生应用之路
- 极简Docker和Kubernetes发展史
- Docker生态到底会不会重蹈Hadoop的覆辙
- 金丝雀发布、滚动发布、蓝绿发布到底有什么差别？关键点是什么？
- 15 Most Interesting Cloud Native Trends From The CNCF Survey
- 10分钟看懂Docker和K8S
- 极简Docker和Kubernetes发展史
- “中台不就是微服务吗？有啥区别？”
- 火热的云原生到底是什么？一文了解云原生四要素！
- 大神告诉你如何理解微服务框架
- Service Mesh 和 API Gateway 关系深度探讨
- 一文详解微服务架构
- Martin Fowler关于微服务的原文翻译（一）
- 微服务架构的理论基础 - 康威定律
- A text interpretation of the cloud native (rpm)
- 走访了十几家美国企业服务公司，我们写下了这篇万字文章 | GGV投资笔记第一期
- 从Uber微服务看最佳实践如何炼成？
- Mashape 和 RapidAPI 合并，组成全球最大的应用编程接口（API）集市！
- 放弃微服务，改用宏服务，Uber 这波什么操作？
- 腾讯大牛深入浅出详解云原生
- 【零壹视界】从Salesforce收购Mulesoft说起，白话讲讲企业数据交换
- EnjoyingSoft之Mule ESB开发教程第一篇：初识Mule ESB
- 微服务架构
- 持续集成、持续交付、持续部署
- 为什么你必须了解云原生？！
- What is Cloud-Native? Is It Hype or The Future of Software Development?
本文转载自：蒋宇捷的企业服务投资洞察。
- 云原生时代（一）云原生及CNCF基金会
- 云原生时代（二）：DevOps与CI/CD
- 云原生时代（三）：微服务、API管理与集成
- 云原生时代（四）：容器和Docker
- 云原生时代（五）：Kubernetes与容器编排之战
- 云原生时代（六）：机会与思考
