云架构师学习------技术路线与总结

Avery123123

已于 2023-10-07 17:01:48 修改

阅读量795

点赞数

分类专栏：技术积累文章标签：学习

于 2023-09-04 15:02:06 首次发布

本文链接：https://blog.csdn.net/avery123123/article/details/131509182

版权

技术积累专栏收录该内容

6 篇文章 1 订阅

订阅专栏

云架构师学习------技术路线与总结

云架构师学习------技术路线与总结

云架构师学习------技术路线与总结

云架构师的技术路线梳理总结

一、什么是架构

IT架构-数据架构-应用架构

在这里插入图片描述

IT架构

简单理解IT架构就是：计算，网络，存储。这是云架构师的基本功，也是最传统的云架构师应该首先掌握的部分，良好设计的IT架构，可以降低CAPEX和OPEX，减轻运维的负担。数据中心，虚拟化，云平台，容器平台都属于IT架构的范畴。

应用架构

随着应用从传统应用向互联网应用转型，仅仅搞定资源层面的弹性还不够，常常会出现创建了大批机器，仍然撑不住高并发流量。因而基于微服务的互联网架构，越来越成为云架构师所必需的技能。良好设计的应用架构，可以实现快速迭代和高并发。数据库，缓存，消息队列等PaaS，以及基于SpringCloud和Dubbo的微服务框架，都属于应用架构的范畴。

数据架构

数据成为人工智能时代的核心资产，在做互联网化转型的同时，往往进行的也是数字化转型，并有战略的进行数据收集，这就需要云架构师同时又大数据思维。有意识的建设统一的数据平台，并给予数据进行数字化运营。搜索引擎，Hadoop，Spark，人工智能都属于数据架构的范畴。

架构的六个层面

从系统的角度出发，架构分六个层次
在这里插入图片描述
持续集成和持续发布是保证微服务拆分过程中的快速迭代，以及变更后保证功能不变的，不引入新的Bug。

服务发现和服务治理是微服务之间互相的调用，以及调用过程中出现异常情况下的熔断，限流，降级策略。

大数据和人工智能是通过收集各个层面的数据，例如用户访问数据，用户下单数据，客服询问数据等，结合统一的中台，对数据进行分析，实现智能推荐。

监控与APM是基础设施的监控和应用的监控，发现资源层面的问题以及应用调用的问题。

基础设施层

在数据中心里面，会有大量的机架，大量的服务器，并通过交换机和路由器将服务器连接起来，有的应用例如Oracle是需要部署在物理机上的。为了管理的方便，在物理机之上会部署虚拟化，例如Vmware，可以将对于物理机复杂的运维简化为虚拟机灵活的运维。虚拟化采取的运维方式多是由运维部门统一管理，当一个公司里面部门非常多的时候，往往要引入良好的租户管理，基于Quota和QoS的资源控制，基于VPC的网络规划等，实现从运维集中管理到租户自助使用模式的转换，托生于公有云的OpenStack在这方面做的是比较好的。随着应用架构越来越重要，对于标准化交付和弹性伸缩的需求越来越大，容器最为软件交付的集装箱，可以实现基于镜像的跨环境迁移，Kubernetes是容器管理平台的事实标准。

数据层

第二个层次是数据层，也即一个应用的中军大营，如果是传统应用，可能会使用Oracle，并使用大量的存储过程，有大量的表联合查询，成本也往往比较高。但是对于高并发的互联网应用，需要进行微服务的拆分，数据库实例会比较多，使用开源的Mysql是常见的选择，大量的存储过程和联合查询往往会使得微服务无法拆分，性能会比较差，因而需要放到应用层去做复杂的业务逻辑，数据库表和索引的设计非常重要。当并发量比较大的时候，需要实现横向扩展，就需要基于分布式数据库，也是需要基于单库良好的表和索引设计。对于结构比较灵活的数据，可以使用MongoDB数据库，横向扩展能力比较好。对于大量的联合查询需求，可以使用ElasticSearch之类的搜索引擎来做，速度快，更加灵活。

中间层

