串2：云计算架构思考

开始之前，先给出串1：一文将大数据、云计算、物联网、5G（移动网）、人工智能等最新技术串起来_龙赤子的博客-CSDN博客

承上

事物的复杂性一般有两个方面，一个是本身结构的复杂，一个是运行机制的复杂。因为这两者会相互影响，所以边界不会那么的清晰。运行机制的复杂，会催生结构的复杂，而结构的复杂往往也会导致内部运行机制的复杂。一般来讲，理学多体现机制的复杂，而工学问题多体现结构的复杂。举个例子，物理问题，首先研究的是原理，即如何找到一个数学模型来表达内部的机制。经典的牛顿力学，就是通过几个数学公式，被完美的诠释了。电与磁的关系也是通过麦克斯韦公式漂亮的表达了出来。这些问题在解决之前，就是机制的复杂。相反，对于人造物操作系统而言，它的复杂性则更多体现在结构本身，特别是对现代产业界，其所映射的生态圈，让其不是一个容易替换物。这个生态圈的构建，是需要许许多多、方方面面的子模块来支撑的，这些子模块的关联关系往往会让人望而生畏，这就是结构的复杂。当然还有机制与结构二者均复杂的结合体，这在生物化学方面体现的更加明显。DNA双螺旋结构与其表达原理，蛋白质分子与其功能，都是结构复杂与机制复杂的代表。正是这种完美的结合，使其具备了强大的能力。

从生活经验来讲，简单的结构涌现不了复杂的功能，这是一个朴素的道理。丰富能力的拥有，必然需要很多结构简单、能力简单的组件通过复杂多重构建才能实现。这方面，现代人工智能，特别是神经网络方面的研究，将来也许会给我们更多的启示。

面对复杂问题，如何快速有效的掌握，是一个涉及方法论的问题。为什么这么讲？首先，相对于碎片化的信息，人类大脑更擅长掌握具有层次关系、因果关系、系统化的内容。以物理学习为例。开始时，物理以自然课的形式出现，讲述生活中或者大自然中的一些现象，引发大家的思考，这是启蒙过程。之后，开始引入一些概念，促使大家定性以及初步定量的看待一些物理事件，这是入门。这一阶段，大家基本能够看到物理的一个概貌，比如有力学、电学、磁学、光学、声学等等，当然可能还会接触到一些量子物理等方面的简单介绍。这就相当于我们把一幅有很多层次细节的巨图，缩小到很多倍得到一眼看全的结果。之后，随着了解的逐步加深，对每一个部分会进行更加深入的介绍，定性越来越少，定量越来越多。等到大学里，之前的计算基本就转换为微积分来重新定量分析。再深入到一定程度，那就不能全面的展开了，因为人的时间精力都是有限的，所以大家就根据兴趣，分别进入更加细分的局部进行深入研究。这就相当于将图片放大很多倍，看到了很多细节。再举一个通过故事记忆卡片的例子。遗忘是大脑的一个基本特性，特别是对于一些缺乏连续的碎片信息。如果给一个人看一堆卡片，然后让其按顺序说出卡片的内容，通过死记硬背，是很难完成的。一个巧妙的辅助记忆手段就是将卡片的内容编成故事，这样更容易记忆。其次，从统计角度来看，大部分人都是通过持续学习，刻苦努力才掌握了丰富复杂的专业知识，而且更加的细分。不像十七十八世纪，甚至更早阶段，一个著名人物可能兼具数学家，物理学家，化学家等等多种身份的加持。现在几乎不存在这样的人了，不是我们变笨了，而是要学习的东西更多更深了。总的来讲，天赋异禀者属于少数，天资愚钝者也是少数，也就是不用学和学不会者都是少数，普通人都可以在感兴趣的领域习得相对专业的技能，无非是方法问题、时间投入问题。

因为问题复杂，因为大脑的并行性有限，对一个问题，我们都是需要不断激活神经元，调取更深层次信息，这就是思考过程。所以对复杂问题，行之有效的方法就是设法使其系统化、层次化，尝试从多个角度来看，逐步构建起大脑中的知识全貌。对于任何一个行业的从业人员来讲，这种全局全貌的掌握，既是持久兴趣、持续快乐的保障，也是进阶升级的终极目标。

