1. 概述

攻技者，短之；理论者，长之；践行者，胜之。能够这么说，一座城市的良心就体如今下水道上，不论这座城市有多少高楼大厦，建设得有多么宏伟，只要是下雨天，雨水就变成了城市良心的检验者。若是由城市建设来类比云原生体系的建设，那么云原生的良心又应该是什么？谁是云原生的暴风雨？谁又是云原生良心的检验者？
前端

云原生带来的业务价值很是多，主要有以下几条：

快速迭代：天下武功，惟快不破 。咱们想要在残酷的市场竞争中争得一席之地，就必须先发制人。云原生的本质就是帮助业务快速迭代，核心要素就是持续交付。
安全可靠： 云原生经过可观测机制，能够快速让咱们从错误中恢复，同时经过逻辑多租和物理多租等多种隔离方式，限制非法使用。
弹性扩展： 经过将传统的应用改造为云原生应用，作到弹性扩缩容，可以更好地应对流量峰值和低谷，而且达到降本提效的目的。
开源共建： 云原生经过技术开源可以更好地帮助云厂商打开云的市场，而且吸引更多的开发者共建生态，从一开始就选择了一条“飞轮进化”式的道路，经过技术的易用性和开放性实现快速增加的正向循环，又经过不断壮大的应用实例来推进了企业业务全面上云和自身技术版图的不断完善。

接下来，本文将由浅入深，从云原生的方方面面进行分析，包括基础的概念、经常使用的技术、一个完整的平台建设体系，让你们对云原生有个初步的了解。

2. 什么是云原生

2.1 云原生的定义
node

云原生的定义一直在发生变化，不一样的组织也有不一样的理解，比较出名的有 CNCF 和 Pivotal 。下面是 CNCF 的最新定义：

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

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

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。经过将最前沿的模式民主化，让这些创新为大众所用。

另外，做为云计算领导者，Heroku 的创始人 Adam Wiggins 整理了著名的云原生十二要素（The Twelve-Factor App：https://12factor.net/zh_cn/)。以后，一样做为云计算领导者，Pivotal (已被VMWare收购）的 Kevin Hoffman 出版了 Beyond the 12 factor App 一书，基于原十二要素新增了三个新要素，即云原生十五要素。

十五要素综合了他们关于 SaaS 应用几乎全部的经验和智慧，是开发此类应用的理想实践标准。十五要素适用于任何语言开发的后端应用服务，将流程自动化和标准化，下降新员工的学习成本；而且划清了与底层操做系统间的界限，以保证最大的可移植性。

下图可概览云原生全部的定义和特征：

2.2 云原生本质

从字面意思上来看，云原生能够分红云和原生两个部分。

云是和本地相对的，传统的应用必须跑在本地服务器上，如今流行的应用都跑在云端，云包含了 IaaS、PaaS 和 SaaS 。

原生就是土生土长的意思， 咱们在开始设计应用的时候就考虑到应用未来是运行在云环境上，要充分利用云资源的优势，好比️云服务的弹性和分布式优点。

云原生既包含技术（微服务、敏捷基础设施），也包含管理（DevOps、持续交付、康威定律、重组等）。云原生也能够说是一系列云技术、企业管理方法的集合。

1、云原生不是业务自己

好几我的问我云原生是什么，我会反问他们，若是你想本身的业务快速迭代，你但愿云原生是什么。云原生必定不是一个具体的东西，而是表明了如何追求问题的本质，它原本是什么，就是什么，它是一套方法论。

云原生的本质是帮助业务快速迭代，不是业务自己，不是技术堆叠，不是生搬硬套。咱们不该该看咱们有什么，而要看客户原本要的是什么。

那么云原生其实就是表明了科技的进步，咱们不光要提升新业务的迭代效率，还要打破旧业务的迭换效率。一个好的架构通常会兼容人类的愚蠢，因此这里的旧业务多是历史包袱，多是知识瓶颈带来的偏见。

咱们无时无刻都在变成旧，无时无刻都在创造新。人要勇于质疑本身，质疑过去，质疑权威，才有建立新的动力和洞见。

2、云原生不是云计算

云计算（Cloud Computing）和云原生（Cloud Native）有很大区别，主要体如今如下六个方面：

起源git

云原生应用程序源于云原生。如前所述，它们构建并部署在云中，真正地访问了云基础设施的强大功能。云计算应用程序一般是在内部使用传统基础设施开发的，而且通过调整后能够在云中远程访问。

设计

云原生应用程序被设计为多租户实例托管（微服务架构）。云计算应用程序在内部服务器上运行，所以它们没有任何多租户实例。

便捷性

云原生应用程序是高度可扩展性，能够对单个模块进行实时更改，而不会对整个应用程序形成干扰。云计算应用程序须要手动升级，从而会致使应用程序中断和关闭。

价格

云原生应用程序不须要任何硬件或软件上的投资，由于它们是在云上进行的，一般能够在被许可方得到，所以使用起来相对便宜。云计算应用程序一般比较昂贵，由于它们须要进行基础升级以适应不断变化的需求。

实现

因为不须要进行硬件或软件配置，云原生应用程序很容易快速实现。云计算应用程序须要定制特定的安装环境。

3、云原生自己是复杂的

云原生改变的不止是技术，最终去改变的是业务。云原生既然会帮助业务快速迭代，那么业务代码和项目流程必然会发生根本性变化。典型的就是业务愈来愈轻，底座愈来愈厚，数据处理愈来愈自动化，非人用户愈来愈多。
程序员

接下来，咱们能够从尤瓦尔赫拉利的三部简史来窥探下云原生的本质。

21 世纪随着人工智能的发展，人类社会将由人文主义逐渐过渡到数据主义。人类社会若是是一个比较大的数据网络，包括人类的情感都只是进化论选择下的生物算法，那么每个人只是其中的一个数据处理器，能够是智人，能够是虚拟人，也能够是将来的超人类。咱们能够拿共产主义和资本主义的区别来举例。共产主义是集中式算法，经过国家的数据网络计算每个人的需求再进行分配；资本主义是分布式算法，少数的资本家掌控大部分的社会资源。

能够说之前的数据是一个孤岛，部署在几个物理机上，管好本身就能够，不会影响别人。而今天不同，全部的应用都在线化，逐渐变成一个有生命力的资产后，应用的约束也会愈来愈严格和复杂，全部的数据流向及依赖彻底是你人为难以预期的。光铺人已经解决不了了。

云原生其实很复杂，本质是链接数据，将数据从杂乱无序处理为信息、知识、智慧。云原生的复杂来源于它想容纳更多复杂的事务和结构，但某一方面来讲，云原生其实又很简单，由于它给终端用户带来无穷无尽的便利和丰富功能，但又无需他们感知。复杂和简单是相对的， 底层越复杂，上层越简单。

3. 什么是云原生应用

什么是云原生应用呢？和云原生的关系又是什么？云原生应用的定义基本以下：
github

云原生应用，是指原生为在云平台上部署运行而设计开发的应用。云原生应用不仅是将应用打包成 Docker 镜像，并且须要将镜像部署到到 Kubernetes 容器云上运行。公平的说，大多数传统的应用，不作任何改动，都是能够在云平台运行起来的，只不过这种运行模式，不可以真正享受云的红利，咱们也叫作云托管（Cloud Hosting）应用。

另外，云原生应用有各类不一样的分类方式。根据业务场景，主要能够按照状态和职能进行分类。

3.1 按状态分类

云原生应用主要分为无状态应用（stateless）和有状态应用（stateful）两类。是否有无状态，主要体现为是否须要感知应用实例的状态，在 Kubernetes 中，应用实例即 Pod ，有状态应用本质上依赖于 Pod 的状态。

3.1.1 无状态应用