第三个层次是中间件层，因为数据库层往往需要保证数据的不丢失以及一些事务，因而并发性能不可能非常大，所以我们经常说，数据库是中军大营，不能所有的请求都到这里来，因而需要一层缓存层，用来拦截大部分的热点请求。Memcached适合做简单的key-value存储，内存使用率比较高，而且由于是多核处理，对于比较大的数据，性能较好。但是缺点也比较明显，Memcached严格来讲没有集群机制，横向扩展完全靠客户端来实现。另外Memcached无法持久化，一旦挂了数据就都丢失了，如果想实现高可用，也是需要客户端进行双写才可以。Redis的数据结构比较丰富，提供持久化的功能，提供成熟的主备同步，故障切换的功能，从而保证了高可用性。另外微服务拆分以后，有时候处理一个订单要经过非常多的服务，处理过程会比较慢，这个时候需要使用消息队列，让服务之间的调用变成对于消息的订阅，实现异步处理。RabbitMQ和Kafka是常用的消息队列，当事件比较重要的时候，会结合数据库实现可靠消息队列。

基础服务层

第四个层次是基础服务层，有的时候成为中台层，将通用的能力抽象为服务对外提供原子化接口。这样上层可以根据业务需求，通过灵活的组合这些原子化接口，灵活的应对业务需求的变化，实现能力的复用，以及数据的统一管理，例如用户数据，支付数据，不会分散到各个应用中。另外基础服务层称为应用和数据库和缓存的一个分界线，不应该所有的应用都直接连数据库，一旦出现分库分表，数据库迁移，缓存选型改变等，影响面会非常大，几乎无法执行。如果将这些底层的变更拦截在基础服务层，上层仅仅使用基础服务层的接口，这样底层的变化会对上层透明，可以逐步演进。

业务服务层

第五个层次是业务服务层，或者组合服务层，大部分的业务逻辑都是在这个层面实现，业务逻辑比较面向用户，因而会经常改变，所以需要组合基础服务的接口进行实现。在这一层，会经常进行服务的拆分，实现开发独立，上线独立，扩容独立，容灾降级独立。微服务的拆分不应该是一个运动，而应该是一个遇到耦合痛点的时候，不断解决，不断演进的一个过程。微服务拆分之后，有时候需要通过分布式事务，保证多个操作的原子性，也是在组合服务层来实现的。

用户接口层

第六个层次是用户接口层，也即对终端客户呈现出来的界面和APP，但是却不仅仅是界面这么简单。这一层有时候称为接入层。在这一层，动态资源和静态资源应该分离，静态资源应该在接入层做缓存，使用CDN进行缓存。也应该UI和API分离，界面应该通过组合API进行数据拼装。API会通过统一的API网关进行统一的管理和治理，一方面后端组合服务层的拆分对APP是透明的，一方面当并发量比较大的时候，可以在这一层实现限流和降级。

二、云计算的历史演进与基本原理

云计算的本质：资源到架构的全面弹性

在这里插入图片描述
云计算的本质是实现从资源到架构的全面弹性。所谓的弹性就是时间灵活性和空间灵活性，也即想什么时候要就什么时候要，想要多少就要多少。
资源层面的弹性也即实现计算、网络、存储资源的弹性。这个过程经历了从物理机，到虚拟化，到云计算的一个演进过程。

架构层面的弹性也即实现通用应用和自有应用的弹性扩展。对于通用的应用，多集成为PaaS平台。对于自己的应用，通过基于脚本的Puppet, Chef, Ansible到基于容器镜像的容器平台CaaS。

云计算如何管理应用

在这里插入图片描述
大数据包含数据的收集，数据的传输，数据的存储，数据的处理和分析，数据的检索和挖掘等几个过程

三、Linux基础知识

四、数据中心和网络基础知识

数据中心网络架构演进

传统三层网络

在这里插入图片描述
接入层：接入交换机通常位于机架顶部，所以它们也被称为ToR（Top of Rack）交换机，它们物理连接服务器。

汇聚层：汇聚交换机连接同一个二层网络（VLAN）下的接入交换机，同时提供其他的服务，例如防火墙，SSL offload，入侵检测，网络分析等，它可以是二层交换机也可以是三层交换机。

核心层：核心交换机为进出数据中心的包提供高速的转发，为多个二层局域网（VLAN）提供连接性，核心交换机为通常为整个网络提供一个弹性的三层网络。

存在的问题
带宽的浪费：为了防止环路，汇聚层和接入层之间通常会运行STP协议，使得接入交换机的上联链路中实际承载流量的只有一条，而其他上行链路将被阻塞（如图中虚线所示），造成了带宽的浪费；

