云原生：一个从买房到开房的故事
Posted 网事如烟云
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生：一个从买房到开房的故事相关的知识，希望对你有一定的参考价值。
云原生
一个从买房到开房的故事
云原生（Cloud Native）这个词火了有不少一段时间了，但是关于是什么是云原生，仍然是众说纷坛，莫衷一是。
问题问对了，答案就找到一半。让我们暂时忘记云原生，“穿越”回古老的面向服务器编程的时代——在那个时代里，最让人无奈的软件架构特性是什么？
一、云原生第一个根问题
当然，对于这个问题（最让人无奈的软件架构特性是什么），不同的人也有不同的答案，但是有一个答案，相信能得到绝大多数人的赞同，那就是：计算的高效弹性伸缩（弹性计算）。
假设一个系统，当前需要的配置是10台服务器，半小时候后，需要15台服务器，该怎么办？
该怎么办？去打报告申请采购-》采购服务器-》安装部署-》上线，这中间哪一步是半小时能够搞定的？面对这样的场景，除了躺平，恐怕别无他法。
而比这个场景更让人崩溃的是，这一番好容易折腾好以后，时光又匆匆流逝了半个月，老板说：我们现在10台服务器也够用了，把刚买的那5台服务器给退了吧。
就算“厚颜无耻”地薅京东的羊毛，人家京东也只是规定可以7天无理由退货，现在已经过去了半个月，又找谁去耍流氓呢？
可以看到，在服务器时代，计算的高效弹性伸缩，是一个无解的命题，直到云计算的出现。
我的意中人是个盖世英雄，我知道有一天，他会在一个万众瞩目的情况下出现，身披金甲圣衣，脚踏七彩祥云来娶我！
——紫霞仙子《大话西游》
云计算，首先是个计算资源池，其次从哲学上来讲，它是问题的转移和转换。
对于云厂商来说，如果它现在有1万台服务器，想扩容到2万台，一样会面临那一系列的问题：申请采购-》采购-》安装部署-》上线，一样会面临冗长的时间流程。从这一点来说，计算的弹性伸缩问题，并没有解决，只是从普通用户转移到了云厂商。
如果仅仅是这样，云计算恐怕就不会有真正的商用。量变引起质变，这世上本没有路，走的人多了，也便成了路。随着云计算的用户增多，不同的用户之间，会达到一种“微妙”的动态平衡：有的人期望增加算力（比如上述场景的增加服务器），同时也会有人期望减少算力，这一增一减之间，就是这么微妙地达到动态平衡——对于云厂商来说，它可以在现有资源不变的情况下，闪转腾挪，满足每个用户的弹性伸缩的需求。（当然，如果总资源不够了，云厂商还是需要购买服务器去扩容，这是另外一个问题了）
可以看到，从某种意义上讲，云计算的本质是一个“共享经济”模式。正是这种“共享”，使得普罗大众的弹性伸缩的需求，得到了很好的满足。
“共享经济”模式这个大基调确定以后，剩下的就是云计算本身的技术发展了。从虚拟机（VM，Virtual Machine）到容器（Container），而容器的解决方案和生态，目前来看，乃是 docker/k8s 胜出。
云计算为什么会有这样的发展路线呢？这又要从原始的问题入手，如图1所示。
图１ 从服务器到 docker/k8s
通过图1可以看到，从服务器演进到云计算，这几乎是一种必然，如表1所示。
表1 弹性效率
服务器模式 |
虚机模式 |
容器模式 |
|
弹性扩容效率 |
日~年 |
分钟级 |
秒级 |
弹性缩容效率 |
不具备 |
分钟级 |
秒级 |
而云计算技术，从虚机一直发展到 docker/k8s，其背后的需求逻辑是：弹性效率，部署效率，弹性自动化（以及其他层面的自动化），如图2所示。
图２ 弹性需求的马斯洛模型
通过图2可以看到，随着弹性需求的马斯洛模型的逐步展开，云计算的技术也是逐步发展，而 docker/k8s 则在这个发展的过程中，成为天选之子，最起码到目前为止，它们是绝代双骄、珠联璧合、俾倪天下。
至于 docker/k8s 为什么会在这场技术大战中胜出，以及它们的技术细节又是什么，本文由于主题和篇幅的原因，就不再详述。我们只须知道，docker/k8s 从根子上是为了满足人们的弹性计算的需求，然后在弹性需求的马斯洛模型上胜出即可。
那么，问题来了，docker/k8s 是不是就可以称为云原生呢？有的人，有的企业，确实是这么宣称的，但是还有另一部分人和企业，表示坚决反对。说句不客气的话，无论是支持此观点的还是反对此观点的，很多时候都不是处于技术层面考虑，而是处于自身的商业利益考虑。
乱花渐欲迷人眼，一说到商业利益，这个事情就说不清楚了。我们还是需要从原始的问题出发，去寻找云原生的本质。
二、云原生的第二个根问题
除了弹性计算，还有什么架构特性是让人最头疼的呢？幸福的人生千篇一律，不幸的人生各有悲苦。第二让人头疼的架构特性，其答案也是纷呈各异，但是如果说是 HA（High Availability，高可用性），应该也能得到很多的赞同。
需要说明的是，HA 分为计算的 HA 和存储的 HA，如图3所示。
图３ HA 的分类
基于不同的原则，HA 有不同的分类，比如 Active/Active、Active/Standby（图3表达的是就是此种模式），又比如本地 HA、异地 HA 等等。而按照部件来分类，HA 分为计算 HA 和存储 HA。
对于计算 HA 来说，docker/k8s 已经能够很好地解决（前提是计算部件要做服务化/无状态改造），但是，对于存储 HA 来说，非常不幸，目前没有非常简单有效的专有方案。
既然没有，那么对于存储类 HA，是不是就该躺平呢？不，云厂商推荐的解决方案是
躺赢
既然没有简单有效的方案，云厂商的意思是：你就不用烦心这个问题了，给钱，我来帮你解决，如图4所示。
图４ 存储类的 HA 躺赢方案示意
存储当然不仅仅意味着关系数据库，图4仅仅是个示意。假设一个 App 需要操作关系数据库，关系数据库里面的数据（也就是存储类）所需要的 HA，对于开发者来说，就不必关心，他只需调用云厂商的关系数据库服务（比如华为云的 GaussDB），那么这背后的数据的 HA（包括数据库计算部分的 HA），都由云厂商来解决，而开发者只需要做一件事情：说服自己的老板，花钱买云厂商的云数据库。
如果不是关系数据库，而是其他类型的数据库，或者说与数据库无关，仅仅是存储，云厂商都有对应的服务，只要你愿意花钱。
需要补充一点，抛开单纯的存储服务，当前云厂商并不能保证它所提供的相应服务能够百分百保证所有用户的需求，这个需要具体问题具体分析。不过总体上是这个思路：
花钱购买云服务，同时解决 HA 问题！
用户花钱购买的云服务，云原生赋予其一个高大上的名字：BaaS（Backend as a Service, 后端即服务）。BaaS 在不同的场景，也有不同的定义，我们不必纠结。这里不妨理解为云厂商的一个话术：
设想一下，作为一个架构师，你的解决方案竟然是花钱，你还怎么在老板那里混？这时候，云厂商就要送你一朵小红花——你这不是花钱，你这是 BaaS！
是不是一下子就很高大上？是不是一下子就很有逼格？花老板的钱，让老板无话可说！
不过，BaaS 还不是最有逼格的。最有逼格的是 Serverless （无服务器）方案。客观地说，Serverless 是云原生的属性之一，但是它不是根本，最起码目前来说，它有那么一点混淆视听。
三、云原生的极致追求
Serverless，并不是真的没有服务器。我们的软件，部署在云上，而云归根结底是由服务器承载的。如果真的没有服务器，那云就不叫云了，那叫空气！
Serverless 指的是对于开发者而言，他不需要感知服务器的存在，一切都交给云。
Serverless 的定义，可以参见一个普遍认可的公式：
Serverless = BaaS + FaaS
BaaS，前文介绍过，它当然不需要用户感知服务器的存在。FaaS（Functions as a Service，函数即服务）这个话题，本文由于篇幅和主题的原因，也无法展开。总之，我们暂时只需要认知两点：
（1）比服务化的代码，更加“简化”；一切的执行、弹性都交给云（而且弹性效率是毫秒级的）
（2）但是，它的适用场景是有限的，并不是一个普适的解决方案
客观地说，Serverless 确实是云原生的一个极致追求，但是正因为 FaaS 并不能称为一个普适的解决方案，笔者并不赞同把 Serverless 理解为云原生的本质（之一），否则会对云原生的概念产生混淆。
其实，“混淆”云原生概念的，又何止一个 Serverless。众多公有云厂商，他们有意无意地——不，它们就是有意的——在无限扩大云原生的范围。嘴里说的都是主义（云原生），心里想的都是生意！在商言商，这么做，可能也没有什么错。
张华在软件公司当码农，花钱买了云服务；李萍在云厂商当网工，运维云服务；王总是软件公司老板，说自己的架构是云原生。
我们都有光明的未来！
那么，这些云厂商到底是如何无限扩大云原生的概念呢？这就是一个从买房到开房的故事。
四、从买房到开房的故事
我们回忆一下软件开发模式的演进，如图5所示。
图５ 从买房到开房的故事
把服务器模式类比为买房模式，这比较好理解。云计算模式，其虚拟化技术包括虚机、容器——这里的容器，指的是单纯的容器技术。在云计算模式下，虽然房子（计算/存储等资源）不用买了，可以租，但是房子内部的其他基本服务（弹性、HA），还需要自己搞定（云计算模式也试图搞定这些基本服务，但是没做好）。而云原生模式下，房子内部的基本服务，也无须用户操心——只管花钱开房，剩下的交给酒店就行了。
人生在世，既有吃喝拉撒睡，还有吃喝嫖赌抽。如果只是一家普通的酒店，那专心致志做好睡的服务即可（当然，还包括拉撒服务）。但是，如果开房的人多了呢，多到足以支撑起其他产业呢？又或者是期望通过其他产业吸引更多的人来开房呢？这个时候，我们就分不清这个酒店的主营到底是什么了？是睡服务、赌服务，还是莞式服务？
就像各大厂商所宣称的云原生，应有尽有，无所不能！比如某厂就从服务的生命周期入手，宣称各个阶段都存在云原生的概念（只要你购买它的服务），如图6所示。
其实，图6虽然涵盖了各个阶段，它还只是涉及了“可信”这一点。但是，就是这一点，也让人无法反驳。如果是运行期的产品族，它把 AI 等各种服务都塞进去，都说是 BaaS，都说是云原生，也仍然让人无法反驳，比如图7所示的阿里云的云原生产品家族。
图７ 阿里云的云原生产品家族
这有问题吗？这没有问题！问题是，我们该如何寻找云原生的本质！
五、云原生的本质
写到这里，笔者有点不敢下笔了。前面怎么扯犊子都行，现在忽然聊这么严肃而深刻的话题，笔者深感水平有限、力不从心。不过，既然已经写到这里了，就斗胆写下去吧，班门弄斧，贻笑大方。
有时候寻找一个解决方案的本质（云原生是一种解决方案），需要从它所解决的本质问题入手。
笔者以为，云原生所要解决的本质问题就是：
弹性计算 + HA
而其它问题，是两个本质问题的解决路径上所遇到的问题（随路问题）——既然遇到了，如果能“捎带脚”解决，那就顺便解决。从完整性角度来说，这扩展了云原生解决方案的范围，但是这绝不是云原生的本质。
比如“服务发现”问题，服务既然要弹性，总得让请求能正确抵达服务实例。那如何抵达呢？当然得先有服务发现。
再比如，安全、韧性等等问题，都是云原生本质路径上所遇到的问题，既来之、则安之，云原生都可以一并帮其解决了。但是，我们要深刻地认识到，这些都是云原生的次生问题，不是云原生的本质问题。
综上所述，笔者以为，云原生的所要解决的问题，也符合马斯洛模型，如图8所示。
图８ 云原生所解决的问题的马斯洛模型
罗曼罗兰说，世界上只有一种真正的英雄主义，那就是看清生活的真相之后，依然热爱生活。
认清了云原生的本质问题和随路问题以后，我们并不拒绝云原生为随路问题所付出的努力。它把那些随路问题解决了，当然是更好，我们没有必要为了纠结一个纯粹的概念，而拒绝整个春天。
当然，问题的解决是双向的，云原生也是双向的，它不仅仅指的是云厂商的努力，也包括了软件开发商的努力。关于这一点，阿里云的总结就比较好，笔者这里直接引用，如图9所示。
图９ 阿里云的云原生架构成熟度模型
图9中的 ACNA 是 Alibaba Cloud Native Architecting 的缩写。笔者之所以直接引用这张图，是因为它：
（1）非常好地涵盖了云原生的本质问题和随路问题，以及解决这些问题的目标
（2）暗含了云厂商与软件开发商的共同努力
当然，随路问题是无限的。随着技术的发展，随着云厂商的发展，我们会看到云原生的范围越来越广，我们甚至会看到，云原生的本质问题，也会扩展。不过，这些都是后话了。
就当前的技术栈而言，你要问笔者云原生最核心、最本质是什么，笔者的答案是：
docker/k8s + BaaS
将来，docker/k8s 这个技术栈也许会被替换，而 BaaS 的外延也会无限扩展，只要“钱能买到钱”——能够提升开发效率，降低开发成本，一切都可以是云原生。
所以，云原生就是 CaaS：Cost as a Service，
成本就是服务
------------
以上是关于云原生：一个从买房到开房的故事的主要内容，如果未能解决你的问题，请参考以下文章