也因为这种复杂，当我们对外展示输出时，往往会选择就某一个方面或某个特定角度，进行有限的输出，比如是某个细小局部的深挖或者可能是全局的概览，而不会出现全局立体的细化展示。因为这一方面要求过高，另一方面，也不符合思维习惯。对输出人而言，其大脑中本身就要具备全局和立体的视图，对接收者而言，其也要能够一次吸收大量的信息量，并能够消化，刻印到自己的大脑中。这两个条件往往都无法同时具备。我们的大脑习惯一次掌握一小块内容，这样才能固化起来。如果灌输的多了，到后面就会遗忘前面的信息。

这样就形成了矛盾的两面。更好的掌握，要求我们有全局的视图，而更好的学习，又要求我们从局部、切片、特定角度的视图展开。若要用这些切片再搭建整体框架，则往往需要学习者持续的学习，以便足够好的掌握足够多的小切片，而且更需要学习者持续的思考，以便能够将小切片之间的连接打通，最终完成系统构建的小壮举。这也就是为什么修炼需要时间，需要努力。苏轼的题西林壁，精准的反映了小伙伴们学习中的感受：

横看成岭侧成峰

远近高低各不同

不识庐山真面目

只缘身在此山中

博主对计算机领域的新技术新概念是比较感兴趣的，但是大家都知道，对全社会来讲，现在是一个知识爆发的时代，特别是对于计算机这种人造物领域来讲，更是如此。而对于洪流中的个人，则是一个专业细分的时代。一个人能够实际接触并深入的领域还是比较局限的。虽然我们可以通过各种知识学习平台，了解到自己感兴趣的领域，但了解跟理解、掌握以至于应用并以此谋生，还是有巨大差别的。对于计算机，不上手操作，效果往往就会打折扣。这个时候，该如何来掌握新领域新技术新概念，思考就显得特别重要了。这其实就是学习的最高境界：大道至简。所谓事物之间的道理都是相通的，人不可能也没有足够时间学习所有东西。此时，变被动输入为主动探索，学会举一反三，提高抽象理解能力就是底座技能。任何技能都不是一朝一夕就能掌握的，更别说这种打通任督二脉的高级技能。但修炼这种技能，往往能够取得事半功倍的效果，不可谓不高明（其实学无捷径，这种看似弯道超车的方法，往往需要付出更多的汗水，所以说，能量还是守恒的）。今天，博主就尝试在之前零星碎片的学习记录、思维导图以及初步的贯通思考基础之上，思考云计算的全局整体大框架，以期在迷乱眼的技术名词中，做到“不畏浮云遮望眼”的心境。

人类大脑的惯用思维方式，有点类似看图软件。首先，看到的是一幅全局图，这让我们有个系统的把握，当放大图像时，我们就会聚焦于部分，不断的看到细节，直到不可再分为止。

回到云计算本身。云计算涉及的技术非常繁杂，这从网上整理的有关DevOps元素周期表就可窥见一二，如下图所示（图片来自https://devops.phodal.com/home）：

 

当然，我们的目的不是把这些工具学完，而且现在也不是两千年前，学富五车就可以行遍天下（据考证，作为书籍承载主题的竹简，装五车在现代看来也没有多少内容）。不把通用基础知识内化于心，学的再多，那也只是盲目跟随，既浪费时间，也没有前途。从普遍的二八原理来讲，如果你不是猎奇者，那么可以肯定的是，上图百分之二十的工具必定占据了百分之八十以上的市场。对于计算机领域，其实真实的结果更惨，往往是一两个工具就占据了某个细分领域。先机特别重要，后来者几无胜算。微信就是经典的例子。Google为啥总是开源其耗费心力财力研发的各种框架，无非就是使自己始终处于技术和市场的领导地位。

相比看到结果、答案，提出问题本身，更具思考挑战性。从长远来看，特别是研究角度，思考过程本身才更具价值。这也在一定程度上反映了我们的教育跟欧美发达国家教育的差别。这一点就不再展开了。对于云计算而言，为什么会出现这样一个东西，它要解决的问题是啥，理清了这些，再来看云计算的现状，云计算的架构，云计算的相关技术，理解的才会深刻。这部分不再从头梳理，而是基于博主之前思考整理的一篇博文（https://blog.csdn.net/wwwyue1985/article/details/113702766）延展。

在上面串联各流行技术的博文中，很多疑问其实已经得到了解答。这里再补充一二。第一，关于计算的性能；第二，关于计算的成本。

我们现实世界运行的规则就是平衡，无论是哪个领域。计算机领域体现的还更为明显。我们总是在计算的性能和成本之间寻找平衡点，经典的例子如现代CPU内部的大小核异构架构。下图为从ARM官网（https://developer.arm.com/documentation/den0013/d/big-LITTLE/Structure-of-a-big-LITTLE-system?lang=en）获取的一个经典大小核架构：

 