故障域较大：STP协议由于其本身的算法，在网络拓扑发生变更时需要重新收敛，容易发生故障，从而影响整个VLAN的网络；

难以适应超大规模网络：在云计算领域，网络规模扩大，数据中心也分布在不同的地理位置，虚拟机要求能在任意地点创建，迁移，而保持其网络属性（IP, 网关等）保持不变，需要支持大二层网络，在上图的拓扑中，无法在VLAN10和VLAN20之间作上述迁移；

-----传统架构下，当存在大量东西向流量时，汇聚交换机和核心交换机的压力会大大增加，网络规模和性能也就限制在了汇聚层和核心层。要支持大规模的网络，就必须有性能最好，端口密度最大的汇聚层核心层设备，这样的设备成本高，不是所有企业都买得起，且必须在建设网络时就预先规划好网络规模，在网络规模小时，会造成资源的浪费，在网络规模继续扩大时，扩容也比较困难，因而让企事业单位陷入了成本和可扩展性的两难选择之中。

-----数据中心的流量总的来说可以分为以下几种：

· 南北向流量：数据中心之外的客户端到数据中心服务器之间的流量，或者数据中心服务器访问互联网的流量。

· 东西向流量：数据中心内的服务器之间的流量。

· 跨数据中心流量：不同数据中心的流量，例如数据中心之间的灾备，私有云和公有云之间的通讯。

在传统数据中心中，业务通常采用专线方式部署。通常，服务部署在一个或多个物理服务器上，并与其他系统物理隔离。因此，传统数据中心东西向流量较低，南北向流量约占数据中心总流量的80%。

在云数据中心，服务架构逐渐从单体架构转变为Web-APP-DB，分布式技术成为企业应用的主流。服务的组件通常分布在多个虚拟机或容器中。该服务不再由一台或多台物理服务器运行，而是由多台服务器协同工作，导致东西向流量快速增长。

此外，大数据服务的出现使分布式计算成为云数据中心的标准配置。大数据服务可以分布在一个数据中心的数百台服务器上进行并行计算，这也大大增加了东西向流量。

传统的三层网络架构是为南北向流量占主导地位的传统数据中心设计的，不适合东西向流量较大的云数据中心。

一些东西向流量(如跨POD的二层和三层流量)必须经过汇聚层和核心层的设备转发，不必要地经过许多节点。传统网络通常设置1:10到1:3的带宽超额比，以提高设备利用率。随着超额订阅率，每次流量通过节点时性能都会显着下降。此外，第 3 层网络上的 xSTP 技术加剧了这种恶化。

因此，如果通过传统三层网络架构运行大量的东西向流量，连接到同一交换机端口的设备可能会争夺带宽，导致最终用户获得的响应时间很差。

叶脊网络架构

Clos 网络以其发明者Charles Clos命名，Charles Clos是一名电话网络工程师，他在 1950 年代需要解决如何应对电话网络的爆炸式增长这一问题. 提出了现在称之为 Clos 的网络架构。

在这里插入图片描述
上图一个简单的两层Clos网络

Spine-Leaf体系架构是由Spine和Leaf这两个交换层组成的数据中心网络拓扑结构。Leaf层由访问交换机组成，汇聚来自服务器的流量，并直接连接到Spine或网络核心。Spine交换机在全网格拓扑中互连所有Leaf交换机。上图中，绿色节点代表交换机，灰色节点代表服务器。在绿色节点中，最上面的是Spine节点，下面是Leaf节点。

Spine-Leaf 网络架构，也称为分布式核心网络，由于这种网络架构来源于交换机内部的 Switch Fabric，因此也被称为 Fabric 网络架构，同属于 CLOS 网络模型。事实已经证明，Spine-Leaf 网络架构可以提供高带宽、低延迟、非阻塞的服务器到服务器连接。

前面说过 CLOS 网络是三级交换架构，而 Leaf Spine 却只有两层，这是因为：网络架构中的设备基本都是双向流量，输入设备同时也是输出设备，因此三级 CLOS 沿着中间层对折，就得到了两层的网络架构。可以看出传统的三层网络架构是垂直的结构，而 Spine-Leaf 网络架构是扁平的结构，从结构上看，Spine-Leaf 架构更易于水平扩展。