无状态应用就是不依赖本地运行环境的应用，实例间互相不依赖，能够自由伸缩。

无状态应用的特征：

无状态应用的实例可类比为牲畜，无名、可丢弃；
运行的实例不会在本地存储须要持久化的数据；
中止的实例全部信息（除日志和监控数据外）都将丢失。

3.1.2 有状态应用

有状态应用就是依赖本地运行环境的应用，实例之间有依赖和启动前后关系，须要作数据持久化，不能随意伸缩。

有状态应用的特征：

有状态应用的实例可类比为宠物、有名、不可丢弃；
实例升级和灰度对启停顺序的要求，如分布式选主；
依赖实例信息，如 ID、Name、IP、MAC、SN 等信息；
须要作数据持久化，依赖本地文件和配置。

3.1.3 无状态和有状态相互转化

有状态应用和无状态应用是能够相互转化的。大部分的中间件应用都是有状态应用，例如 ZooKeeper、RocketMQ、etcd、MySQL 等。大部分的业务应用都是无状态应用，例如 Web 类应用、查询类应用等。

1、无状态到有状态

好比一个比较简单的云产品，在公有云部署时，能够依赖公有云的基础设施，因此是无状态；但在专有云部署时，却须要本身解决环境和对其余BaaS的依赖，因此是有状态，这就是基础设施和运维方式不一样形成的差距。

通常状况下，咱们不提倡应用之间的依赖过于复杂，尤为在专有云场景下，复杂的依赖带来的环境问题至关多，拔萝卜带泥几乎要把整个公有云搬到专有云，不管对咱们仍是对客户，都是比较大的心智负担。

2、有状态到无状态

业务应用本质上都应该是有状态的，不过它能够借助中间件、运维 API、BaaS、Serverless 的能力，把有状态转嫁到了中间件上。而可以被转嫁成无状态应用的有状态应用又叫作“伪有状态应用”。

经过中间件改造为无状态

大部分业务应用能够使用公有云上的中间件产品来实现计算、存储、网络的能力。例如 Web 应用，能够使用 RDS 等数据库产品，经过BaaS能力开通和依赖RDS实例，只实现核心的业务逻辑便可。

经过运维 API 改造为无状态

有特殊运维逻辑的应用能够调用运维 API 转嫁运维的复杂性。例如 MetaQ 须要主备切换，这时候利用 Kubernetes 上的 etcd 提供的选主 API 给 MetaQ 实例进行打标， MetaQ 开发者就能够像无状态应用同样运维 MetaQ 了。

经过 Serverless 改造为无状态

对于业务逻辑很是简单的应用，不必定须要打包镜像，可直接经过各类 Serverless 平台进行开发，交给平台来进行运维。

为了更好的识别伪有状态，咱们应该从应用的本质而非状态去定义是否有无状态。而对于 ZooKeeper、etcd、MySQL 这种彻底依赖自身应用代码进行运维的中间件，就算是比较完全的有状态应用了，很难进行改造。

那么有状态到无状态的转化，有状态是消失了吗？有状态实际上是本质存在的，其实面向终态，不是说不去作一些运维操做，而是根据状态变化把这些运维操做，交给平台来处理，以期达到的指望状态，这个过程就是生命周期的运维了。不是有状态减小了，而是有状态不给用户暴露而已。 Kubernetes 其实帮你们解决了 Pod 的有状态。而对于有状态应用，咱们须要关注 Pod 的生命周期，把业务的 Operator 变成平台的 Operator ，就是有状态改造为无状态的主要工做量了。

在云原生体系下，咱们要尽可能试着把有状态应用转为无状态应用，这样能够尽最大能力地使用云原生的福利，把可观测和高可用都交给云平台去保障，而开发同窗只需关心离客户最近的业务。

随着技术的进步，有状态应用会不断变成无状态应用，只有少数缓存、消息、存储相关的中间件须要进行有状态运维，而且慢慢下沉到底层，后面通常人根本不须要了解两者的区别。

3.2 按职能分类

云原生中的应用若是按职能来区分，能够包含业务应用和运维应用两种。

3.2.1 业务应用

业务应用就是业务开发工程师经过 Java、Go、Python 等语言来开发业务代码，而后打包为镜像后部署的应用。业务应用主要用来解决业务问题，实现特定的业务功能。业务应用的交付物主要是镜像。

在 Serverless 平台中，业务应用也能够是一些函数代码，能够打镜像；也能够不打镜像，直接部署到多语言运行环境中。

3.2.2 运维应用

因为云原生重点须要解决应用运维自动化的问题，而业务应用没法解决自身运维的问题，即本身没法管理本身，因此须要运维应用来管理业务应用。

运维应用就是运维开发工程师用 YAML、Helm 等开发的运维代码，而后下发到 Kubernetes 上部署的应用。运维应用主要用来解决运维问题，实现特殊的运维逻辑。运维应用的交付物主要是 YAML 。

4. 云原生的理论探索

4.1 一切皆数据
web

其实从 DevOps 到 AIOps 之间，还有个 DataOps，Kubernetes 的面向终态就像是一个黑盒，让人不知道运行状态如何，就像一样能跑到终点，你跑得快仍是我跑得快没人知道，因此相对于面向终态又出现了可观测，用来衡量达到终态的过程是否完善，是否健康。

所以，咱们在平时的设计中必须具备数据思惟，进行更多的数据建模，不然可观测也是无米之炊。 咱们来看看云原生的各个环节中，都有哪些数据？

咱们须要编辑资源的配置，并经过 GitOps 或者 K8s 命令进行下发，也叫数据驱动，即一切皆配置数据；
资源的各类逻辑都须要执行一系列动做，执行动做能够有多种触发方式，即一切皆执行数据；
资源内部的生命周期须要编排，资源之间的依赖关系也须要编排，本质是编排执行动做，即一切皆编排数据；
K8s 是基于事件驱动的架构，K8s 上各类资源状态的变化，都会产生事件，即一切皆事件数据；
事件流即日志，业务记录即日志，动做变化即日志，结构化的日志是可观测的根本，即一切皆日志；
不管是配置指令、仍是依赖编排，亦或者是事件，都是围绕资源进行的，全部的 API 都是以资源这个主体进行调用，即一切皆资源数据。

4.2 多维业务组合论

常常有人跟我说，云原生的技术搞得如此火热，成天让咱们上云，除了节省成本外，为啥我没看出来对业务的快速交付有什么明显帮助呢？我认为多是你还没找到一套特别适合云原生时代的业务架构。

有人说汉语是世界上最优秀的表意语言，由于汉语是二维语言，基础词汇 2000 多个，其余举一反三，变幻无穷，形神俱佳，思惟面广阔。而英语只是一维语言，出现一个新事物，就得创造一个新单词，没有声调，同类事物的单词也看不出关联，但在表达非海量信息的领域比较擅长，好比编程、数理化表达式等。从这里能够类比得出结论，底层的技术用机器语言 0-1 比较便捷，而上层的业务就须要一个多维的业务模型。

能够这么说，云原生带来的是不只技术的发展，更是业务的深入变革，那么咱们现今有没有一套业务模型能指导云原生时代的复杂业务呢？

典型的如微服务架构，事件驱动架构、中台架构，但貌似都没法解决问题。笔者也进行了一些探索，发明出一套多维业务组合论，并以纵横图的方式来表征。

各个图形的含义：

纵横图：以纵横交错的线条和面积块来细分各个领域；
点：业务功能，业务组装的最小单位；
横向线：微平台，PaaS，服务主体单一；
纵向线：业务软件，SaaS；
圆柱体：业务领域或者技术领域；
面积块：解决方案或一站式工做台，可按租户、产品、服务控制权限。

咱们能够从图中看出每一个领域的隔离区域和拓展范围，纵横层会变得愈来愈多，领域也会分割地愈来愈细。