简单来讲，大核心强调性能，小核心强调功耗。每一个核心的计算跟功耗关系可以看成是一条曲线，如下图：

 

从图上可以看到，二者构成一个剪刀形状。在低频范围内，小核心更具功耗优势，而在高频范围内，大核心则更具功耗优势。这样一来，低频可以完成的工作，交给小核心做更划算，而高性能计算工作，交给大核心做更划算。

推而广之，一个CPU如此，一堆CPU也是如此。可现实问题是，小核心的这种曲线更为容易出现。当CPU的频率提升，晶体管的开关频率也就意味着要提升。在工艺不变的情况下，要快速的充电放电，需要的电压也就相对高一些，而且快速的通断，导致耗电更多，功耗更大，自然发热就会更严重。而发热又会影响器件的特性，甚至CPU工作的正确性，自然，超过一定的平衡点后，频率的提升就不再是一条划算的道路。

但是我们回归到性能这个话题本身。CPU虽然可以通过其他技术来提升性能，比如典型的流水线技术，乱序发射执行技术等，实现单周期指令目标甚至平均小于单周期的总体执行效果。不过这些技术终归有个极限，流水线的终极效果就是单周期，乱序执行受程序本身影响，宏观上有一定提升，总体不会太大。所以不管怎样，这个极限的高点，更多的还是受限于CPU的主频。主频就像是CPU的天赋，决定了最终高度。

我们现在所生活的世界，很多问题都依赖CPU的计算解决。既然CPU的性能强关联与CPU的主频，那么是否意味着性能的提升有限？是否意味着能解决的现实问题有限？其实不然。虽然快与强有强关联的关系，但并不是绑定死的。关于这个问题，人类的解决方案还是比较多的，这里简单列举几个：

1 首先，在一定程度上，可通过架构设计，实现大核心的效果。专门设计这类CPU，并专用于高速计算场景，通过高频实现高性能的计算，这也算是实现了性能和成本的平衡。

2 其次，这个问题更好的解决方案是前面串联文章中提到的主打方法：分而治之。一个CPU搞不定，就组装多个来干。所以，面对高性能计算的需求，在现有基础物理理论没有突破的情况下，也就只有堆叠这一条路。这条路有个限制门，就是哪些本身可以被分解来计算的问题可以通过这个限制门，否则仍然没戏。但通过这个限制门后，却可以有两个叉，后面我们会提到。

3 异构计算。计算问题本身有其多样性的特点，适合CPU来干的只是其中的一部分。比如，对于网络包处理，对于图形渲染，对于信号处理等，我们有网络处理器NP，图形处理器GPU以及信号处理器DSP等专门解决。有些特殊领域，比如强实时性任务，可通过硬件编程方式，使用FPGA或CPLD器件解决。CPU天然的串行计算过程，适合编程，灵活性高，通用性强，带来的问题就是指令浪费。既然要通用性，就得考虑全面一些。专用处理器则不需要受此限制，可以采取直达目的的方式实现，从而跳过不必要的中间过程。

采用上面三种方法，大部分问题都可以得到解决。如果真有更高要求的场景，那就只能集当前人类智慧的最强组合，尽力而为了。像密码领域，棋类领域，天然的就存在当前处理器难以驾驭的问题，而这些问题正好可以用来防护数据的安全。

对于上面第二条中所述的分叉，主要是指科研领域极为重要的超级计算机和普通商业应用领域的云计算。超级计算机性能强，成本高，但是适用面比较狭窄，从计算和成本的平衡来看，不适合各类管理系统。而云计算则更加通用一些，除了计算外，更适合企业业务。

到这里，我们有了云计算的计算基础。对于企业类业务，除了计算，更多的还有存储和网络需求。设想我们有一个伸缩能力极强的服务中心，为了完成业务功能，除了开发业务逻辑代码外，在服务中心还需要存储我们的数据，还需要提供网络入口，供用户访问。这个服务中心，屏蔽了物理位置的概念，全球任何位置的客户和节点都可以安全的极速访问，请求可以极速处理、响应，而这一切的成本是跟需求匹配的。资源不会闲置，更不会缺乏。数据不会被非法访问，更不会丢失。云计算应该是满足了开发者、用户、服务提供方（企业）对最完美服务中心的所有美好想象。

从上面这个完美服务中心来看，它就是一台隐形的超级计算机，无处不在，而且还会72般变化。你要什么，它就能给你什么。你要一台机器还是一群机器，一个平台还是可直接使用的服务接口，都可以满足你。