在这里插入图片描述
从拓扑结构上看，Spine-Leaf 二层架构视乎要比传统三层网络架构简单得多，但为什么 Spine-Leaf 直到近些年才能得到普及呢？技术成熟度固然是因素之一，再一个就是数据中心网络发展过程中无法回避的成本问题。传统三层网络架构只有核心交换机是昂贵的 L3 交换机，但 Spine-Leaf 却要求所有节点都应该是 L3 交换机。因此，Spine-Leaf 也只能在设备价格下降了的这些年才得以被推广。

Spine-Leaf 的工作原理

Leaf Switch：相当于传统三层架构中的接入交换机，作为 TOR（Top Of Rack）直接连接物理服务器。与接入交换机的区别在于 L2/L3 网络的分界点现在在 Leaf 交换机上了。Leaf 交换机之上是三层网络，Leaf 交换机之下都是个独立的 L2 广播域，这就解决了大二层网络的 BUM 问题。如果说两个 Leaf 交换机下的服务器需要通讯，需要通过 L3 路由，经由 Spine 交换机进行转发。
在这里插入图片描述
Spine Switch：相当于核心交换机。Spine 和 Leaf 交换机之间通过 ECMP（Equal Cost Multi Path）动态选择多条路径。区别在于，Spine 交换机现在只是为 Leaf 交换机提供一个弹性的 L3 路由网络，数据中心的南北流量可以不用直接从 Spine 交换机发出，一般来说，南北流量可以从与 Leaf 交换机并行的交换机（edge switch）再接到 WAN router 出去。
在这里插入图片描述
Fabric 中的 Leaf 层由接入交换机组成，用于接入服务器，Spine 层是网络的骨干（Backbone），负责将所有的 Leaf 连接起来。每个低层级的 Leaf 交换机都会连接到每个高层级的 Spine 交换机上，即每个 Leaf 交换机的上行链路数等于 Spine 交换机数量，同样，每个 Spine 交换机的下行链路数等于 Leaf 交换机的数量，形成一个 Full-Mesh 拓扑。当 Leaf 层的接入端口和上行链路都没有瓶颈时，这个架构就实现了无阻塞（Nonblocking）。并且，因为任意跨 Leaf 的两台服务器的连接，都会经过相同数量的设备，所以保证了延迟是可预测的，因为一个包只需要经过一个 Spine 和另一个 Leaf 就可以到达目的端。

因为 Fabric 中的每个 Leaf 都会连接到每个 Spine，所以，如果一个 Spine 挂了，数据中心的吞吐性能只会有轻微的下降（Slightly Degrade）。如果某个链路的流量被打满了，Spline-Leaf 的扩容过程也很简单：添加一个 Spine 交换机就可以扩展每个 Leaf 的上行链路，增大了 Leaf 和 Spine 之间的带宽，缓解了链路被打爆的问题。如果接入层的端口数量成为了瓶颈，那就直接添加一个新的 Leaf，然后将其连接到每个 Spine 并做相应的配置即可。这种易于扩展（Ease of Expansion）的特性优化了 IT 部门扩展网络的过程。

传统的三层网络架构由核心层、汇聚层和接入层组成，由于该结构中存在多设备多路径冗余，会导致环路的形成。与此同时，传统的三层网络架构主要是为了南北向流量而设计，虽然也支持东西向流量，但其不足非常明显，如浪费核心交换机资源、多层转发增加了延时、最终用户响应时间过长等。因此，传统的三层网络架构并不适用计算机和存储服务器四处分布的大型虚拟化数据中心。

注：南北向流量指数据中心之外的客户端到数据中心服务器之间的流量，或数据中心服务器访问互联网的流量；东西向流量值数据中心内的服务器之间的流量。

Spine-Leaf 的优势

扁平化：扁平化设计缩短服务器之间的通信路径，从而降低延迟，可以显著提高应用程序和服务性能。

易扩展：如果 Spine 交换机的带宽不足，我们只需要增加 Spine 节点数，也可以提供路径上的负载均衡；如果接入连接不足，则只需增加 Leaf 节点数。
低收敛比：容易实现 1:X 甚至是无阻塞的 1:1 的收敛比，而且通过增加 Spine 和 Leaf 设备间的链路带宽也可以降低链路收敛比。