举个例子，有一个交易系统的应用，须要依赖消息队列和数据库，而且想部署到公有云的 Kubernetes 中。假设今天没有这些分层，那么负责这个交易系统的同窗，须要本身买公有云的机器，而后部署 Kubernetes ，再而后部署中间件，接着再部署交易系统，而且须要解决各类网络和稳定性问题，结果可想而知。

另外，咱们还能够从技术的发展来看纵横图的价值。技术发展得越快，业务同窗感受事情并无之前那么简单了。由于业务的复杂度在增长，同时对迭代速度要求更高。微服务、容器、中台不少概念都是为了加速创新。解耦是为了更好的组合，那如何来把控粒度呢？这其实能够从物理学的发展看出一二。理论上人类文明进化得越高，微观会更微，宏观会更宏，例如量子力学和相对论。因此粒度的大小是跟当今社会的创新能力相匹配的。

将来咱们要打技术生态，对于技术点的组合编排创新必然成为主旋律。能够这么说，单点技术很难发挥价值和沉淀下来，也极易被替换，靠作单点被集成去得到生态，这条路很难长久。一个好的平台，其中的任何一个技术点在都是可替换的。 技术编排的时代到来了，云原生的最终目标是解交付，而非成本，为了更快创新。

4.3 面向终态论

面向终态论，有点相似数据驱动论，让软件系统更加接近人类指令的终极理论。K8s中的面向终态，响应式编程中的数据驱动，让事件交给系统来管理，咱们只须要知道本身想要什么，而不用关心如何实现。

能够说，在整个 Kubernetes 设计理念中，面向终态是其核心理念，是运维自动化的关键。好比个人应用须要 10 个实例，这机器故障时，帮我自动跟换一台等，这些需求，经过声明后提交给系统，系统会自动化的完成这些用户指望的事情。而这种方式，就是一种面向终态的设计。面向终态设计的核心手段就是使用“声明式API”。

下面主要以 Deployment 为例，核心逻辑是把自定义 CR（MyApp）当作终态，把 Deployment 当作运行态，经过比对属性的不一致，编写相关的 Reconcile 逻辑。

一张图解释各类资源和 Controller 的关系：

从图中能够得出以下结论：

replicas在My-App CR和Deployment之间的流程是单向的；
My-App驱动Deployment，Deployment驱动Pod；
Pod的状态反馈到Deployment，Deployment的状态反馈到My-App，而后App的状态达到Running。

可是 Kubernetes 中的面向终态设计还不够完整，它并无设计各种资源整个生命周期的终态定义，例如如何定义资源状态机，如何依赖 BaaS 和 Config ，如何插入钩子，如何订阅事件并处理，如何设计完成度和健康度。

运维的本质是面向过程的，因此过程也须要定义。如同人的一辈子的终态是走向死亡，终态真的是咱们向往的吗？咱们须要去拓宽生命的宽度，寻找幸福的意义。云原生中的运维也是相似的，全部资源都有生命周期，有生命周期就有过程，有过程就有状态，有状态就有状态机。

4.4 中心管理论

云原生的本质在于链接业务或者数据，好比为了避免被云厂商锁定，就须要跨云；为了异地多活，就须要跨 Region ；边缘计算中为了简化管理或者组成逻辑集群，就须要跨 Kubernetes 集群。在这些场景下，中心化就是必然须要解决的问题。

能够这么说，大到一个国家，小到一个 ZooKeeper 选主，所谓的跨 XXX ，就必然有一个中心化的管理组织。通常来讲，咱们的物理隔离主要隔离的是数据中心，数据分为不少种，咱们主要关心用于调度的数据，调度的数据都是比较简单表征用户的指令，咱们把它叫作配置，因此云原生中的中心化管理须要一个全局的调度中心，全局配置中心，在复杂的场景下，能够在每个物理集群中加一个可接收和解析到指令的客户端 Agent 便可。例如 Prometheus 监控的设计就是如此，咱们须要在每个 node 节点加一个监控的 Agent 进行系统监控并搜集数据上报。

4.5 编排上移论

本身没法编排和管理本身，自身必定是自闭环的，因此总有更上一层的对象编排本身。例如全部的集群调度系统的架构都是没法横向扩展的，若是须要管理更多的服务器，惟一的办法就是建立多个集群；还有容器没法编排本身，因此出现了 Kubernetes ；再有就是在分布式选主中，master 只能有一个，若是有两个 master ，就不知道用哪一个实例管理了；又好比在同一个团队只能有一个主管，要是有两个主管，必然这两个主管上面还必须出现一个主管作最终的裁定。

另外，每一层的位置不是一成不变的，业务堆栈在逐渐上移，今天咱们认为复杂的事，将来会所有自动化掉。

解耦的关键在于自闭环，组合的关键在于编排，自动化的关键在于调度和调协。

在云原生中还有一个现象，就是不少功能都能引用到资源编排上去，例如云服务申请叫资源编排，运维调度叫资源编排，应用部署也叫资源编排。资源很大，编排也很大，资源+编排就是大上加大。 Kubernetes 里一切皆资源，机器是资源，存储和计算是资源，服务也是资源；一切组合都是编排，有依赖就有编排，连说人是非，也能说在编排谁谁？因此咱们在讲编排时，必定要加上一个限定词，不然会出现定位不清的问题。

另外，编排和调度、调协也有本质区别。举个例子，在容器平台中，虽然调度与编排同属一部分，但它们负责的内容并不相同，调度是将分布式系统中的闲置资源合理分配给须要运行的进程并采用容器进行封装的过程，编排则是对系统中的容器进行健康检查、自动扩缩容、自动重启、滚动发布等的过程。还有咱们在达到面向终态的过程当中，须要设计控制器对于资源的状态进行控制，这个过程就叫调协，更形象地说，在应用生命周期管理中，工做负载产生 Pod 是调度，挂载 Hook 是编排，消费 Event 是调协。

4.6 永不失败论

又叫依赖相对论，惟一永远不会失败的系统是那些让你活着的系统，你处在系统调用链的某个环节，相信你依赖的系统的稳定性，由它为你兜底。

下面拿业务应用的环境分层模型来举例，咱们将业务应用的环境分为测试环境、预发环境、生产环境，业务应用依赖中间件，中间件须要运行在 Kubernetes 上。通常状况下，业务应用依赖的底层基础设施环境通常都具备很高的可靠性，不然出大事了。因此你在测试本身的业务应用时，主要是测试本身的核心功能，须要相信本身的上游是稳定的，否则测试系统的设计将极其复杂。固然在监控链路中，须要监控与本身业务系统相关的上游系统问题，一旦出现报警，可以找上游系统的同窗来兜底。

4.7 生命周期论

软件的架构就是为了知足不断增加的业务需求，对原有的生命周期进行拆分，造成新的核心生命周期（主体不变）和非核心生命周期（主体变化），而非核心生命周期能够交由他人来完成，最后合并各子生命周期并发执行的结果，完成总的生命周期。

从技术的发展能够看出来，应用的粒度是越拆越小，更多技术上的代码都下沉到底层基础设施上去了。

能够绝不客气的说，在云原生应用平台上运维业务，主要包括 Pod 、配置、BaaS 应用、产品、解决方案等资源的运维。实现自动化的关键就是定义好每一个资源的生命周期，并编排每一个阶段的钩子和订阅事件进行消费。

4.8 降维打击论

近两年有个词很火，叫“降维打击”，“消灭你，与你无关”，出自科幻小说《三体》。大概意思是说，用高级生物去打低级世界的生物，一打一个准。用更通俗的语言表达，就是利用错位竞争的方式让你永远领先对手。在云原生中，不管是技术仍是业务，若是充满反叛精神，勇于创新，都可产生降维打击。降维打击的实现有三种路径：