上面的描述可能不够具体，但是对于云计算能够带给你什么，我想应该有一个粗略的答案了吧。因为它被描述的无所不能，过于完美，使得我们很难去具体的定义它是什么。你的需要是什么，你眼中的云计算机就是什么样子的。它是可裁剪的，可组合搭建的，所以每个人的使用环境不同，这台计算机的样子会有点差异。如果有人让你建造这样一台计算机，即使你是计算机设计方面的专家，也可能会奔溃。这个需求似乎说了什么，但又好像等于没说。“大音希声，大象无形”，过于玄乎的东西，似乎都有这样的特点。一根棍子，练武之人拿它做武器，老太太拿它当拐杖，渔夫拿它撑船，女人拿它洗衣服…需求不同，定义自然不同。

好了，不管世人如何看它，总之，你就把云计算看做是一台漂浮在地球上的隐形超级计算机。它在哪，不是你需要关注的。你只需要知道，当你需要时，它就会出现在你面前。

 

从这个设想出发，我们看看，如何实现这样一台计算机。这个探索的过程，就是主动思考的过程，内化于心的过程。当然这个过程比起原始创新，难度是低了很多的。我们相当于是知道答案了，再思考过程。因为前面说了，一堆的术语，切片式的局部展示，无法构建系统化、立体化、全局化的整体视图，而这个视图，才是以不变应万变的法宝，才是能被我们大脑对等刻画的雕板。虽然是知答案而探过程，但这个过程可以辅助我们将碎片拼接起来，形成前述的最终视图。此过程实现以小博大，还是很有价值和意义的。

首先，这台漂浮的隐形超级计算机是一个服务中心，它最终也是由具体的硬件实物构成的。这是它的根本。既然作为一个计算机存在，那么自然就需要具备冯洛伊曼所总结的五个基本要素：输入、输出、计算、控制、存储。有了大框架，我们来看需要填什么。

第一，自然是计算了。计算典型的硬件实物就是CPU了。但是时刻需要注意的是，这是一台超级计算机，CPU会以机群的方式出现。想象一个超大的CPU矩阵，这个矩阵划分为多个区，每个区又划分为多个组，每个组有多个实物CPU，每个CPU内部又有多个核心。这样划分，是为了管理。这台计算机输出的算力是根据需求可大可小的，那么就需要弹性伸缩的能力，大的话，可以多划分一些出来，小的话就少点，根据需求来。如果少于一个物理CPU呢？还可以按CPU内部的核心来，这样就避免了资源闲置浪费。除了CPU外，我们说了，这台超级计算机适应能力很强，如果用户要用它来做图形图像方面的工作，那可能GPU更合适。如果还有其他特殊需求呢，可能一些相对专业定制的XPU甚至固件更合适（Intel加altera，AMD加Xilinx）。要将它们放在一起管理，我们可以抽象一些插槽出来，定义其标准，然后就可以在其上安插所需的算力实物了。这样一个伸缩自如的算力框架构建了。

第二，有了计算，下一个就是存储了。这包括两方面，一方面是我们传统意义上的内存，一方面是类似传统意义上的磁盘。对于内存，靠近每一个CPU单元，都有其运行所需的内存，这是机器底层本身的构成件。作为服务器产品，这种内存空间可以比较大，满足计算需求应该不成问题。如果不够，还有numa架构来支援。人为分解一部分核心关联一个内控，实现横向扩展。说完内存，再来说存储，也就是外存。从理论上将，这有三种方式可选，一个是DAS,一个是NAS，还有一个是SAN。DAS就理解为机器硬盘好了，直接的，挂到总线上的，别人不可访问。基本的有这种就可以了，但是仅仅这种是满足不了需求的。比如我们要在这台超级计算机里面迁移数据，放大后，你会发现，顶层抽象的内部迁移，在底层是跨机器的，这就很不方便了。如果这些存储在一定范围内是网络化的，所谓的迁移就是传递个地址的事，岂不高效简便。这就需要NAS和SAN了。NAS基于文件系统，NFS、FTP类的实例比较容易理解。但是问题是性能受限。SAN就综合了前面两种的特点，使用磁盘指令，性能不受限于协议，其次网络化。实践层面，关键是要有个光纤交换机来保证速度。这玩意不便宜，所以说世上没有免费的午餐。注意，这里说的光纤交换机通过分区就可以实现数据转发，不是以太网的光电转换，需要Mac地址什么的。这样一来，不仅通过群实现了可伸缩计算的硬件基础，也通过网络实现了可伸缩存储的硬件基础。虚拟机的热迁移也是需要这种机制的。

