云计算构建在大量软件组件上，由于集成通常非常昂贵、冒险，并且很耗时，规划者与架构师通常选择集成包。云堆栈中一个重要元素是 hypervisor，有时用于hypervisor支持的“堆栈选项”未达到***标准。要验证你自己的“包”选项，了解三种hypervisor关联维度，检查满足应用需求的云软件选项，以及验证串联的硬件功能时需要小心翼翼。
在云计算与虚拟化中，hypervisor将一台物理服务器划分为多个虚拟块，以便单独分配给应用。hypervisor有三种事物有着明显的关系：硬件平台、主机操作系统以及子操作系统。这三种连接的方式不尽相同，在自己的云应用中你需要核查连接规模，确保选择了合适的云软件。
了解三种hypervisor类型
询问hypervisor规模的***个问题是hypervisor在三种连接元素中创建的关系。有三种受支持的基本模式：硬虚拟化模式，即Type 1 hypervisor、操作系统集成模式Type 2以及容器模式，如Docker。
Type 1 虚拟化创建了一个框架，虚拟机从硬件隔离，没有主操作系统。如果云应用需要大量不同的子操作系统配置，并且出于安全、遵从或多租户原因，应用必须严格分离，那么这种隔离就非常有价值。你的云软件堆栈使用在子操作系统中无隔离的灵活性差的hypervisor，那就换个呗。
Type 2 虚拟化是hypervisor功能与主操作系统的结合。如果主机与子操作系统相同，这种亲密关系非常有用，这表示云堆栈支持所有(几乎所有)运行在相同操作系统上的应用。Type 2 hypervisor几乎是不提供应用隔离，应用会影响其他应用的性能，但资源效率与运营易于管理。多数用户也没有像公有云提供商那样关注租户隔离。仔细查看应用的性能，要小心不能访问硬件与你想要的加速功能。如果想用这些功能，那就换个hypervisor。
Type 3 ***一个类别是最不像hypervisor的hypervisor，即基于容器的云系统。容器是轻量级应用托管点，比Type 2虚拟机的隔离性还差。它们不在应用之间提供资源控制，安全性也有待提升。它们能提供的是非常简单的应用部署与资源有效利用。你在服务器上部署所部署的容器数量可能是虚拟机的5到10倍。然而，做一个通用的容器承载任何应用却很难，因此，如果要大型的不同硬件组成的资源池中托管很多不同的应用，使用容器的方式就比较困难。
验证hypervisor选择
下一步是验证为应用所选的hypervisor是否合适。通常，拥有的不同应用集越多，就需要多个子操作系统或不同的中间件版本，这样看起来你似乎需要的是Type 1 hypervisor，而不用去管云软件包含了什么。小心确定与供应商之间的关系，因为几乎所有的应用都适合托管在云中。你会将云托管作为常规IT战略。
许可与支持也是作决策需要考虑的一部分。可能在任何hypervisor上运行一个子操作系统，这些操作系统副本的许可与支持将给总体成本带来压力。有些Type 2厂商不愿意支持除了自己操作系统之外的子机，这就使得价格与支持变得更复杂。了解自己应用所需的子操作系统的许可是如何收费的，如果价格不合适就考虑另一种hypervisor方式。
hypervisor的硬件选择最复杂。随着虚拟化与云计算愈发流行，厂商纷纷通过各种硬件增强与软件工具提升虚拟机性能。这些工具通常针对网络，提供到子操作系统的设备连接。这些工具的性能差异区别很淡，所以需要确保选择一个拥有所有促进功能的hypervisor，满足应用的需求。
作出继续使用hypervisor的决定
通用规则总是充满危险，但有个起点决定是否保持或替换云平台的hypervisor。
- 如果你有使用不同操作系统的应用，就该坚持使用Type 1 hypervisor，并替换云堆栈产品。
- 如果你的云主要用于托管少量应用上的多个实例，而这些应用运行在相同操作系统与中间件下，利用率又不高，那么你应该使用容器技术而不是传统的hypervisor虚拟化。
- 如果你的应用主要基于单个操作系统与中间件，但偶有例外，就该使用Type 2 hypervisor替换Type 1。
记住，你无论何时移除云软件包，你就承担了更多集成与支持的责任。确保你更改hypervisor的益处证明你值得去冒险。