量变到质变：从小到大，积少成多，创新是随时随地可发生的，到必定程度后，云原生对业务的影响是根本性的，是可见的；
跨维空降：从左到右，弯道超车，从一个行业转向另外一个关联的行业，好比一个作容器平台的团队，很容易转向作 APaaS ；
入口垄断：从上到下，隐藏底层实现，好比一个作技术平台的团队，原来用一个收费的组件，但发展起来后，颇有可能自研该组件，这个收费的组件就会受到很大的影响。

另外，咱们还能够根据不一样的业务场景，选择不一样的研发模式：

自底而上：先从底层开始，用 MVP 最小可用原则来开发业务系统。从小的技术点开始创新，到大的组合创新，最终符合云原生的终极目标，提升交付效率，缩短创新迭代的周期。
自顶而下：从业务视角逐渐下推技术架构，这样设计的系统不会偏离业务自己，重构的可能性也较小。
原生模式：原本是什么就应该用什么思路开发。举个例子，PaaS 的开发路径有 SaaS->PaaS、IaaS->PaaS、原生 PaaS 三种，那么哪一个会搞得更好？相信大多数人会选择原生 PaaS 。拿造车来讲，不能造个轮子就投入市场吧，而必须先有一辆能跑的车。

4.9 鸿沟理论

早在 1991 年 Jeffery Moore 针对高科技行业和高科技企业生命周期的特色，提出了著名的“鸿沟理论”。这个理论基于“创新传播学”，将创新性技术和产品的生命周期分为五个阶段：创新者（Innovator）、早期使用者（Early adopters）、早期大众（Early majority）、晚期大众（Late majority）、落后者（Laggard）。

Kubernetes 在 2017 年末成为容器编排事实标准，以后以其为核心的云原生生态持续爆发，在传播周期上能够说已经跨过鸿沟了，进入 Early majority 早期大众阶段，开始占领潜力巨大的主流市场。

4.10 飞轮理论

飞轮效应指为了使静止的飞轮转动起来，一开始你必须使很大的力气，一圈一圈反复地推，每转一圈都很费力，可是每一圈的努力都不会白费，飞轮会转动得愈来愈快。达到某一临界点后，飞轮的重力和冲力会成为推进力的一部分。这时，你无须再费更大的力气，飞轮依旧会快速转动，并且不停地转动。

飞轮效应其实也是复利效应，下面以 AWS 的崛起举个例子， AWS 的三大支柱业务就是让飞轮效应启动的关键：

超值的 prime 会员服务，每一年只要 99 美金，就能享受不少增值服务；
Markerplace 第三方卖家平台，除了亚马逊本身售卖的商品，其余卖家也能够进驻亚马逊直接售卖本身的商品；
AWS 云服务，它的主要功能是向大大小小的企业提供云服务，不管你是大公司仍是小企业，均可以把本身的整套 IT 系统创建在亚马逊云服务上，性能稳定。

5. 云原生的核心技术

云原生的技术发展十分之快，自从云原生理念提出之后，每一年都有层出不穷的新技术孵化，本章节主要介绍云原生的各类经常使用的开源技术。
算法

5.1 运维技术

从模板技术到配置技术，再到编程技术，运维的灵活性逐次加强。模板技术过于死板，没法抽象成现实世界的对象；编程技术虽然很灵活，可是复杂度十分高，增长了不少不可控因素，运维成本十分高。因此，从个人角度上理解，动态配置技术将来会逐渐代替模板技术，成为主流。

因此有着严格约束的语言好呢，仍是灵活万能的语言好呢？我认为跟它的使用场景有关，一味的统一只是抹杀了业务的丰富多彩，践行“通用就是无用”的理论。

5.1.1 模板技术

5.1.1.1 YAML

YAML 是一个可读性高，用来表达数据序列化的格式。在 Kubernetes 中，面向终态、数据驱动和声明式 API ，均是经过 YAML 来体现的。

可是 YAML 没法体现面向对象的设计思想，咱们很难将各类扁平的 YAML 碎片关联起来，也没法清晰地推测事务的发展轨迹。并且在 YAML 中嵌入 JSON 和其余脚本的方式，也在把该语言变成一个蹩脚的万能语言。为了解决 YAML 的一系列问题，社区逐渐发展出了各类加强 YAML 的技术，例如动态配置和运维框架等。若是 Kubernetes 是将来的操做系统，那么 YAML 就是将来的汇编语言。

官网： https://yaml.org/

5.1.1.2 Helm

Helm 是 Kubernetes 的软件包管理工具。但显然，它并不仅想成为一个包管理工具，同时它还包含模板渲染、简单的依赖配置。

Helm 依旧延续了 YAML 的缺点，只是简单的把 YAML 堆在了一块儿。同时复杂的模板语法调试成本极高，例如各类流程控制结构结合空格缩进问题，对于眼神很差的人简直是个灾难。

官网： https://helm.sh/

5.1.1.3 KUDO

Kubernetes Universal Declarative Operator，提供了一种经过声明式构建产品级Kubernetes Operator。针对 Kubernetes 对工做负载作了一些简单的自动化加强以外，还须要一些更复杂的场景须要手动解决，而 KUDO 就是用于来帮助开发人员全面自动化的方式。

KUDO 的包结构和 Helm 比较相似，可是在 Helm 的基础上增长了资源的执行计划编排，编排的动做相对于 Helm 只有 Apply ，还增长了 Delete、Toggle 等。

官网： https://kudo.dev/

5.1.1.4 MetaController

Metacontroller 是一个封装了自定义控制器所需的大部分基础功能的针对 Kubernetes 的扩展服务。当你经过 Metacontroller 的 API 去建立一个自定义的控制器时，你仅须要在你的控制器中提供一个你所须要的业务逻辑函数。这些业务逻辑函数会经过 webhooks 的方式被触发。

MetaController 看起来配置简洁，可是却想借技术手段解决业务问题，且解决的有限，目前主要包括两种手段：

一是为一组对象构建复合对象的控制器；二是为已经存在的对象添加新的行为。

官网： https://metacontroller.app/

5.2.2 配置技术

5.2.2.1 CUE

CUE，发音为 Q ，是一种通用且基于约束的强类型语言，旨在简化涉及定义和使用数据的任务。CUE受到多种语言的影响，例如 BCL、GCL、LKB、Go、JSON、Swift、Typescript、Javascript、Prolog、Jsonnet、HCL、Flabbergast、Nix、JSONPath、Haskell、Objective-C 和 Python 等。

CUE 设计时考虑了云配置和相关系统，但不限于此域。它从关系编程语言中衍生出其形式主义，同时 CUE 延续了 JSON 超集的思路，在技术方面的关键创新在于基于集合论实现了类型设计，能够说是 BCL 思路的一种开源版实现。目前 CUE 的生态还不是很强大，没有配套的开发工具，可是好在阿里的多个团队正在积极研发它。

官网： https://cuelang.org/

5.2.2.2 Jsonnet

Jsonnet 是 Google 开源的一门配置语言，用于弥补 JSON 所暴露的短板，它彻底兼容 JSON ，并加入了 JSON 所没有的一些特性，包括注释、引用、算数运算、条件操做符、数组和对象深刻、引入函数、局部变量、继承等，Jsonnet 程序被编译为兼容 JSON 的数据格式。简单来讲 Jsonnet 就是加强版 JSON 。

Jsonnet 的生态比较完善，不管 Jsonnet 文件仍是 Libsonnet 都有开发工具，而且还有开源的 UI 组件。目前 Promethus 和 Kubeless 都使用了该动态配置语言。

官网： https://jsonnet.org/

5.2.2.3 HCL