第三，输入输出。对于这个漂浮的机器，输入输出最自然的方式就是网络了。网络典型的就是层次架构，接入、汇聚、核心三板斧，哪里都吃香。服务端可靠性是硬要求，故冗余也要做足了。实物上，交换机、路由器、防火墙都妥妥的要备上。

第四，控制。从底层来看，控制并不有明显独立的实物。这个角色，软硬件共但，这里就不展开了。

至此，我们有了最底层的硬件视图。如下：

 

通过上述硬件层面的基座，使得提供位置无关，安全弹性可伸缩计算和存储成为了可能。下面我们就基于这个底座，构建云计算的上层设施。

对外的灵活性往往意味着内部的复杂性。对外既要能够支持这样，又要能够支持那样，那内部不就得有支撑这样那样的组件存在嘛。云计算是按需提供资源的，这一点跟操作系统管理内存页面的大小选择有点类似。如果按物理机提供资源，因为物理机的性能较为强大，在业务层进行功能隔离的情况下，可能会出现资源闲置。而且不同的业务，需求的重点不同，有的可能要较强的网络处理能力，有的可能需要较多的存储，有的可能更多的完成计算。统一按物理机提供资源，显然不够合理。理想情况是，用户或者业务需要多少资源，就能够提供多少资源。资源不够的情况，可以通过多机联合来提供。将管理资源的粒度缩小，既能够充分利用资源，又能最大化收益，何乐而不为。当然这个粒度不能过小了，就跟内存页面划分不能够过小一般，否则花费在内耗管理上的投入可能就超过了收益的平衡点。对基础设施构建者和管理者而言，资源不能够精细管理，那是不合格的，也意味着失败。好在，我们有很好的方案可选。

1 首先，是虚拟机方案。关于什么是虚拟机，就不介绍了。这种方案，可以有两种方式，一种是底层硬件就被虚机接管，在虚机上安装客户操作系统。一种是安装操作系统后，再安装虚机，最后在虚机中安装客户操作系统。这种方式，虚机作为操作系统的一个应用存在。显然，后一种方式多层封装，性能有损耗。但是实现起来比较简单，对于普通用户，仍然有一定应用价值。而对于云计算资源池构建来讲，前一种方案显然更为合理。

2 其次，是容器的方案。虚拟机方案虽然隔离性很好，但是较为笨重，资源损耗大，划分粒度不够精细。相反，容器是通过操作系统的支持，主要在软件层构建的一个相对封闭的运行环境。因为更加面向应用本身，而不过多牵涉操作系统，故可以做的较为轻便，启停更快，资源划分更为精细，体验更好。但缺点是隔离性不如虚拟机方案，无法独立管理资源，比较适合面向最终业务应用，也就是资源的最终用户。毕竟，所有的容器实例还是在一个操作系统的管理之下。

到这里，我们就有了三种对计算资源管理的方式。一种是原始物理机，一种是虚拟计算机，还有一种是应用容器。层次不同，面向用户不同，使用场景不同。物理机适用于对资源有严格独立要求的客户；虚拟机适用于需要完整计算资源的客户；而容器适用于关注业务应用的客户。

以上，我们简单整理了计算资源的虚拟化。其实，硬件底座只是提供了能力，为了满足多样需求，包括计算、存储和网络，我们更多的是需要控制和管理，而这方面，软件就更为合适了。为了达到灵活可控的目的，不仅需要对计算资源虚拟化，还需要对存储和网络资源虚拟化，将它们整合起来，形成资源池，既具备资源本身所属的属性特点（比如计算、存储和网络），又能够被灵活管理（比如调度，迁移，切分，限速）。

下面我们看看存储资源的虚拟化。前面在存储资源构建上，我们已经提供了两种方式，NAS和SAN。通过这两种方式，虚拟计算节点就可以访问存储资源。存储资源与计算资源不同，需求更多的是小聚合为大，而非大拆小。这里的大和小主要是指容量。试想一下，存储本身的特点就是越存越多，不断膨胀，很少会收缩，当然也不是没有，这主要是在用户配置层面。出于成本和收益考虑，用户可能扩大也可能缩小存储需求。虚拟化的存储池要能够满足这一点。对于DAS，通过分区即可解决这一点。对于NAS和SAN，可以通过虚拟化控制器，实现对存储设备的管理，进而对主机的存储做出适配。存储除了容量外，还有可靠性的指标，支持冗余的磁盘阵列是实现这一途径的主要手段。