简化管理：叶脊结构可以在无环路环境中使用全网格中的每个链路并进行负载平衡，这种等价多路径设计，在使用 SDN 等集中式网络管理平台时处于最佳状态。SDN 允许在发生堵塞或链路故障时简化流量的配置，管理和重新分配路由，使得智能负载均衡的全网状拓扑成为一个相对简单的配置和管理方式。

边缘流量处理：随着物联网（IoT）等业务的兴起，接入层压力剧增，可能有数千个传感器和设备在网络边缘连接并产生大量流量。Leaf 可以在接入层处理连接，Spine 保证节点内的任意两个端口之间提供延迟非常低的无阻塞性能，从而实现从接入到云平台的敏捷服务。

多云管理：数据中心或云之间通过 Leaf Spine 架构仍可以实现高性能、高容错等优势，而多云管理策略也逐渐成为企业的必选项。

Spine-Leaf 的缺陷

Fabric 架构并非完美。叶子节点网络设备无论是性能要求还是功能要求，均高于传统架构下的接入设备，其作为各种类型的网关（二三层间、VLAN/VxLAN 间、VxLAN/NVGRE 间、FC/IP 间等等），芯片处理能力要求较高，目前尚无满足所有协议间互通的商用芯片；由于不存在相关的标准，为了实现各种类型网络的接入，其骨干节点与叶子节点间的转发各个厂商均采用了私有封装，这也为将来的互通设置了难题。除此之外，还有：

独立的 L2 Domain 限制了依赖 L2 Domain 应用程序的部署。要求部署在一个二层网络的应用程序，现在只能部署下一个机架下了。
独立的 L2 Domain 限制了服务器的迁移。迁移到不同机架之后，网关和 IP 地址都要变。

子网数量大大增加了。每个子网对应数据中心一条路由，现在相当于每个机架都有一个子网，对应于整个数据中心的路由条数大大增加，并且这些路由信息要怎么传递到每个 Leaf 上，也是一个复杂的问题。

叶脊网络架构如何设计？

在设计叶脊网络架构之前，您必须先确定一些重要的因素。如，收敛比（即超额预订比率）、叶交换机与脊交换机的比例、从叶层到脊层的上行链路、构建在第2层还是第3层等。

收敛比（即超额预订比率）——指所有设备在相同时间内发送流量的比值，也就是指南北向流量（下行链路带宽）和东西向流量（上行链路带宽）的比值。当前的网络设计应遵循3:1的超额预订比率，也就是说下行端口（叶交换机到服务器或存储设备）和上行端口（叶交换机到脊交换机）的比值应达到3:1。下图说明了如何测量叶子层和脊椎层的超额预订比率。
在这里插入图片描述

叶交换机和脊交换机的比例——由于叶脊网络架构中的网络端点仅与叶交换机连接，因此网络中叶交换机部署数量取决于网络端点所需连接的接口数。而又因为每台叶交换机都需要连接到脊交换机，因此脊交换机的端口密度取决于拓扑结构中叶交换机的最大数量，同时，网络中的脊交换机的数量取决于叶交换机之间的吞吐量、叶子层的冗余/等价多路径（ECMP）数以及脊交换机中的端口密度。

从叶层到脊层的上行链路——对于叶脊网络，从叶子层到脊椎层的上行链路通常为10G/40G，且可从10G迁移到40G。为了避免网络不会因主机的增加造成阻塞，最好是确保上行链路的传输速率比下行链路的传输速率快。

叶脊架构可构建在第二层或第三层——叶脊网络架构可构建在第2层（任何VLAN）或第3层（子网）中。在第2层中构建叶脊网络架构时，能提供较高的灵活性，允许VLAN跨越任何地方，以及MAC地址可迁移到任何地方。在第3层中构建叶脊网络架构时，可提供最快的收敛时间和较优越的扩展性（可扩展至最大规模），同时，其具备扇出（也就是扇形发散）等价多路径（ECMP）路由功能，可支持32个或更多脊交换机。

Spine-Leaf架构的主要好处之一就是它允许数据流从数据的源到数据的目标路径较短。无论源和目的地如何，Spine-Leaf结构中的数据流在网络上的跳数都相同，任意两个服务器之间都是Leaf—>Spine—>Leaf三跳可达的。