HCL 是 HashiCorp 构建的配置语言。HCL 的目标是构建一种人机友好的结构化配置语言，以与命令行工具一块儿使用，但专门针对 DevOps 工具，服务器等。HCL 也彻底兼容 JSON 。也就是说 JSON 能够用做指望使用 HCL 的系统的彻底有效输入。这有助于使系统与其余系统互操做。

官网： https://github.com/hashicorp/hcl

5.2.2.4 Kusion

Kusion 主要是基于云原生基础设施的高级专用语言及工具链，在不可变业务镜像外提供 "Compile to Cloud" 的完整技术栈支持。Kusion 由 KCL 语言及工具链，KusionCtl 工具，Kusion-Models SDK 及 OCMP 实践定义四部分组成。

KCL 是一种专用于配置定义、校验的动态强类型配置语言，重点服务于 configuration & policy programing 场景，以服务云原生配置系统为设计目标，但做为一种配置语言不限于云原生领域。KCL 吸取了声明式、OOP 编程范式的理念设计，针对云原生配置场景进行了大量优化和功能加强。

Kusion 由阿里内部研发，目前还没有开源。

5.1.3 编程技术

5.1.3.1 Operator

Operator 是 CoreOS 推出的旨在简化复杂有状态应用管理的框架，它是一个感知应用状态的控制器，经过扩展 Kubernetes API 来自动建立、管理和配置应用实例。

一个 Operator 工程通常必须包含 CRD 和 Controller，Webhook 是可选的。若是说 Kubernetes 是 "操做系统" 的话，Operator 是 Kubernetes 的第一层应用，使用 Kubernetes "扩展资源" 接口的方式向更上层用户提供服务。Operator 的实现方式主要包括 OperatorSDK 和 KubeBuilder ，目前 KubeBuilder 在阿里使用的比较多。

KubeBuilder： https://github.com/kubernetes-sigs/kubebuilder

OperatorSDK： https://github.com/operator-framework/operator-sdk

5.1.3.2 OperatorPlatform

但愿经过设计一个通用化的 Operator 平台来解决原生Operator的各类问题，这个平台的核心目标包括：

简化、标准化 Operator 编写（多语言、简化框架、下降用户门槛）；
下沉 Operator 核心能力、统一管控（中心管控全部用户 Operator）；
提高用户 Operator 性能（水平扩展、多集群、精简缓存）；
控制 Operator 灰度及运行时的风险（完善监控、灰度回滚能力、控制爆炸半径、权限控制，访问限制）。

OperatorPlatform 由阿里内部研发，目前还没有开源。

5.1.3.3 Pulumi

Pulumi 是一个架构即代码的开源项目，可在任何云上建立和部署使用容器，无服务器功能，托管服务和基础架构的云软件的最简单方法。Pulumi 采用了基础设施即代码以及不可变基础设施的概念，并可以让您从您最喜欢的语言（而不是 YAML 或 DSL）中得到自动化和可重复性优点。

Pulumi 的中心是一个云对象模型，与运行时相结合以了解如何以任何语言编写程序，理解执行它们所需的云资源，而后以强大的方式规划和管理您的云资源。这种云运行时和对象模型本质上是与语言、云中立的，这就是为何咱们可以支持如此多的语言和云平台。

官网： https://www.pulumi.com/

5.1.3.4 Ballerina

Ballerina 是一款开源的编译式的强类型语言。Ballerina是一种开放源代码编程语言和平台，供云时代的应用程序程序员轻松编写能够正常运行的软件。Ballerina 是语言和平台的组合设计，敏捷且易于集成，旨在简化集成和微服务编程。

Ballerina 是一种旨在集成简化的语言。基于顺序图的交互，Ballerina 内置了对通用集成模式和链接器的支持，包括分布式事务、补偿和断路器。凭借对 JSON 和 XML 的一流支持，Ballerina 可以简单有效地构建跨网络终端的强大集成。

官网： https://ballerina.io/

5.1.3.5 CDK8S

CDK8S 是 AWS Labs 发布的一个使用 TypeScript 编写的新框架，它容许咱们使用一些面向对象的编程语言来定义 Kubernetes 的资源清单，CDK8S最终也是生成原生的 Kubernetes YAML 文件，因此咱们能够在任何地方使用CDK8S来定义运行的 Kubernetes 应用资源。

官网： https://cdk8s.io/

5.1.3.6 Terraform

Terraform 是一个构建、变动、和安全有效的版本化管理基础设施的工具。Terraform 能够管理已存在和流行的服务提供商以及定制的内部解决方案。Terraform 的特性包括：架构就是代码、执行计划、资源图、变动自动化等。

官网： https://www.terraform.io/

5.1.4 应用技术

5.1.4.1 OAM

以应用程序为中心的标准，用于构建云原生应用程序平台。OAM 综合考虑了在公有云、私有云以及边缘云上应用交付的解决方案，提出了通用的模型，让各平台能够在统一的高层抽象上透出应用部署和运维能力，解决跨平台的应用交付问题。

OAM 的核心理念以下：

第一个核心理念是组成应用程序的组件（Component），它可能包含微服务集合、数据库和云负载均衡器；
第二个核心理念是描述应用程序运维特征（Trait）的集合，例如，弹性伸缩和 Ingress 等功能。它们对应用程序的运行相当重要，但在不一样环境中其实现方式各不相同；
最后，为了将这些描述转化为具体的应用程序，运维人员使用应用配置（Application Configuration）来组合组件和相应的特征，以构建应部署的应用程序的具体实例

官网： https://oam.dev/

5.1.4.2 KubeVela

KubeVela 是一个简单易用且高度可扩展的应用管理平台与核心引擎。KubeVela 是基于 Kubernetes 与 OAM 技术构建的。对于应用开发人员来说，KubeVela 是一个很是低心智负担的云原生应用管理平台，核心功能是让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，无需了解任何 Kubernetes 自己相关的细节。在这一点上，KubeVela 能够被认为是云原生社区的 Heroku。

官网： https://oam.dev/

5.1.4.3 OpenKruise

OpenKruise 是 Kubernetes 的一个标准扩展，它能够配合原生 Kubernetes 使用，并为管理应用容器、Sidecar、镜像分发等方面提供更增强大和高效的能力。OpenKruise包括如下资源：

CloneSet：提供更加高效、肯定可控的应用管理和部署能力，支持优雅原地升级、指定删除、发布顺序可配置、并行/灰度发布等丰富的策略。
Advanced StatefulSet：基于原生 StatefulSet 之上的加强版本，默认行为与原生彻底一致，在此以外提供了原地升级、并行发布（最大不可用）、发布暂停等功能。
SidecarSet：对 Sidecar 容器作统一管理，在知足 Selector 条件的 Pod 中注入指定的 Sidecar 容器。
UnitedDeployment：经过多个 Subset Workload 将应用部署到多个可用区。
BroadcastJob：配置一个 Job，在集群中全部知足条件的 Node 上都跑一个 Pod 任务。
Advanced DaemonSet：基于原生 DaemonSet 之上的加强版本，默认行为与原生一致，在此以外提供了灰度分批、按 Node label 选择、暂停、热升级等发布策略。

官网： https://openkruise.io/

5.2 微服务

5.2.1 BaaS

BaaS 即指业务应用依赖的后台服务，它须要有一个服务目录，供用户选择须要使用的中间件，而后经过 BaaS Plan 选择规则，再建立完服务实例后，再经过 BaaS Connector 和 BaaS 的 Endpoint 绑定。更多原理能够参看云原生应用平台的服务中心章节。

5.2.1.1 Service Catalog

服务目录是 Kubernetes 社区的孵化项目 Kubernetes Service Catalog 项目，旨在接入和管理第三方提供的 Service Broker ，使 kubernetes 上托管的应用能够使用 Service Broker 所代理的外部服务。

官网： https://github.com/kubernetes-sigs/service-catalog