总的来看，存储面对的数据需求有块、文件和对象三个层级，面对的控制需求有伸缩、可靠、速度等指标，管理上可以通过OS配合虚拟控制器到物理控制器来实现。

除了集中式的存储资源池化，为了降低成本，充分利用存储资源，还可以利用软件定义存储SDS，通过异构设备来构建存储。如下图（图片来自RedHat官网）

 

利用x86标准服务器构建分布式SDS，可以满足特定领域的需求，比如大数据。跟传统的CT转IT类似，这也有点专业、集中的昂贵存储转分布式低成本，软件掌控的存储的感觉。通过软件和网络，将存储资源利用起来，通过算法，实现可靠性保障，总体实现灵活、低成本的解决方案，似曾相识啊。

关于存储虚拟化，最后再提一点，其可以作为一项独立资源面对客户和应用，而不需要和计算绑定。比如，我可以只有存储需求，通过网络这个输入输出通道，将我的数据汇集到云上我独享的几乎无线存储空间的隐形超级计算机的存储中。我也不需要管数据到底存在哪里。

说完存储虚拟化，再来看看网络虚拟化。同存储环境一样，我们面对的网络现状也是类似的，各种异构设备充斥于云中，缺乏统一标准，厂家兼容性差。显然，这种问题也只能通过软件来解决，这就是软件定义网络SDN的初衷。通过SDN，将网络设备划分为控制层面和数据转发层面。网络设备从一个自治的独立体变成一个受控的转发器。流量的走向由控制层面决定，传统的网络设备主要负责数据转发平面。当然，理想是美好的，不过这与各个网络厂商对自己的定位会有那么一点错位，现实自然就是骨感的了。

不过，现有的网络架构还是可以满足构建一个虚拟超级计算机的。毕竟，网络只是一个连通管道，管道中流动的数据，是我们可以灵活定义的。

使用传统网络，解决主机之间的沟通，问题自然不大。传统的网络架构本身也支持虚拟管道的构建、带宽的限制、安全的防护。但是，面对虚机、容器等对网络连通的要求，传统设备就力不从心了。一味去适应传统架构，整个虚拟云机的管理就会变得很复杂，这种窘境，就需要网络虚拟化技术，通过隔离影藏对外差异来优雅解决了。比如，通过虚拟网卡、虚拟交换机、虚拟路由器技术，可以使虚机和容器对外表现的跟传统主机一致，再配合以隧道类技术，VLAN的划分，可以使得云中整个资源在一个虚拟二层网络中，东西向的迁移，就变得很简单了。

 

以上就是网络虚拟化的相关内容。其实到这里，我们可感受到，计算机里面除了平衡的思想外，还有一个值得关注的现象，就是能量守恒。怎么讲，就是任何功能，都可以在不同层次实现。软件虚拟化设备就是典型的例子。计算机底层硬件的开关门到软件层面面对的0与1，使得这种转换可以做到无缝衔接，这也是现今云计算可实可虚的根基所在。

对于云上的这台超级隐形计算机，为了面对多变的需求，在硬件满足基础能力的基础上，需要对资源虚化，以便能够更好的掌控。这样就形成了如下的一个资源虚拟化层。

 

上图中，各个层面都有多种技术可以选择，我们只是抽象技术，而不涉及具体工具产品。虚拟计算层面，对外可以提供物理机、虚机和容器等不同等级的资源，而容器既可以构建于物理机之上，也可以构建于虚机之上。

这样一个虚拟层，就相当于云上漂浮的这台超级隐形计算机的一个类似于物理机的虚拟机层。这样更方便我们去理解。

资源有了，资源可控化的封装接口有了，那么下一步就需要定义资源的具体管理了。这就是云操作系统。云操作系统管理云超级机的资源，但并不是从头实现，而是基于物理机或虚拟机里已有的OS来构建的。