由于Spine-Leaf 架构不再需要 STP（生成树协议），容量也得到了提高。其依赖诸如 ECMP(等价多路径)路由等协议来平衡所有可用路径上的流量，同时仍然避免网络环路。

基于OpenStack了解云平台

云是基于计算，网络，存储虚拟化技术的，云和虚拟化的主要区别在于，管理员的管理模式不同，用户的使用模式也不同。

虚拟化平台没有多层次的丰富的租户管理，没有灵活quota配额的限制，没有灵活的QoS的限制，多采用虚拟网络和物理网络打平的桥接模式，虚拟机直接使用机房网络，没有虚拟子网VPC的概念，虚拟网络的管理和隔离不能和租户隔离完全映射起来。对于存储也是，公司采购了统一的存储，也不能和租户的隔离完全映射起来。

用虚拟化平台的特点是，对于这个平台的操作完全由运维部门统一管理，而不能将权限下放给业务部门自己进行操作。因为一旦允许不同的部门自己操作，大家都用机房网络，在没有统一管控的情况下，很容易网段冲突了。如果业务部门向申请虚拟机，需要通过工单向运维部门统一的申请。当然这个运维部门很适应这种方式，因为原来物理机就是这样管理的。

但是公有云，例如aws就没办法这样，租户千千万万，只能他们自己操作。在私有云里面，随着服务化甚至微服务化的进行，服务数目越来越多，迭代速度越来越快，业务部门需要更加频繁的创建和消耗虚拟机，如果还是由运维部统一审批，统一操作，会使得运维部门压力非常大，而且极大限制了迭代速度，因而要引入租户管理，运维部灵活配置每个租户的配额quota和QoS，在这个配额里面，业务部门随时可以按照自己的需要，创建和删除虚拟机，无需知会运维部门。每个部门都可以创建自己的虚拟网络VPC，不同租户的VPC之前完全隔离，所以网段可以冲突，每个业务部门自己规划自己的网络架构，只有少数的机器需要被外网或者机房访问的时候，需要少数的机房IP，这个也是和租户映射起来的，可以分配给业务部门机房网IP的个数范围内，自由的使用。这样每个部门自主操作，迭代速度就能够加快了。

OpenStack的云平台设计模式

第一：基于PKI Token的认证模式

如果我们要实现一个Restful API，希望有个统一的认证中心的话，Keystone的三角形工作模式是常用的。
当我们要访问一个资源，通过用户名密码或者AK/SK登录之后，如果认证通过，接下来对于资源的访问，不应该总带着用户名密码，而是登录的时候形成一个Token，然后访问资源的时候带着Token，服务端通过Token去认证中心进行验证即可。
在这里插入图片描述

第二：基于Role Based Access Control的鉴权模式

对于权限控制，我们学会比较通用的Role Based Access Control的权限控制模式，形成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系，可以非常灵活的控制权限。
在这里插入图片描述

第三：基于Quota的配额管理

可以通过设置计算，网络，存储的quota，设置某个租户自己可以自主操作的资源量。

第四：基于预选和优选两阶段的Scheduler机制

当需要从一个资源池里面，选择一个节点，使用这个节点上的资源的时候，一个通用的Scheduler机制是：
• 首先进行预选，也即通过Filter，将不满足条件的过滤掉。
• 然后进行优选，也即对于过滤后，满足条件的候选人，通过计算权重，选择其中最优的。
在这里插入图片描述

第五：基于独立虚拟子网的网络模式

为了每个租户可以独立操作，因而虚拟网络应该是独立于物理网络的，这样不同的租户可以进行独立的网络规划而互不影响，也不影响物理网络，当需要跨租户访问，或者要访问物理网络的时候，需要通过路由器。
在这里插入图片描述

第六：基于Copy on Write的镜像机制

有时候我们在虚拟机里面做了一些操作以后，希望能够把这个时候的镜像保存下来，好随时恢复到这个时间点，一个最最简单的方法就是完全复制一份，但是由于镜像太大了，这样效率很差。因而采取Copy on write的机制，当打镜像的时刻，并没有新的存储消耗，而是当写入新的东西的时候，将原来的数据找一个地方复制保存下来，这就是Copy on Write。
对于Openstack，有一种镜像qcow2就是采取的这样的机制。
在这里插入图片描述