5.2.1.2 Open Service Broker

Open Service Broker API 项目使独立软件供应商，SaaS 提供者和开发人员能够轻松地为运行在 Cloud Foundry 和 Kubernetes 等云原平生台上的工做负载提供支持服务。该规范已被许多平台和数千个服务提供商采用，它描述了一组简单的API端点，可用于提供，获取和管理服务产品。该项目的参与者来自 Google，IBM，Pivotal，Red Hat，SAP 和许多其余领先的云公司。

官网： https://www.openservicebrokerapi.org/

5.2.1.3 Spring Cloud Connector

Spring Cloud Connector 为在云平台上运行的基于 JVM 的应用程序提供了一个简单的抽象，能够在运行时发现绑定的服务和部署信息，而且支持将发现的服务注册为 Spring Bean 。它基于插件模型，以便相同的编译应用程序能够在本地或任何多个云平台上进行部署，并经过 Java 服务提供程序接口（SPI）支持定制服务定义。

官网： https://cloud.spring.io/spring-cloud-connectors/

5.2.2 Service Mesh

Service Mesh 直译过来是服务网格，目的是解决系统架构微服务化后的服务间通讯和治理问题。服务网格由 Sidecar 节点组成。

5.2.2.1 Istio

Istio 提供一种简单的方式来为已部署的服务创建网络，该网络具备负载均衡、服务间认证、监控等功能，而不须要对服务的代码作任何改动。Istio的能力以下：

Istio 适用于容器或虚拟机环境（特别是 K8s），兼容异构架构。
Istio 使用 Sidecar（边车模式）代理服务的网络，不须要对业务代码自己作任何的改动。
HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
Istio 经过丰富的路由规则、重试、故障转移和故障注入，能够对流量行为进行细粒度控制；支持访问控制、速率限制和配额。
Istio 对出入集群入口和出口中全部流量的自动度量指标、日志记录和跟踪。

目前 AliMesh 和 ASM 都使用的是 Istio 方案。

官网： https://istio.io/

5.2.2.2 linkerd

linkerd 是一个透明的服务网格，旨在经过透明地将服务发现、负载均衡、故障处理，插桩和路由添加到全部的服务间通讯中，使现代应用程序安全可靠，而无需侵入应用内部自己的实现。

linkerd 做为一个透明的 HTTP/gRPC/thrift/ 等代理，一般能够以最少的配置被加入到现有的应用程序中，无论这些应用程序采用什么语言编写。linkerd 能与许多通用协议和服务发现后端运行，包括 Mesos 和 Kubernetes 等预约好的环境。

官网： https://linkerd.io/

5.2.3 Micro Service Framework

5.2.3.1 Dapr

Dapr 是微软开发的开源的、可移植的、事件驱动的应用运行时，它使开发人员能够轻松地构建弹性的、微服务的无状态和有状态的应用，这些应用运行在云端和边缘之上。Dapr 做为 Sidecar 更像微服务的运行时，为程序提供原本不具有的功能。Dapr 的主要功能以下：

服务调用：弹性服务与服务之间（service-to-service）调用能够在远程服务上启用方法调用，包括重试，不管远程服务在受支持的托管环境中运行在何处。
状态管理：经过对键 / 值对的状态管理，能够很容易编写长时间运行、高可用性的有状态服务，以及同一个应用中的无状态服务。
在服务之间发布和订阅消息：使事件驱动的架构可以简化水平可扩展性，并使其具有故障恢复能力。
事件驱动的资源绑定：资源绑定和触发器在事件驱动的架构上进一步构建，经过从任何外部资源（如数据库、队列、文件系统、blob 存储、webhooks 等）接收和发送事件，从而实现可扩展性和弹性。
虚拟角色：无状态和有状态对象的模式，经过方法和状态封装使并发变得简单。Dapr 在其虚拟角色（Virtual Actors）运行时提供了许多功能，包括并发、状态、角色激活 / 停用的生命周期管理以及用于唤醒角色的计时器和提醒。
服务之间的分布式跟踪：使用 W3C 跟踪上下文（W3C Trace Context）标准，轻松诊断和观察生产中的服务间调用，并将事件推送到跟踪和监视系统。

官网： https://dapr.io/

5.2.3.2 Dubbo

Dubbo 是阿里巴巴开源的基于 Java 的高性能 RPC（一种远程调用）分布式服务框架（SOA），致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。目前阿里内部使用的 HSF 也将逐渐被 Dubbo代替。

官网： http://dubbo.apache.org/

5.2.3.3 Spring Cloud

Spring Cloud 为开发者提供了在分布式系统（如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 Token、全局锁、决策竞选、分布式会话和集群状态）操做的开发工具。使用 Spring Cloud 开发者能够快速实现上述这些模式。

目前阿里基于原生 Spring Cloud 框架再加上阿里中间件作了一版加强，叫作 Spring Cloud Alibaba 。

Spring Cloud： https://spring.io/projects/spring-cloud

Spring Cloud Alibaba： https://spring.io/projects/spring-cloud-alibaba

5.3 Serverless

Serverless 本质上是不须要别人感知服务器，能够根据不一样的无服务器场景分为Kubernetes Serverless、App Serverless、BaaS Serverless、FaaS Serverless、Data Serverless 等。

Serverless 在非容器时代，在大数据和人工智能领域，已经获得必定程度的发展，例如阿里内部的 ODPS、TPP 等平台；可是容器时代的到来，更是大大加速了 Serverless 的发展。

还有，Serverless 在前端领域发展的十分风骚，出现了各类各样易用性很是好的Serverless 平台。

5.3.1 Cloud Events

CloudEvents 是一种规范，用于以通用格式描述事件数据，以提供跨服务、平台和系统的交互能力。

事件格式指定了如何使用某些编码格式来序列化 CloudEvent。支持这些编码的兼容 CloudEvents 实现必须遵循在相应的事件格式中指定的编码规则。全部实现都必须支持 JSON 格式。

官网： https://cloudevents.io/

5.3.2 Serverless Framework

Serverless Framework 是业界很是受欢迎的无服务器应用框架，开发者无需关心底层资源便可部署完整可用的 Serverless 应用架构。Serverless Framework 具备资源编排、自动伸缩、事件驱动等能力，覆盖编码-调试-测试-部署等全生命周期，帮助开发者经过联动云资源，迅速构建 Serverless 应用。

官网： https://github.com/serverless/components/blob/master/README.cn.md

5.3.3 FaaS Serverless

5.3.3.1 Kubeless

Kubeless 是一个基于 Kubernetes 的 Serverless 框架，容许您部署少许代码，而无需担忧底层基础架构管道。它利用 Kubernetes 资源提供自动扩展、API 路由、监控、故障排除等功能。Kubless 有三个核心概念：

Function：表明须要被执行的用户代码，同时包含运行时依赖、构建指令等信息；
Trigger：表明和函数关联的事件源。若是把事件源比做生产者，函数比做执行者，那么触发器就是联系二者的桥梁；
Runtime：表明函数运行时所依赖的环境。

官网： https://kubeless.io/

5.3.3.2 Nuclio

Nuclio 是专一于数据，I/O 和计算密集型工做负载的高性能“无服务器”框架。它与 Jupyter 和 Kubeflow 等流行的数据科学工具很好地集成在一块儿；支持各类数据和流媒体源；并支持经过 CPU 和 GPU 执行。Nuclio 项目于 2017 年开始，而且一直在迅速发展。许多初创企业和企业如今都在生产中使用Nuclio。

Jupyter： https://jupyter.org/

Kubeflow： https://www.kubeflow.org/

官https://fission.io/网： https://nuclio.io/

5.3.3.3 Fission