资源管理，从层级上来看，也依赖于具体的实体。比如，针对物理机的集群管理，针对虚拟机的虚机管理和针对容器的容器管理。这些管理有很多相似性，首先是管理的实体，各种资源的控制要有。其次是实体的监控要有，哪些实体工作中，哪些实体闲置中都可以获知。任何实体都可能出现故障，因此OS还要能够探测到故障，并给出应对策略。接着是资源的调度要有，比如根据负载选择，尽量实现均衡。从商业角度来看，资源使用的计量要有，无论是按时间还是按别的指标。从上帝视角来看，一个用户提出资源需求，云OS要满足这种需求，而且要优雅的满足，保证设备的可靠运转。用完后，要能够给出计费结果。这就是这台超级隐形计算机操作系统的基本要求和需求。为了保障这些需要，还需要在可靠性、可用性、高性能、能耗、安全、易用性、可维护性等多个维度来做优化。实际中，Google、亚马逊、微软都有自己的云计算操作系统。开源领域，OpenStack比较流行。这主要是针对虚拟机层面。容器领域，kubernetes目前应用火热。它们面对的问题层次不同，解决方案也不同。我们把主要提供裸机和虚机的，称为IaaS，客户需要基于这类节点，自己搭建软件环境。这会在一定程度上节省购机、搭建机房、设备维护、人员管理等的费用开销。我们把提供虚机并且在其上提供基础软件比如操作系统、数据库、开发环境、部署环境等业务的称作PaaS。这在第一层次基础上，进一步节省了软件购买、授权、安装、维护等的开销。向面向最终业务的支撑更近了一步。对于容器，你把它当做一个平台，那么其就属于PaaS，你把它当做服务，那么就属于SaaS。我觉的这里不用非要将其划分到哪个层次，主要看对用户的价值。如果PaaS的工作你也懒得参与，那就只能使用SaaS了。这个前提是你的需求相对标准化，服务商已经针对这种需求，提供了标准化的开发流程和环境支撑。当然，如果你有领域特定的优势，也可以基于IaaS或者PaaS构建自家的SaaS，提供给其他用户使用。

 

如上图，系统层可能对外提供IaaS服务，也可能对外提供PaaS服务，还可能对外提供SaaS服务。

到此，一个基本的云计算框架就有了。我们只需将他们堆叠起来即可。

 

面对落地实践，这里的思考还远远不够。特别是对于PaaS层和SaaS层。回到最初的需求，我们想要的这台超级隐形计算机，最大的特点就是拥抱需求，拥抱变化。你想要一台物理机，或者一台虚拟机，或者多台，他们之间互联互通，这些都没有问题。因为这类需求，相对而言比较标准，每一个实体单元就是我们熟悉的CPU、内存、磁盘、带宽等。但是，更进一步，如果我们需要的不仅仅是机器，还有其上的软件，想想看，是不是面对的可能性空间就膨胀了。如果这个软件只是操作系统还好，现在流行的无非就是那几种系统，但如果进一步的扩展到了数据库，开发环境，运行环境、测试环境，各种工具和软件组合下来，空间就过于庞大了，不可能预备每一种组合。这个过程就需要用户参与了，有两种方案可选择，一种是云中提供尽可能多的各种软件和工具，用户选择后手动或者自动安装，这样一来，搭建时间就会比较长。另外，中间如果想卸载一部分，重新安装新的，该如何很好的实现，有良好的用户体验，也是需要仔细考虑的。考虑到中间可能出现故障，数据的备份恢复，镜像和快照工作也是少不了的。当然，还有另一种方案，就是容器。容器可以叠加，我们可以一层一层构建，也可以拿来直接用。因为容器就是应用的包装，不依赖安装，可以容易的复制迁移到不同的机器，效率和可靠性、容错恢复等，都有明显的提升。

有了机器，有了环境，你要做业务，就会产生数据。大部分信息系统，早期都是展示层、业务逻辑层和数据层的三层结构。数据层常常也会成为平台比较重要的一部分，为业务做好支撑。在互联网大爆发的时代，数据层也发生了一些变化，由之前主要是结构化数据为主逐步过渡到结构化数据和半结构化及非结构化数据共存的状态。大数据也在此基础上应用而生。而且，大数据的存储思路不再是之前集中式、关系化的基于特定存储硬件的统一数据库，而是分布式的、基于普通PC机的，建立于软件算法基础上的运算和存储分离的分布式文件系统。Hadoop是其中的代表。围绕其构建的大数据生态，极大地方便了大数据应用的开发，也为以数据为中心的业务构建，打下了坚实的基础。这样一来，我们可以将平台层抽象出来，不仅提供计算环境，也提供大数据存储分析环境。

 

