3. 虚拟机性能优化
Azure 虚拟机的性能并不是由单一参数决定的，而是由计算、存储、网络三条资源路径共同约束。任何一条路径成为瓶颈，整体吞吐或响应时间都会受限。因此，优化 VM 性能的第一步不是“调参数”，而是判断当前工作负载究竟受限于哪条路径，再针对性地选择 VM 系列、磁盘类型、缓存模式和网络能力。
一、VM 大小选型：先看约束，再看规格
Azure 的 VM 大小按系列划分，每个系列在 vCPU 与内存比例、本地磁盘类型、网络带宽、是否支持加速网络、是否支持高级存储等方面存在差异。选型时应先明确三个约束：
- 计算特征：是持续高 CPU、突发型、内存密集，还是 GPU/FPGA 加速型。
- 内存与 vCPU 比例：通用型（如 D 系列）约为 1:4，内存优化型（如 E 系列）约为 1:8，计算优化型（如 F 系列）约为 1:2。
- 存储与网络上限：每个大小都有明确的“最大数据磁盘数”“最大缓存与临时磁盘吞吐”“预期网络带宽”。
例如，一个运行 SQL Server 的虚拟机，若内存不足会导致大量物理读，即使 CPU 空闲也会表现为查询缓慢。此时应优先选择 E 系列或 M 系列，而不是单纯提升 vCPU 数量。反之，一个高并发 Web 前端若 CPU 长期饱和、内存占用平稳，则应考虑 F 系列或增加实例数量横向扩展。
选型时还要注意“预期网络带宽”和“最大网络带宽”的区别：前者是 Azure 对典型负载的参考值，后者是物理上限。对于网络密集型应用，应选择支持加速网络的大小，并确认其网络带宽是否满足峰值需求。
二、磁盘类型与缓存策略：把 IO 路径拆开看
Azure 托管磁盘分为 Ultra Disk、Premium SSD v2、Premium SSD、Standard SSD 和 Standard HDD。性能依次递减，成本也依次递减。选择磁盘时，关键指标是 IOPS、吞吐量和延迟，而不是容量。容量只决定“能存多少”，性能等级才决定“读写多快”。
缓存策略是磁盘性能优化中最容易被忽视的一环。Azure 为每个数据磁盘提供三种主机缓存模式：
- None：不使用主机缓存，读写直接落到磁盘。适合写密集且对数据一致性要求高的场景，如数据库日志盘。
- ReadOnly：读操作走主机缓存，写操作直接落盘。适合读多写少的场景，如 Web 静态资源盘。
- ReadWrite：读写都走主机缓存，由 Azure 负责回写。适合临时数据或可容忍丢失的缓存盘，但不适合数据库数据盘和日志盘。
一个常见的错误是给数据库数据盘和日志盘都设置 ReadWrite 缓存。日志盘要求顺序写入且持久化，ReadWrite 缓存会引入回写延迟和潜在数据丢失风险，正确做法是日志盘使用 None，数据盘使用 ReadOnly 或 None，具体取决于读写比例。
下面这张图展示了从 VM 到磁盘的 IO 路径，以及缓存策略在路径中的位置。它可以帮助你判断：一次读或写究竟经过哪些环节，缓存是否命中，瓶颈可能出现在哪里。
三、网络加速：降低延迟，而不是提高带宽
加速网络（Accelerated Networking）通过 SR-IOV 技术将网卡虚拟化功能卸载到硬件，使 VM 的数据包绕过主机虚拟交换机，直接进入物理网卡。它的核心收益是降低延迟、减少抖动、提升包转发率，而不是单纯提高带宽上限。
对于以下场景，加速网络通常能带来明显改善：
- 高并发短连接服务，如 API 网关、负载均衡后端。
- 分布式数据库节点之间的同步复制。
- 实时通信、金融交易等对延迟敏感的应用。
启用加速网络的前提是 VM 大小支持该功能，且操作系统内有对应驱动。Windows 和主流 Linux 发行版通常已内置驱动，但部分旧版镜像需要手动安装。启用后可通过 ethtool -S eth0 或性能计数器观察丢包与队列情况，确认是否真正生效。
四、CPU 积分机制：突发型 VM 的“信用卡”
B 系列 VM 是 Azure 的突发型实例，其 CPU 性能采用积分机制。每个 B 系列大小有一个基准 CPU 性能百分比，当实际使用低于基准时，差额会累积为积分；当实际使用高于基准时，消耗积分来维持高于基准的性能。
以 Standard_B2s 为例，它有 2 个 vCPU，基准性能为 40%。这意味着在持续负载下，它只能稳定使用相当于 0.8 个 vCPU 的计算能力。当积分余额充足时，它可以突发到 100% 甚至更高；当积分耗尽后，性能会被限制回基准水平。
判断 B 系列是否适合当前负载，关键看两个指标：剩余积分和积分消耗速率。如果剩余积分长期接近零，说明负载已经超出基准能力，应改用 D 系列或 F 系列等固定性能实例。如果积分长期满额、CPU 使用率远低于基准，则说明当前规格过大，可以降配以节省成本。
五、把四条路径放在一起判断
实际优化时，建议按以下顺序排查：
- 观察 CPU 使用率与积分余额，判断是否受计算能力限制。
- 观察磁盘 IOPS 与吞吐是否接近所选磁盘类型的上限，判断是否受存储限制。
- 观察网络延迟与丢包，判断是否受网络路径限制。
- 确认缓存模式是否与工作负载的读写特征匹配。
例如，一个 Web 应用响应变慢，CPU 使用率 30%、磁盘 IOPS 打满、网络延迟正常。此时瓶颈在存储路径，应优先升级磁盘类型或调整缓存模式，而不是增加 vCPU。反之，若 CPU 积分耗尽、磁盘和网络均空闲，则应更换为固定性能系列或增加实例数量。
性能优化的本质是找到当前最紧的那条约束，然后只针对它投入资源。盲目升级规格或更换磁盘类型，往往只是把成本提高，而瓶颈仍然留在原来的位置。