Fission 是由私有云服务提供商 Platform9 领导开源的 serverless 产品，它借助 kubernetes 灵活强大的编排能力完成容器的管理调度工做，而将重心投入到 FaaS 功能的开发上，其发展目标是成为 AWS lambda 的开源替代品。Fission包含三个核心概念：

Function：表明用特定语言编写的须要被执行的代码片断。
Trigger：用于关联函数和事件源。若是把事件源比做生产者，函数比做执行者，那么触发器就是联系二者的桥梁。
Environment：用于运行用户函数的特定语言环境。

官网： https://fission.io/

5.3.3.4 OpenFaas

OpenFaas 是一个受欢迎且易用的无服务框架（虽然在上表中不及 OpenWhisk）。但它不像 OpenWhisk 那么受欢迎，并且代码的提交都是基于我的进行的。除了我的开发者在业余时间的贡献外，VMWare 还聘请了一个团队在全职维护 OpenFaas。

官网： https://www.openfaas.com/

5.3.3.5 OpenWhisk

OpenWhisk 是一个成熟的无服务框架，而且获得 Apache 基金会和 IBM 的支持。IBM 云函数服务也是基于 OpenWhisk 构建的。主要提交者都是 IBM 的员工。OpenWhisk 利用了 CouchDB、Kafka、Nginx、Redis 和 ZooKeeper，有不少底层的组件，因此增长了必定的复杂性。

官网： https://openwhisk.apache.org/

5.3.3.6 FnProject

Fn是能够运行在用户侧或者云端的容器原生的无服务器计算平台。它须要使用 Docker 容器。该项目主要的贡献者都来自于 Oracle。还有一个叫 Fn Flow 的新功能，它能够用来编排多函数，相似 OpenWhisk。

官网： https://fnproject.io/

5.3.3.7 Serverless Devs

Serverless Devs 是阿里巴巴首个开源的 Server less 开发者平台，也是业内首个支持主流 Serverless 服务/框架的云原生全生命周期管理的平台。经过该平台，开发者能够一键体验多云 Serverless 产品，极速部署 Serverless 项目。

官网：https://www.serverless-devs.com/#/home

5.3.4 App Serverless

5.3.4.1 Knative

Knative 是谷歌开源的 Serverless 架构方案，旨在提供一套简单易用的 Serverless 方案，把 Serverless 标准化。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，2018 年 7 月 24 日才刚刚对外发布，当前还处于快速发展的阶段。Knative 是为了解决容器为核心的 Serverless 应用的构建、部署和运行的问题。此外，Knative原始的 Build 功能已经被废弃，被 Tekton 代替。

官网： https://knative.dev/

5.4 CI/CD

5.4.1 GitOps

GitOps 是一种快速、安全的方法，可供开发或运维人员维护和更新运行在 Kubernetes 或其余声明式编排框架中的复杂应用。GitOps 的四个原则以下：

以声明的方式描述整个系统；
系统的目标状态经过 Git 进行版本控制；
对目标状态的变动批准后将自动应用到系统；
驱动收敛 & 上报偏离。

对于没有管控系统，须要暂时用黑屏操做的同窗来讲，能够选择 GitOps ；若是有管控系统，不建议使用 GitOps ，不然你须要保证管控的数据库、Git 的文件、Kubernetes的运行时文件的状态的一致性，中间多了一个环节，出错概率高。

5.4.2 Argo

Argo 是一个云原生的工做流/流水线引擎，Argo 工做流以CRD形式实现。Argo工做流的每一个步骤，都是一个容器。多步骤的工做流建模为任务的序列，或者基于DAG来捕获任务之间的依赖。Argo 主要包括如下功能：

Argo Workflows：声明式的工做流引擎；
Argo CD：声明式的 GitOps 持续交付；
Argo Events：基于事件的依赖管理；
Argo Rollouts：支持灰度、蓝绿部署的 CR 。

因为 Argo 的每一个步骤都是 Pod ，极其占用服务器资源，对于生产级业务系统，须要谨慎使用。

官网： https://argoproj.github.io/

5.4.3 Tekton

Tekton 是一个功能强大且灵活的 Kubernetes 原生框架，用于建立 CI/CD 系统。经过抽象出底层实现细节，容许开发者跨多云环境或本地系统进行构建、测试与部署。Tekton 总体的架构抽象很是棒，基本能解决全部容器下的编排问题。

但一样每一个步骤都是 Pod ，跟 Argo 同样极其占用资源。

官网： https://github.com/tektoncd

5.5 集群管理

5.5.1 Federation

Kubernetes Federation（如下简称KubeFed）容许您经过托管集群中的一组 API 来协调多个 Kubernetes 集群的配置。 KubeFed 的目的是提供一种机制，用于表达应管理哪些集群及其配置以及应该如何配置的集群。KubeFed 提供的机制是有意的底层机制，旨在为更复杂的多集群用例（例如部署多地理位置应用程序和灾难恢复）奠基基础。

官网： https://github.com/kubernetes-sigs/kubefed

5.5.2 K3S

K3S 是一个轻量级Kubernetes，它易于安装，二进制文件包小于40MB，只须要512MB RAM 便可运行。它很是适用于 Edge、IoT、CI、ARM 等场景。K3S 是Rancher 出品的一个简化、轻量的 K8s ，从名字上也能看出，K3s 比 K8s 少了些东西。

官网： https://k3s.io/

5.5.3 K9S

K9S 提供了一个终端 UI 与您的 Kubernetes 集群进行交互。该项目的目的是简化浏览，观察和管理应用程序的过程。K9S 持续监视 Kubernetes 的更改，并提供后续命令与您观察到的资源进行交互。 K9S 是一款管理员们喜欢的 “单一屏幕” 实用程序，K9S提供了一个基于 curses 的全屏终端 UI ，可与您的 Kubernetes 集群进行交互。

官网： https://k9scli.io/

5.5.4 Minikube

Minikube 是一个易于在本地运行 Kubernetes 的工具，可在你的笔记本电脑上的虚拟机内轻松建立单机版 Kubernetes 集群。便于尝试 Kubernetes 或使用 Kubernetes 平常开发。Minikube 至关于一个运行在本地的 Kubernetes 单节点，咱们能够在里面建立 Pods 来建立对应的服务。

官网： https://minikube.sigs.k8s.io/

5.5.5 OpenYurt

OpenYurt 主打“云边一体化”概念，依托 Kubernetes 强大的容器应用编排能力，知足了云-边一体化的应用分发、交付、和管控的诉求。OpenYurt 能帮用户解决在海量边、端资源上完成大规模应用交付、运维、管控的问题，并提供中心服务下沉通道，实现和边缘计算应用的无缝对接。在设计 OpenYurt 之初，咱们就很是强调保持用户体验的一致性，不增长用户运维负担，让用户真正方便地 “Extending your native kubernetes to edge”。

官网： https://openyurt.io/en-us/

5.6 PaaS

5.6.1 OpenShfit

OpenShift 是红帽开发的云开发平台即服务（PaaS）。自由和开放源码的云计算平台使开发人员可以建立、测试和运行他们的应用程序，而且能够把它们部署到云中。 Openshift 普遍支持多种编程语言和框架，如 Java，Ruby 和 PHP 等。另外它还提供了多种集成开发工具如 Eclipse integration，JBoss Developer Studio和 Jenkins等。OpenShift 只部署 Operator 应用，并提出了 Operator 成熟度，有本身的 Operator 应用定义模板。相对其余容器平台来讲，仍是比较轻的。

官网： https://www.openshift.com/

5.6.2 CloudFoundry

Cloud Foundry 是 Pivotal 公司开发的业界第一个开源 PaaS 云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员可以在几秒钟内进行应用程序的部署和扩展，无需担忧任何基础架构的问题。