平台搭建好了，那就该上业务了。不过，解耦一直是计算机领域解决复杂问题的重要抓手。业务的架构也是经历了好几代，从单体到分层，到面向服务SOA，再到当前流行的微服务、无服务器以及服务网格。之前博主也简单总结过一些，参考：三言两语说软件架构演变_软件架构技术的演变_龙赤子的博客-CSDN博客。微服务及之前的我们也就不再展开了，这里简单说说无服务器和服务网格。服务网格是针对微服务的问题而提出的，思路还是进一步的解耦。微服务多了后，服务之间的交互管理难题就逐渐突现出来，成为业务开发中过于关注的非业务内容。我们知道，基于云平台和各种框架进行业务开发，最终带来的是非功能属性的剥离。所有的方案都不会代替业务本身的开发。分布式事务、分布式锁、高并发、高安全、高可靠、高可用、高吞吐、高性能等多高指标，往往成为业务做大的绊脚石。这些东西不是业务层面的重点，但又会成为业务的枷锁，所以，解耦一直都是沿着这个思路进行的。当微服务交互问题暴露出来后，这一非业务功能的实现就可以继续解耦，这就促使服务网格架构的诞生。通过服务网格，由框架完成服务交互的管理，开发人员就可以继续将精力聚焦于业务本身的开发。

再来说说无服务器。网上虽然有很多介绍资料，但是我觉的很多都言过其实了。SaaS的思想是理解无服务器架构的利器。我们把业务层面再进一步标准化，提供API接口出来，开发人员只需调用这些API，就可以实现业务功能，完全感知不到服务器的存在。如何来理解这一点，举个例子，就好比你处于一个高度文明、高度发达、基础设施高度完善的社会，每天要吃饭时，对智能管家说我要吃什么，管家就能提供你需要的东西；要出门时，只需说目的地，管家自然将你送到目的地。这个过程中，你不需要知道这一切是谁最终提供给你的，你只管用最终的服务即可。

最后，关于云原生多说两句。注意了，它并不是某一种技术，而是一种开发思想，或者说是方法论。当然，我们也不能走极端，让它成为一个筐，什么都可以往里扔。总的来讲，上面的几种架构，应该可以应对大部分的业务场景了。

 

有了服务层的基础，那么后面就可以比较顺手的开发业务本身的应用了。这一层那就真的成是一个筐了，什么都可以尝试往里塞。还是回到起点，我们的需求是如何构建一台云上漂浮的超级隐形计算机。最终，这台计算机不仅要性能强悍，具备动态收缩扩容能力，还要能够方便使用。上面所述的各个层，就是为这些目标而构建的。到业务层，就该实际检验了。

 

起初，用户可以选择少量的计算和存储及网络资源，利用云上的微服务开发环境，采用云原生的思想，开发、部署、测试自己的业务。比如，开发一个照片分享的业务。开始时，因为用户数量比较少，我们的云机就显得比较瘦，这样租用费用就比较低。随着应用功能的丰富，注册用户的增多，资源的需求就会增加，这时，云机就要扩容了。但这一切，都可以通过点点鼠标，可视化的甚至自动化的完成，不需要传统模式的购机、环境搭建等一系列过程。而且，因为使用了云计算技术，网络带宽不仅可以随着业务量的增加而提升，还可以解决一系列迁移加速的问题。这样，在面向全国、甚至全球化的业务时，优势更加明显。如果我们业务中需要一些图形处理的高性能计算需求，云机也能帮助我们轻松解决。当业务积累到一定的数据量后，还可以基于这些数据，提供新的业务形式，这时候云机的大数据基础环境可以帮助我们解决数据存储、分析、挖掘的难题。随着人工智能在诸多领域垂直落地，我们还可以利用云机上的相关模型接口，采用无服务方式开发这类业务。可以看到，整个过程，自始至终，开发团队始终专注的是业务本身的需求，而业务攀升后带来的扩容、安全、管理、并发、性能等等一系列问题，也就是前述的非功能需求，这些在传统开发模式下会逐渐占据大量开发资源的情况，在云原生环境下，不再出现。这就是这台漂浮的超级隐形计算机带给我们的变革。冰山虽然越长越大，但这一切都被隐藏了起来。下面我们看看这台云机的总体架构。

 

上图中，补充了安全和管理。因为这两块其实是垂直贯通所有层的，故放在两侧。

到此，一切看起来都非常的美好。但前面讲过，计算机有两个特别重要的点，一个是平衡，一个是守恒。虽然上层越来越简单了，但是底层却越来越复杂。我们还能造多少轮子，软件的未来在哪里，这也许更值得人们思考。

PS：第一篇串联，说的是大的框架理论。此篇是落地实践的理论，细节更多一些。如果有机会，再来个串三，主要是在串二的基础上，抽取周期表中的关键框架，讲述如何落地实践。此路任重道远，吾将上下而求索。