云原生体系下的技海浮沉与理论探索

作者 | 王银利(芸峥)

1 . 概述

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

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

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

2 . 什么是云原生

2.1 云原生的定义

云原生的定义一直在发生变化，不同的组织也有不同的理解，比较出名的有 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、持续交付、康威定律、重组等）。云原生也可以说是一系列云技术、企业管理方法的集合。

一、云原生不是业务本身

好几个人问我云原生是什么，我会反问他们，如果你想自己的业务快速迭代，你希望云原生是什么。云原生一定不是一个具体的东西，而是代表了如何追求问题的本质，它本来是什么，就是什么，它是一套方法论。

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

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

我们无时无刻都在变成旧，无时无刻都在创造新。人要敢于质疑自己，质疑过去，质疑权威，才有创建新的动力和洞见。

二、云原生不是云计算

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

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

设计

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

便捷性

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

价格

云原生应用程序不需要任何硬件或软件上的投资，因为它们是在云上进行的，通常可以在被许可方获得，因此使用起来相对便宜。云计算应用程序通常比较昂贵，因为它们需要进行基础升级以适应不断变化的需求。

实现

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

三、云原生本身是复杂的

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

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

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

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

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

3 . 什么是云原生应用

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

云原生应用，是指原生为在云平台上部署运行而设计开发的应用。云原生应用不只是将应用打包成 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 类应用、查询类应用等。

一、无状态到有状态

比如一个比较简单的云产品，在公有云部署时，可以依赖公有云的基础设施，所以是无状态；但在专有云部署时，却需要自己解决环境和对其他BaaS的依赖，所以是有状态，这就是基础设施和运维方式不同造成的差距。

一般情况下，我们不提倡应用之间的依赖过于复杂，尤其在专有云场景下，复杂的依赖带来的环境问题相当多，拔萝卜带泥几乎要把整个公有云搬到专有云，无论对我们还是对客户，都是比较大的心智负担。

二、有状态到无状态

业务应用本质上都应该是有状态的，不过它可以借助中间件、运维 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 一切皆数据

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

因此，我们在平时的设计中必须具有数据思维，进行更多的数据建模，否则可观测也是无米之炊。我们来看看云原生的各个环节中，都有哪些数据？

我们需要编辑资源的配置，并通过 GitOps 或者 K8s 命令进行下发，也叫数据驱动，即一切皆配置数据；
资源的各种逻辑都需要执行一系列动作，执行动