第2章资源抽象与建模

第2章：资源抽象与建模

好，咱们接着聊。上一章我讲了分布式资源聚合的整体架构，这一章咱们深入到底层——资源抽象与建模。

说白了，资源抽象就是给物理资源“化妆”。CPU、内存、存储、网络这些硬件，原本是赤裸裸的金属。你直接操作它们？太累了。我们需要一层虚拟化抽象，把它们包装成标准化的“资源对象”。

我个人习惯，把资源抽象分成两个层面：

虚拟化抽象：把物理资源切成虚拟资源，比如虚拟CPU、虚拟内存、虚拟磁盘。
描述模型：用标准格式（JSON Schema、YANG）来描述这些资源长什么样、有什么属性。

嗯，咱们一个一个来看。

2.1 物理资源的虚拟化抽象

先说说CPU。CPU的虚拟化，最核心的就是“分时复用”。一个物理核，可以跑多个虚拟CPU（vCPU）。每个vCPU觉得自己独占了一个核，其实是被Hypervisor调度着轮流用。

我在项目中遇到过一个问题：某个客户说他的虚拟机CPU性能忽高忽低。查了半天，发现是Hypervisor的调度策略没配好，导致vCPU之间互相抢时间片。后来我建议他改用“绑核”模式，把vCPU固定到物理核上，问题就解决了。

你想想看，CPU虚拟化其实就三种模式：

全虚拟化：不需要改客户操作系统，但性能有损耗。
半虚拟化：需要改内核，但性能接近物理机。
硬件辅助虚拟化：Intel VT-x、AMD-V，硬件帮你做隔离，性能最好。

内存虚拟化呢？说白了就是“地址翻译”。物理内存的地址，和虚拟机看到的地址，不是一回事。中间有个影子页表或者EPT（扩展页表）在干活。

避坑指南：我曾经在项目中遇到过内存超分过度的情况。物理内存只有64GB，我分了80GB给虚拟机。结果一跑业务，频繁触发Swap，性能直接崩了。后来我学乖了，内存超分比例控制在1.5倍以内，留点余量。

存储虚拟化，这个大家比较熟悉。物理磁盘被抽象成虚拟磁盘（VMDK、QCOW2等）。但要注意，存储虚拟化不仅仅是“切分”，还有“聚合”。比如Ceph，把一堆物理磁盘聚合成一个统一的存储池。

网络虚拟化，嗯，这个最复杂。物理网卡被虚拟成多个虚拟网卡（vNIC），每个虚拟机都有自己的虚拟交换机（vSwitch）。我记得有一次调试Open vSwitch，发现流量走不对，查了两天才发现是流表规则写错了。

2.2 资源描述模型

资源抽象完了，怎么描述它？总不能靠嘴说吧。我们需要一个标准化的描述模型。

我个人最常用的是JSON Schema。为什么？因为它简单、直观、生态好。你看下面这个例子：

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "VirtualMachine",
  "type": "object",
  "properties": {
    "vcpu": {
      "type": "integer",
      "description": "虚拟CPU数量",
      "minimum": 1,
      "maximum": 64
    },
    "memory": {
      "type": "integer",
      "description": "内存大小（MB）",
      "minimum": 512,
      "maximum": 524288
    },
    "disk": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "size": { "type": "integer" },
          "type": { "enum": ["SSD", "HDD"] }
        }
      }
    },
    "network": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "mac": { "type": "string" },
          "bandwidth": { "type": "integer" }
        }
      }
    }
  },
  "required": ["vcpu", "memory"]
}

你看，这个Schema把虚拟机的CPU、内存、磁盘、网络都描述清楚了。而且可以加校验规则，比如CPU不能超过64核，内存不能超过512GB。

但JSON Schema有个缺点——它不太适合描述“配置与状态”的混合模型。这时候YANG模型就派上用场了。

YANG模型是网络设备配置的标准描述语言。它比JSON Schema更强大，支持配置、状态、RPC操作、通知等。我在做SDN控制器的时候，就大量使用YANG模型来描述网络资源。

举个例子：

module example-vm {
  namespace "urn:example:vm";
  prefix vm;

  container virtual-machine {
    leaf name {
      type string;
      mandatory true;
    }
    leaf vcpu {
      type uint8 {
        range "1..64";
      }
      default 2;
    }
    leaf memory {
      type uint32 {
        range "512..524288";
      }
      units "megabytes";
    }
    list disk {
      key "id";
      leaf id {
        type uint32;
      }
      leaf size {
        type uint64;
      }
      leaf type {
        type enumeration {
          enum SSD;
          enum HDD;
        }
      }
    }
  }
}

YANG模型的好处是，它天生支持“配置”和“状态”分离。比如你配置了虚拟机的CPU数量，但实际分配了多少，可以通过状态节点查出来。这在运维场景下特别有用。

2.3 两种模型的选型建议

我经常被问到：到底用JSON Schema还是YANG？

我的建议是这样的：

场景	推荐模型	原因
云平台API（OpenStack、K8s）	JSON Schema	生态好，前端后端都熟悉
网络设备配置（交换机、路由器）	YANG	NETCONF/RESTCONF标准支持
混合场景（既有计算又有网络）	两者结合	JSON Schema描述计算，YANG描述网络

嗯，这里要注意一点：不要试图用一个模型解决所有问题。我在一个项目中，团队非要统一用YANG描述所有资源，结果写出来的模型又臭又长，维护成本极高。后来我建议拆开，计算资源用JSON Schema，网络资源用YANG，清爽多了。

2.4 核心知识体系

为了让你更直观地理解这一章的知识结构，我画了一张图：

这张图把整个知识体系串起来了。从底层的物理资源，到中间的虚拟化抽象，再到上层的描述模型，最后落到应用场景。你想想看，每一层都有它的价值，缺一不可。

核心要点回顾：

虚拟化抽象是基础，把物理资源变成可灵活分配的逻辑资源
JSON Schema适合云平台API场景，简单易用
YANG模型适合网络设备场景，配置与状态分离
选型时不要一刀切，根据场景灵活选择

好了，这一章就到这里。资源抽象与建模，说白了就是给物理资源“穿衣服”，再用标准语言“描述衣服”。下一章咱们聊聊资源调度与编排，那才是真正让资源“动起来”的关键。

📚 课程目录