简介《云计算基础与应用》第二章“云计算技术架构”的个人学习笔记专门面向正在学习云计算基础课程的高校学生及自学者。笔记以课堂内容为主线系统梳理云计算三层架构模型基础架构层IaaS、中间层PaaS与应用层SaaS并对云管理层中的账号、配置、计费、运维等模块做了逐项说明。同时笔记进一步展开虚拟化技术专题涵盖计算虚拟化、存储虚拟化和网络虚拟化并以KVM为例讲解主流虚拟化方案帮助读者理解物理资源如何抽象为云服务掌握资源池、中间件、负载均衡等核心概念。资源为单个PDF文档共8.85MB属于纯文档资料便于随时翻阅。已有358人学习浏览适合作为课后复习、考前冲刺或第一轮入门梳理的参考资料能够快速建立云计算架构的整体框架。1. 把云计算技术架构的 PDF 当“排障地图”读别当概念书背做过云计算运维的同事大概都有同感一道故障报过来第一反应不是去翻云厂商控制台而是先判断问题出在计算层、存储层还是调度层。这份《云计算基础与应用 第二章 云计算技术架构.pdf》表面上是课件资料实际上把做判断需要的底图给全了——三层服务模型、参考架构组件、虚拟化的三条主要实现路径它都按条目列清楚了。对刚从传统运维转岗或者准备考云计算认证的人来说这份资源的最大价值不是背下 IaaS/PaaS/SaaS而是建立起“看到报错先画架构图、再动手改配置”的体感。本文按我自己归档和动手验证的顺序把这一章拆成一份可以直接照做的落地笔记。2. 从服务模型到组件清单先把抽象概念还原成排查方向2.1 IaaS / PaaS / SaaS 不是上下层是责任边界几乎所有人读这一章都会看到一页云图从下往上分成 IaaS、PaaS、SaaS 三层。它们在架构图上确实由下往上排列但真正做故障判断时这三层不是在比“谁更高”而是在划分“由谁来修”。IaaS 这一层负载均衡、操作系统、中间件乃至虚拟网络用户都可以自行调整到了 PaaS用户手里只剩应用代码和运行参数配套的运行时、伸缩策略、日志采集由平台统一维护再往上到 SaaS一整条业务链路都托管给服务商。这个视角在第二章里往往只有一段话但它直接决定你的排查顺序。我在生产环境里见过最多的误判就是把 PaaS 平台上的网络策略问题当成 IaaS 层的主机防火墙问题去解决。比如某个应用连不上另一个服务传统经验告诉你先到云主机里看 iptables但在 PaaS 模式下私有网络和安全组是平台级对象虚机内部未必有防火墙痕迹。如果你已经把“责任边界”代入架构图就不会在错误的一层浪费时间。所以我建议读第二章时先做一件事在每一层旁边写出“我能改什么、平台负责什么”而不是单纯记住三个英文缩写。2.2 参考架构的组件地图管理平面和资源平面为什么必须分开第二章的参考架构图通常会把产品做横纵切分横向是计算、存储、网络三类资源池纵向是管理功能。很多初学者以为“管理中间件”只是一些无关紧要的 API但它实际承担着身份认证、配额、计费、监控和调度策略。没有管理平面下面那些资源池只是一堆能跑虚机的物理机而已。把这一层摘清楚是我读这一章收获最大的一部分组件类别典型职责常见技术载体容易漏掉的坑计算资源池CPU 与内存的分配、回收、热迁移KVM、QEMU、容器运行时超配比会影响整机稳定性存储资源池卷、快照、克隆与备份Ceph、LVM、分布式块存储快照层数越多写入链路越长网络资源池虚拟交换机、隔离、QoSOVS、Linux Bridge、overlay管理网与业务网混跑是大忌管理中间件认证、调度、计量、APIKeystone、Nova、监控组件配额与计费信息不准会引发资源争抢服务接入层CLI、SDK、控制台、REST APIAPI Gateway、消息队列限流与鉴权策略常常上线后补这张表真正想强调的是“互相牵制”的关系这是第二章正文里很少明说、但架构师必须理解的部分。计算节点在扩容内存的同时会挤占同一宿主机的 IO 带宽网络 QoS 设置过高同样会影响存储的吞吐表现。遇到功能层面说不通的问题先看资源平面里哪个组件先到了瓶颈而不是急着改业务代码。2.3 用 Archimate 的元素关系举例子把读图变成建模做技术架构调研时很多人会用到 Archimate 这类建模语言来说明内部元素关系。它的表达方式很直接把架构对象之间的关系分为依赖、触发、实现、接入几种语义。用在第二章的“读图”上非常合适因为它能逼着你去回答“组件之间到底怎么连接”而不是停在“这个图里有哪些方块”。给一个可操作的练习用一条依赖链把“云主机—虚拟化层—宿主机—存储池—管理 API”串起来。比如一次虚拟机的启动动作可以拆成用户请求触发管理中间件管理中间件依赖调度器选择宿主机调度器依赖计算资源池获取可用 CPU 和内存最后通过虚拟化层完成实例创建。能画出这条链说明第二章的架构图在你脑子里真正活了。后端和运维同事联合排查时很多争议其实是在争论“当前谁依赖谁”如果有这张建模图沟通成本会明显下降。3. 虚拟化三条主线CPU、内存、I/O 的取舍要在生产环境算清楚3.1 CPU 虚拟化透传、半虚拟化、硬件辅助的选择逻辑第二章在虚拟化部分会讲三种 CPU 虚拟化方式完全模拟、半虚拟化、硬件辅助虚拟化。落到 Linux 虚拟化平台上完全模拟方式在实际工作中基本见不到最常见的是 KVM 结合硬件辅助虚拟化也就是利用 Intel VT-x 或 AMD-V 让 CPU 指令直接在物理核上运行。性能损耗虽小但不代表没有副作用硬件辅助虚拟化只解决了特权指令的捕获问题CPU 的调度仍然由宿主机负责多台虚机之间抢时间片的问题始终存在。这里给一个可落地的参数建议vCPU 总数与物理核总数的比例我一般控制在 2:1 到 3:1如果是数据库、实时计算这类延迟敏感业务直接按 1:1 分配。不要一拍脑袋决定“32 核宿主机跑 16 台 2C 虚机”业务高峰时它们同时抢物理核会产生明显的 CPU steal。观察方法很简单在宿主机上跑mpstat -P ALL 1盯住%steal列。这一列超过 10%说明虚拟 CPU 在等待物理 CPU 调度要么超配比例过高要么存在“噪音邻居”。3.2 内存虚拟化气球、回收、页合并三种机制不要全开内存虚拟化比 CPU 更容易被忽略。从实现方式看主流虚拟化平台都有三类内存管理功能内存气球、内存回收、页合并KSM。内存气球让宿主机按需“借走”虚机里的空闲内存内存回收是宿主机认为内存紧张时强制回收部分页面页合并则把多个虚机中内容相同的内存页合并成一份减少物理内存占用。这三个功能听起来都能省内存但绝不建议同时按默认值开启。开气球后如果虚机内部应用本身正全力使用内存气球会频繁收缩换来的是明显的性能抖动。页合并适用于大量同规格、同镜像的重复负载省内存的效果很明显但代价是额外 CPU 开销而且共享内存页在安全隔离上也存在隐患。我的习惯是生产环境只启用气球机制透明大页和内存回收做最低保障评估某个功能时才在测试环境临时开页合并对比开启前后的 CPU 和内存监控曲线。3.3 网络与存储 I/O虚拟化里最容易被低估的链路开销把第二章的网络虚拟化部分读细会发现文档不会只说“虚拟网卡连到虚拟交换机”还会提到网络 I/O 路径。一条数据从虚机内部发出去至少要穿透“应用 → 内核协议栈 → 虚拟网卡 → 虚拟交换机 → 物理网卡”五个环节每一层都可能引入拷贝、中断和锁竞争。性能敏感场景下的常见做法是把 virtio 多队列数调整到与 vCPU 数量一致并让 vhost 处理数据面减少用户态和内核态的切换。KVM 虚机配置里可以为 interface 增加多队列参数配合virsh vcpuinfo观察 vCPU 和队列的绑定状态。存储 I/O 同理。虚机的虚拟磁盘在宿主机里可能是 raw 映像也可能是 qcow2 增量文件。qcow2 支持快照和按需分配但读一条数据需要多一层元数据解析频繁写入还会造成磁盘碎片。如果用它承载数据库建议把缓存模式设置为 none避免虚机内部页缓存与宿主机页缓存叠加成双重缓存造成性能假象。这些细节第二章通常只当概念引入可它们才是上线后决定虚机稳定性的关键参数。4. 把第二章落到本地环境用 KVM 建一条最小验证链路4.1 规划最小架构一台宿主机同时充当管理平面和资源平面作为入门操作不值得一上来就搭 OpenStack 或 Kubernetes 全家桶。用 KVM 加 libvirt 就能验证第二章里的“资源池”和“管理中间件”实际是怎么协作的。我的做法是找一台 16G 内存以上的 X86 机器装 Ubuntu Server 22.04 LTS然后安装最基础的一套工具sudo apt update sudo apt install -y qemu-kvm libvirt-daemon-system virtinst bridge-utils sudo systemctl enable --now libvirtd安装完成后先做环境自检确认硬件虚拟化是否可用、libvirt 守护进程是否正常egrep -c (vmx|svm) /proc/cpuinfo virsh list --all第一条命令输出 0说明 BIOS 里没开 CPU 硬件虚拟化需要重启进 BIOS 开启 VT-x 或 AMD-V第二条命令如果报连接失败优先执行systemctl status libvirtd看守护进程日志。这套组合对应到第二章就是“虚拟化引擎 管理中间件”两段KVM 是内核模块QEMU 负责设备模拟libvirtd 负责 API 和实例生命周期管理。sudo usermod -aG libvirt $(whoami) newgrp libvirt执行完这两条命令再看virsh list --all权限问题通常会消失。到这里“计算资源池”这个抽象概念就变成了本机上一个可操作的管理对象。4.2 创建第一台虚拟机把 CPU、内存、磁盘参数逐一对上环境就绪后创建一台带参数的虚拟机。我不建议一开始就依赖图形界面图形界面会隐藏参数之间的映射关系命令行反而更直观sudo virt-install \ --name demo-vm \ --memory 2048 \ --vcpus 2 \ --disk size20,formatqcow2 \ --cdrom /home/user/ubuntu-22.04-server.iso \ --os-variant ubuntu22.04 \ --network networkdefault \ --noautoconsole--memory 2048分配 2048MiB 内存对应参考架构里计算资源池的内存配额。--vcpus 2分配两个虚拟 CPU注意是 vCPU 而不是物理核默认由宿主机调度。--disk size20,formatqcow2创建 20GiB 的 qcow2 磁盘映像对应存储资源池里的卷。--network networkdefault使用 libvirt 自带的虚拟 NAT 网络对应网络资源池里的虚拟交换机。--noautoconsole创建完成后不自动进入控制台方便后续用命令持续管理。创建完成后用virsh list --all查看状态。如果出现 ERROR优先打开/var/log/libvirt/qemu/demo-vm.log里面通常直接记录了失败原因。这一步跑通你就完成了“资源请求 → 管理中间件 → 虚拟化层 → 资源池”的最小闭环这也是第二章架构图里最核心的一条主链路。4.3 资源测绘用三条命令感受调度和 QoS 的真实存在虚拟机运行起来后我习惯做两个小实验一是看 vCPU 与物理 CPU 的映射关系二是给虚拟磁盘加一个限速体验 QoS 从配置到生效的整个过程virsh vcpupin demo-vm 0 0-1 virsh vcpuinfo demo-vm virsh blkdeviotune demo-vm vda --read-bytes-sec 10485760 --write-bytes-sec 10485760第一行把 demo-vm 的第 0 个 vCPU 绑定到宿主机 0-1 号物理核上这是 CPU 绑定的一种轻度实践第二行查看 vCPU 当前落在哪些物理核上帮助你理解调度器的行为第三行给虚拟磁盘设置每秒 10MiB 的读写限速对应存储资源池的 QoS 控制。如果在虚机内部执行dd if/dev/zero of/tmp/test bs1M count200 oflagdirect写一个 200MiB 的文件你会观察到实际速率被限速控制在 10MiB/s 左右。这个实验会彻底改变你对“QoS 只是监控面板上一个数字”的误解也会让你更愿意相信第二章里“资源池具备配额和限速能力”这句话是实打实的设计。5. 学习云计算技术架构的四个常见误区与踩坑排查5.1 把虚拟化等同于装一套虚拟机软件现象第一次部署 KVM 时只在宿主机上装好virt-manager之后就不再关心底层参数虚拟机一多宿主机就频繁假死。原因把管理工具当成了虚拟化本身忽视了 qemu-kvm 和 libvirt 只是管理入口真正的资源分配发生在内核模块和 QEMU 进程里。虚拟机假死的根源往往在超配比、内存气球和调度策略上。解决回读第二章的计算资源池部分重新确认 CPU 超配比、内存气球状态和 IO 调度方式用mpstat、free -h、iostat三条命令定位宿主机压力来源而不是继续盲目加虚拟机规格。5.2 只记住服务模型却没有建立管理平面的概念现象两个租户在同一台物理机上的虚拟机网络互通正常但用户投诉存在数据泄露风险排查时却不知道在哪一层设置隔离边界。原因只从功能角度记住了 IaaS、PaaS、SaaS 三层忽略了管理中间件里“租户”“项目”“安全组”这些资源对象。租户隔离不是网络设备自动完成的它依赖管理平面的策略下发。解决养成“任何网络访问都必须先过安全组或虚拟防火墙”的排查习惯。在 OpenStack 环境里先查 neutron 安全组规则不要一上来就在宿主机上翻 iptables。第二章里管理平面那条纵轴就是在不断提醒你这件事。5.3 宿主机的内存规格按满配计算现象一台 32G 内存的宿主机直接创建 8 台 4G 内存的虚机业务低峰期正常高峰期内存耗尽触发 OOM。原因没有给管理平面和操作系统页缓存预留余量也没有考虑内存气球机制在虚机实际占用升高时能否及时回收。低频运行不等于低频占用业务高峰到来时内存压力会瞬间集中爆发。解决预留宿主机物理内存的 20% 给管理平面、内核和页缓存剩余部分再按超配比分配给虚机。不要用“内存总数除以单机规格”这种算法生产环境的资源规划从来不是运动会上的除法题。5.4 把存储快照当成备份来用现象虚机磁盘被误删运维同事说“我们有快照可以恢复”结果从快照恢复后仍然丢失了最近几个小时的数据。原因快照记录的是某个时间点的变化前状态它依赖源卷仍然存在也无法覆盖源卷损坏的极端场景。备份则是独立的离线副本两者在架构图里属于不同层级的保护手段。解决在笔记里把快照和备份分开画快照属于存储资源池内部的变更回退点备份属于管理中间件之上的灾备服务。生产环境至少保留一个独立副本快照只用于变更前后的回退验证。5.5 libvirt 权限报错被误判为虚拟化组件损坏现象执行virsh list --all报 “Failed to connect socket to /var/run/libvirt/libvirt-sock: Permission denied”第一反应是重装 libvirt。原因当前用户不在 libvirt 用户组里socket 文件权限不足。这和虚拟化组件本身是否损坏没有关系属于最基础的权限问题却经常占用不少排查时间。解决执行sudo usermod -aG libvirt $(whoami)加组再执行newgrp libvirt刷新组权限。如果用户组里已经有该用户就检查/var/run/libvirt/libvirt-sock的属组和权限位。这类问题记在笔记里能省掉一次重启宿主机的代价。6. 从第二章走向云原生用同一套架构语言读 Kubernetes读这份 PDF 时如果只看虚拟化部分容易产生“这套架构已经过时”的错觉。但第二章最核心的部分——资源池、管理中间件、调度、配额、网络隔离——放到 Kubernetes 环境下其实原封不动地存在只是换了对象名。我建议你读完第二章后顺手做一张映射表把经典云计算架构映射到云原生架构上第二章概念Kubernetes 对应物计算资源池节点池与 Node 可分配资源虚拟化层容器运行时containerd、CRI-O管理中间件控制平面API Server、调度器、控制器网络资源池CNI 插件与 Service 网段存储资源池CSI 插件与 PersistentVolume服务接入层kubectl 与 API Server有了这张表你看到 Kubernetes 报错时会自动把它对应回第二章的架构坐标里。比如 Pod 调度失败本质上是调度器依赖计算资源池时发现 CPU 或内存不足和虚拟化平台里资源超配导致虚拟机创建失败是同一类问题。理解到这一层才叫真正读懂了第二章。云原生兴起之后很多人喜欢讨论“技术架构研究调查”这类话题比如流数据处理层面的 Kappa 架构、离线计算与实时计算的融合方案。这些听起来和第二章无关但你会发现它们的讨论方式仍然沿用同一种语言资源和计算逻辑如何分层调度和容错放在哪一层管理面与数据面如何分离。换个场景底层逻辑没变。养成一个习惯每拿到一份架构相关文档先跳过目录直接在纸上画组件依赖图画完再回到文档正文校对。这个习惯帮我少踩了很多排错的坑也让我在团队评审架构时不会只停留在名词层面。第二章这份 PDF 能不能发挥价值不取决于你翻了多少页而取决于你能不能清楚写出“一条请求从用户侧到资源池的完整链路”。希望这份拆解笔记能帮到你也少走我当年走过的弯路。本文还有配套的精品资源点击获取
云计算技术架构拆解：从服务模型到KVM虚拟化实践
简介《云计算基础与应用》第二章“云计算技术架构”的个人学习笔记专门面向正在学习云计算基础课程的高校学生及自学者。笔记以课堂内容为主线系统梳理云计算三层架构模型基础架构层IaaS、中间层PaaS与应用层SaaS并对云管理层中的账号、配置、计费、运维等模块做了逐项说明。同时笔记进一步展开虚拟化技术专题涵盖计算虚拟化、存储虚拟化和网络虚拟化并以KVM为例讲解主流虚拟化方案帮助读者理解物理资源如何抽象为云服务掌握资源池、中间件、负载均衡等核心概念。资源为单个PDF文档共8.85MB属于纯文档资料便于随时翻阅。已有358人学习浏览适合作为课后复习、考前冲刺或第一轮入门梳理的参考资料能够快速建立云计算架构的整体框架。1. 把云计算技术架构的 PDF 当“排障地图”读别当概念书背做过云计算运维的同事大概都有同感一道故障报过来第一反应不是去翻云厂商控制台而是先判断问题出在计算层、存储层还是调度层。这份《云计算基础与应用 第二章 云计算技术架构.pdf》表面上是课件资料实际上把做判断需要的底图给全了——三层服务模型、参考架构组件、虚拟化的三条主要实现路径它都按条目列清楚了。对刚从传统运维转岗或者准备考云计算认证的人来说这份资源的最大价值不是背下 IaaS/PaaS/SaaS而是建立起“看到报错先画架构图、再动手改配置”的体感。本文按我自己归档和动手验证的顺序把这一章拆成一份可以直接照做的落地笔记。2. 从服务模型到组件清单先把抽象概念还原成排查方向2.1 IaaS / PaaS / SaaS 不是上下层是责任边界几乎所有人读这一章都会看到一页云图从下往上分成 IaaS、PaaS、SaaS 三层。它们在架构图上确实由下往上排列但真正做故障判断时这三层不是在比“谁更高”而是在划分“由谁来修”。IaaS 这一层负载均衡、操作系统、中间件乃至虚拟网络用户都可以自行调整到了 PaaS用户手里只剩应用代码和运行参数配套的运行时、伸缩策略、日志采集由平台统一维护再往上到 SaaS一整条业务链路都托管给服务商。这个视角在第二章里往往只有一段话但它直接决定你的排查顺序。我在生产环境里见过最多的误判就是把 PaaS 平台上的网络策略问题当成 IaaS 层的主机防火墙问题去解决。比如某个应用连不上另一个服务传统经验告诉你先到云主机里看 iptables但在 PaaS 模式下私有网络和安全组是平台级对象虚机内部未必有防火墙痕迹。如果你已经把“责任边界”代入架构图就不会在错误的一层浪费时间。所以我建议读第二章时先做一件事在每一层旁边写出“我能改什么、平台负责什么”而不是单纯记住三个英文缩写。2.2 参考架构的组件地图管理平面和资源平面为什么必须分开第二章的参考架构图通常会把产品做横纵切分横向是计算、存储、网络三类资源池纵向是管理功能。很多初学者以为“管理中间件”只是一些无关紧要的 API但它实际承担着身份认证、配额、计费、监控和调度策略。没有管理平面下面那些资源池只是一堆能跑虚机的物理机而已。把这一层摘清楚是我读这一章收获最大的一部分组件类别典型职责常见技术载体容易漏掉的坑计算资源池CPU 与内存的分配、回收、热迁移KVM、QEMU、容器运行时超配比会影响整机稳定性存储资源池卷、快照、克隆与备份Ceph、LVM、分布式块存储快照层数越多写入链路越长网络资源池虚拟交换机、隔离、QoSOVS、Linux Bridge、overlay管理网与业务网混跑是大忌管理中间件认证、调度、计量、APIKeystone、Nova、监控组件配额与计费信息不准会引发资源争抢服务接入层CLI、SDK、控制台、REST APIAPI Gateway、消息队列限流与鉴权策略常常上线后补这张表真正想强调的是“互相牵制”的关系这是第二章正文里很少明说、但架构师必须理解的部分。计算节点在扩容内存的同时会挤占同一宿主机的 IO 带宽网络 QoS 设置过高同样会影响存储的吞吐表现。遇到功能层面说不通的问题先看资源平面里哪个组件先到了瓶颈而不是急着改业务代码。2.3 用 Archimate 的元素关系举例子把读图变成建模做技术架构调研时很多人会用到 Archimate 这类建模语言来说明内部元素关系。它的表达方式很直接把架构对象之间的关系分为依赖、触发、实现、接入几种语义。用在第二章的“读图”上非常合适因为它能逼着你去回答“组件之间到底怎么连接”而不是停在“这个图里有哪些方块”。给一个可操作的练习用一条依赖链把“云主机—虚拟化层—宿主机—存储池—管理 API”串起来。比如一次虚拟机的启动动作可以拆成用户请求触发管理中间件管理中间件依赖调度器选择宿主机调度器依赖计算资源池获取可用 CPU 和内存最后通过虚拟化层完成实例创建。能画出这条链说明第二章的架构图在你脑子里真正活了。后端和运维同事联合排查时很多争议其实是在争论“当前谁依赖谁”如果有这张建模图沟通成本会明显下降。3. 虚拟化三条主线CPU、内存、I/O 的取舍要在生产环境算清楚3.1 CPU 虚拟化透传、半虚拟化、硬件辅助的选择逻辑第二章在虚拟化部分会讲三种 CPU 虚拟化方式完全模拟、半虚拟化、硬件辅助虚拟化。落到 Linux 虚拟化平台上完全模拟方式在实际工作中基本见不到最常见的是 KVM 结合硬件辅助虚拟化也就是利用 Intel VT-x 或 AMD-V 让 CPU 指令直接在物理核上运行。性能损耗虽小但不代表没有副作用硬件辅助虚拟化只解决了特权指令的捕获问题CPU 的调度仍然由宿主机负责多台虚机之间抢时间片的问题始终存在。这里给一个可落地的参数建议vCPU 总数与物理核总数的比例我一般控制在 2:1 到 3:1如果是数据库、实时计算这类延迟敏感业务直接按 1:1 分配。不要一拍脑袋决定“32 核宿主机跑 16 台 2C 虚机”业务高峰时它们同时抢物理核会产生明显的 CPU steal。观察方法很简单在宿主机上跑mpstat -P ALL 1盯住%steal列。这一列超过 10%说明虚拟 CPU 在等待物理 CPU 调度要么超配比例过高要么存在“噪音邻居”。3.2 内存虚拟化气球、回收、页合并三种机制不要全开内存虚拟化比 CPU 更容易被忽略。从实现方式看主流虚拟化平台都有三类内存管理功能内存气球、内存回收、页合并KSM。内存气球让宿主机按需“借走”虚机里的空闲内存内存回收是宿主机认为内存紧张时强制回收部分页面页合并则把多个虚机中内容相同的内存页合并成一份减少物理内存占用。这三个功能听起来都能省内存但绝不建议同时按默认值开启。开气球后如果虚机内部应用本身正全力使用内存气球会频繁收缩换来的是明显的性能抖动。页合并适用于大量同规格、同镜像的重复负载省内存的效果很明显但代价是额外 CPU 开销而且共享内存页在安全隔离上也存在隐患。我的习惯是生产环境只启用气球机制透明大页和内存回收做最低保障评估某个功能时才在测试环境临时开页合并对比开启前后的 CPU 和内存监控曲线。3.3 网络与存储 I/O虚拟化里最容易被低估的链路开销把第二章的网络虚拟化部分读细会发现文档不会只说“虚拟网卡连到虚拟交换机”还会提到网络 I/O 路径。一条数据从虚机内部发出去至少要穿透“应用 → 内核协议栈 → 虚拟网卡 → 虚拟交换机 → 物理网卡”五个环节每一层都可能引入拷贝、中断和锁竞争。性能敏感场景下的常见做法是把 virtio 多队列数调整到与 vCPU 数量一致并让 vhost 处理数据面减少用户态和内核态的切换。KVM 虚机配置里可以为 interface 增加多队列参数配合virsh vcpuinfo观察 vCPU 和队列的绑定状态。存储 I/O 同理。虚机的虚拟磁盘在宿主机里可能是 raw 映像也可能是 qcow2 增量文件。qcow2 支持快照和按需分配但读一条数据需要多一层元数据解析频繁写入还会造成磁盘碎片。如果用它承载数据库建议把缓存模式设置为 none避免虚机内部页缓存与宿主机页缓存叠加成双重缓存造成性能假象。这些细节第二章通常只当概念引入可它们才是上线后决定虚机稳定性的关键参数。4. 把第二章落到本地环境用 KVM 建一条最小验证链路4.1 规划最小架构一台宿主机同时充当管理平面和资源平面作为入门操作不值得一上来就搭 OpenStack 或 Kubernetes 全家桶。用 KVM 加 libvirt 就能验证第二章里的“资源池”和“管理中间件”实际是怎么协作的。我的做法是找一台 16G 内存以上的 X86 机器装 Ubuntu Server 22.04 LTS然后安装最基础的一套工具sudo apt update sudo apt install -y qemu-kvm libvirt-daemon-system virtinst bridge-utils sudo systemctl enable --now libvirtd安装完成后先做环境自检确认硬件虚拟化是否可用、libvirt 守护进程是否正常egrep -c (vmx|svm) /proc/cpuinfo virsh list --all第一条命令输出 0说明 BIOS 里没开 CPU 硬件虚拟化需要重启进 BIOS 开启 VT-x 或 AMD-V第二条命令如果报连接失败优先执行systemctl status libvirtd看守护进程日志。这套组合对应到第二章就是“虚拟化引擎 管理中间件”两段KVM 是内核模块QEMU 负责设备模拟libvirtd 负责 API 和实例生命周期管理。sudo usermod -aG libvirt $(whoami) newgrp libvirt执行完这两条命令再看virsh list --all权限问题通常会消失。到这里“计算资源池”这个抽象概念就变成了本机上一个可操作的管理对象。4.2 创建第一台虚拟机把 CPU、内存、磁盘参数逐一对上环境就绪后创建一台带参数的虚拟机。我不建议一开始就依赖图形界面图形界面会隐藏参数之间的映射关系命令行反而更直观sudo virt-install \ --name demo-vm \ --memory 2048 \ --vcpus 2 \ --disk size20,formatqcow2 \ --cdrom /home/user/ubuntu-22.04-server.iso \ --os-variant ubuntu22.04 \ --network networkdefault \ --noautoconsole--memory 2048分配 2048MiB 内存对应参考架构里计算资源池的内存配额。--vcpus 2分配两个虚拟 CPU注意是 vCPU 而不是物理核默认由宿主机调度。--disk size20,formatqcow2创建 20GiB 的 qcow2 磁盘映像对应存储资源池里的卷。--network networkdefault使用 libvirt 自带的虚拟 NAT 网络对应网络资源池里的虚拟交换机。--noautoconsole创建完成后不自动进入控制台方便后续用命令持续管理。创建完成后用virsh list --all查看状态。如果出现 ERROR优先打开/var/log/libvirt/qemu/demo-vm.log里面通常直接记录了失败原因。这一步跑通你就完成了“资源请求 → 管理中间件 → 虚拟化层 → 资源池”的最小闭环这也是第二章架构图里最核心的一条主链路。4.3 资源测绘用三条命令感受调度和 QoS 的真实存在虚拟机运行起来后我习惯做两个小实验一是看 vCPU 与物理 CPU 的映射关系二是给虚拟磁盘加一个限速体验 QoS 从配置到生效的整个过程virsh vcpupin demo-vm 0 0-1 virsh vcpuinfo demo-vm virsh blkdeviotune demo-vm vda --read-bytes-sec 10485760 --write-bytes-sec 10485760第一行把 demo-vm 的第 0 个 vCPU 绑定到宿主机 0-1 号物理核上这是 CPU 绑定的一种轻度实践第二行查看 vCPU 当前落在哪些物理核上帮助你理解调度器的行为第三行给虚拟磁盘设置每秒 10MiB 的读写限速对应存储资源池的 QoS 控制。如果在虚机内部执行dd if/dev/zero of/tmp/test bs1M count200 oflagdirect写一个 200MiB 的文件你会观察到实际速率被限速控制在 10MiB/s 左右。这个实验会彻底改变你对“QoS 只是监控面板上一个数字”的误解也会让你更愿意相信第二章里“资源池具备配额和限速能力”这句话是实打实的设计。5. 学习云计算技术架构的四个常见误区与踩坑排查5.1 把虚拟化等同于装一套虚拟机软件现象第一次部署 KVM 时只在宿主机上装好virt-manager之后就不再关心底层参数虚拟机一多宿主机就频繁假死。原因把管理工具当成了虚拟化本身忽视了 qemu-kvm 和 libvirt 只是管理入口真正的资源分配发生在内核模块和 QEMU 进程里。虚拟机假死的根源往往在超配比、内存气球和调度策略上。解决回读第二章的计算资源池部分重新确认 CPU 超配比、内存气球状态和 IO 调度方式用mpstat、free -h、iostat三条命令定位宿主机压力来源而不是继续盲目加虚拟机规格。5.2 只记住服务模型却没有建立管理平面的概念现象两个租户在同一台物理机上的虚拟机网络互通正常但用户投诉存在数据泄露风险排查时却不知道在哪一层设置隔离边界。原因只从功能角度记住了 IaaS、PaaS、SaaS 三层忽略了管理中间件里“租户”“项目”“安全组”这些资源对象。租户隔离不是网络设备自动完成的它依赖管理平面的策略下发。解决养成“任何网络访问都必须先过安全组或虚拟防火墙”的排查习惯。在 OpenStack 环境里先查 neutron 安全组规则不要一上来就在宿主机上翻 iptables。第二章里管理平面那条纵轴就是在不断提醒你这件事。5.3 宿主机的内存规格按满配计算现象一台 32G 内存的宿主机直接创建 8 台 4G 内存的虚机业务低峰期正常高峰期内存耗尽触发 OOM。原因没有给管理平面和操作系统页缓存预留余量也没有考虑内存气球机制在虚机实际占用升高时能否及时回收。低频运行不等于低频占用业务高峰到来时内存压力会瞬间集中爆发。解决预留宿主机物理内存的 20% 给管理平面、内核和页缓存剩余部分再按超配比分配给虚机。不要用“内存总数除以单机规格”这种算法生产环境的资源规划从来不是运动会上的除法题。5.4 把存储快照当成备份来用现象虚机磁盘被误删运维同事说“我们有快照可以恢复”结果从快照恢复后仍然丢失了最近几个小时的数据。原因快照记录的是某个时间点的变化前状态它依赖源卷仍然存在也无法覆盖源卷损坏的极端场景。备份则是独立的离线副本两者在架构图里属于不同层级的保护手段。解决在笔记里把快照和备份分开画快照属于存储资源池内部的变更回退点备份属于管理中间件之上的灾备服务。生产环境至少保留一个独立副本快照只用于变更前后的回退验证。5.5 libvirt 权限报错被误判为虚拟化组件损坏现象执行virsh list --all报 “Failed to connect socket to /var/run/libvirt/libvirt-sock: Permission denied”第一反应是重装 libvirt。原因当前用户不在 libvirt 用户组里socket 文件权限不足。这和虚拟化组件本身是否损坏没有关系属于最基础的权限问题却经常占用不少排查时间。解决执行sudo usermod -aG libvirt $(whoami)加组再执行newgrp libvirt刷新组权限。如果用户组里已经有该用户就检查/var/run/libvirt/libvirt-sock的属组和权限位。这类问题记在笔记里能省掉一次重启宿主机的代价。6. 从第二章走向云原生用同一套架构语言读 Kubernetes读这份 PDF 时如果只看虚拟化部分容易产生“这套架构已经过时”的错觉。但第二章最核心的部分——资源池、管理中间件、调度、配额、网络隔离——放到 Kubernetes 环境下其实原封不动地存在只是换了对象名。我建议你读完第二章后顺手做一张映射表把经典云计算架构映射到云原生架构上第二章概念Kubernetes 对应物计算资源池节点池与 Node 可分配资源虚拟化层容器运行时containerd、CRI-O管理中间件控制平面API Server、调度器、控制器网络资源池CNI 插件与 Service 网段存储资源池CSI 插件与 PersistentVolume服务接入层kubectl 与 API Server有了这张表你看到 Kubernetes 报错时会自动把它对应回第二章的架构坐标里。比如 Pod 调度失败本质上是调度器依赖计算资源池时发现 CPU 或内存不足和虚拟化平台里资源超配导致虚拟机创建失败是同一类问题。理解到这一层才叫真正读懂了第二章。云原生兴起之后很多人喜欢讨论“技术架构研究调查”这类话题比如流数据处理层面的 Kappa 架构、离线计算与实时计算的融合方案。这些听起来和第二章无关但你会发现它们的讨论方式仍然沿用同一种语言资源和计算逻辑如何分层调度和容错放在哪一层管理面与数据面如何分离。换个场景底层逻辑没变。养成一个习惯每拿到一份架构相关文档先跳过目录直接在纸上画组件依赖图画完再回到文档正文校对。这个习惯帮我少踩了很多排错的坑也让我在团队评审架构时不会只停留在名词层面。第二章这份 PDF 能不能发挥价值不取决于你翻了多少页而取决于你能不能清楚写出“一条请求从用户侧到资源池的完整链路”。希望这份拆解笔记能帮到你也少走我当年走过的弯路。本文还有配套的精品资源点击获取