Cloud Foundry 和 Spring Cloud Connector 结合，对于 Spring 应用的服务依赖问题支持得很是好。可是 Cloud Foundry 至关重，在容器时代以前就存在了，运维难度很高，要谨慎使用。

官网： https://www.cloudfoundry.org/

5.6.3 KubeSphere

KubeSphere 是 QingCloud 开发的基于 Kubernetes 构建的分布式、多租户、多集群、企业级开源容器平台，具备强大且完善的网络与存储能力，并经过极简的人机交互提供完善的多集群管理、CI / CD 、微服务治理、应用管理等功能，帮助企业在云、虚拟化及物理机等异构基础设施上快速构建、部署及运维容器架构，实现应用的敏捷开发与全生命周期管理。

KubeSphere 可谓是业届的良心之做，交互体验十分棒，功能也很完善，和 App Matrix 几乎承担了 QingCloud 的全部业务应用和云产品的运维。而目前的阿里云云产品基本都是垂直化的运维系统。

Demo（demo1 / Demo123）： https://demo.kubesphere.io/

官网： http://kubesphere.qingcloud.com/

5.6.4 Azure

Azure 是微软开发的基于云计算的操做系统，原名“Windows Azure”，和 Azure Services Platform 同样，是微软“软件和服务”技术的名称。Microsoft Azure的主要目标是为开发者提供一个平台，帮助开发可运行在云服务器、数据中心、Web 和 PC 上的应用程序。另外，经过 Azure 的 Service Fabric ，可轻松开发、打包、部署和管理可缩放且可靠的微服务（或者非微服务）。

官网： https://azure.microsoft.com/zh-cn/

5.6.5 Anthos

Anthos 是 Google 开发的以 Kubernetes 为核心的混合云/多云管理平台，主要做用是保护客户的网络链接和应用程序，并以容器化的部署形式，提供云服务支撑能力。它的开发是由于客户但愿使用单一的编程模型，这使他们能够选择并灵活地将工做负载转移到 Google Cloud 和其余云平台（如 Azure 和 AWS）而不作任何更改。

官网： https://www.anthos.org/

5.6.6 Heroku

Heroku 是 Salesforce 旗下云服务商，提供方便便捷的各类云服务，如服务器、数据库、监控、计算等。而且它提供了免费版本，这使得咱们这些平时想搞一些小东西的人提供了莫大的便捷，虽然它有时长和宕机的限制，可是对于我的小程序来讲已经足够了。

官网： https://www.heroku.com/

5.6.7 Crossplane

Crossplane 是 Upbond 公司开发的一个开源的多云平台控制面板，用于跨环境、集群、区域和云，管理你的云原生应用程序和基础设施。Crossplane 能够安装到现有的 Kubernetes 集群中，以添加托管服务供应，或者做为多集群管理和工做负载调度的专用控制平面部署。

目前，OAM 和 Crossplane 社区共同致力于建设一个聚焦在标准化的应用和基础设施上的开放社区。

官网： https://crossplane.io/

5.6.8 Rancher

Rancher 是供采用容器的团队使用的完整软件堆栈。它解决了在任何基础架构上管理多个 Kubernetes 集群的运营和安全挑战，同时为 DevOps 团队提供了用于运行容器化工做负载的集成工具。

Rancher 的 Rio 是一种 MicroPaaS ，能够在任何标准 Kubernetes 集群之上进行分层。用户能够轻松地将服务部署到Kubernetes并自动得到持续交付，DNS，HTTPS，路由，监控，自动扩展，Canary 部署，Git 触发构建等等。全部这一切只须要 Kubernetes 集群和 Rio CLI 。

官网： https://rancher.com/

5.7 大数据与AI

5.7.1 Kubeflow

Kubeflow 是谷歌发布的一个机器学习工具库，Kubeflow 项目旨在使 Kubernetes 上的机器学习变的轻松、便捷、可扩展，其目标不是重建其余服务，而是提供一种简便的方式找到最好的 OSS 解决方案。

官网： https://www.kubeflow.org/

5.7.2 Fluid

Fluid 是一款开源的云原生基础架构项目。在计算和存储分离的大背景驱动下，Fluid 的目标是为 AI 与大数据云原生应用提供一层高效便捷的数据抽象，将数据从存储抽象出来，以便达到如下目的：

经过数据亲和性调度和分布式缓存引擎加速，实现数据和计算之间的融合，从而加速计算对数据的访问；
将数据独立于存储进行管理，而且经过 Kubernetes 的命名空间进行资源隔离，实现数据的安全隔离；
未来自不一样存储的数据联合起来进行运算，从而有机会打破不一样存储的差别性带来的数据孤岛效应。

官网： https://github.com/fluid-cloudnative/fluid

5.7.3 KubeTEE

KubeTEE 是一个云原生大规模集群化机密计算框架，旨在解决在云原生环境中 TEE 可信执行环境技术特有的从开发、部署到运维总体流程中的相关问题。KubeTEE 是云原生场景下如何使用 TEE 技术的一套总体解决方案，包括多个框架、工具和微服务的集合。

官网： https://github.com/SOFAEnclave/KubeTEE

6. 云原生存在的问题

1. 无状态真的是万能的吗？spring

咱们虽然倡导应用都应该改形成无状态应用，例如 Kubernetes 中的 Deployment 就是专门针对于无状态应用的，部分状态机框架也推荐 Pipeline 也应该设计成无状态的，还有 FaaS 中的 Function 也基本都是无状态的，可是无状态真的是万能的吗？例如一些须要查库进行大量计算的高 QPS 的 Function，若是能把数据缓存在本地，是否会更好些呢？数据库

2. 一处接入，到处运行是否真的可行？apache

能够说云原生的技术堆栈在不断上移，愈来愈接近业务。例如应用运维，咱们原来想创造一门技术，到处通吃，只要中间件接入一个应用平台，随着这个应用平台就能输出到各类公有云和专有云中。可是经过很长时间的实践，咱们发现不一样的客户要求不一样，还有各类云基础设施的差别，基本很难“一处接入，到处运行”。盲目地去搞大一统，只会陷入一个到处不行的大泥坑中。

3. 中台难在哪里？

中台理论既然能提出，必然是符合当时的业务背景的。那么为啥后来的实践却不怎么理想呢？我粗浅地认为，主要问题在于根深蒂固的 To C基因，很难用一个大而全的业务理论去改变。咱们还须要继续探索，从业务和技术两个方面去完善和改进中台理论。

4. 客户想要的和说的不同？

你会发现，在客户决定要买你的产品时，跟你聊得都是一些高大上的功能，例如异地多活、单元化、多租隔离、限量降级等；但在买回去后，发现用到的都是一些比较基础的功能。这是由于决定买的客户和使用的客户不是同一批人，因此咱们必定要深刻挖掘使用产品的用户到底想要的是什么，这才能创建长期合做的机制。

5. 同一套应用模型真的能一统天下吗？

每个应用模型背后都须要相应的平台配套，应用本就是很偏业务的一层，不只有云原生的基础应用，还有各类行业应用。不一样的业务场景，对于应用的使用方式和交付流程都是不同。另外，基本每个平台都有本身的应用模型，因此应用模型自己是为某一个应用平台服务的，例如 OpenShift、CloudFoundry、KubeSphere 都有本身基于原生 Kubernetes 概念抽象后的应用模型。因此，同一套应用模型，只能用在某一个垂直场景中。

7. 云原生的将来展望

云原生技术的发展已经成为不可阻挡的趋势，目前正是云原生技术大幅度运用到商业化产品的最好时机。在技术体系的变革后，必然会迎来业务模式的变革，咱们都知道将来会变，如何抓住云原生这个契机，找到属于时代的重要风口呢？

惟有打破旧的体系和认知才是惟一出路。

本文分享自微信公众号 - 云服务圈（heidcloud）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。

云原生|理论认识探索