Joseph Sibony
如果想要了解按需、保留和竞价实例间的区别，可能是因为发生了下列两件事中的一件。
要么是正在启动一个新项目，并试图找出确保团队有足够云容量以完成工作的方法；
要么是刚被令人瞠目结舌的云账单弄得措手不及，正在疯狂寻找控制成本的方法。
无论是什么导致了对云实例的探究，此探究方向都没有错。
幸运的是，实例的类型，以及竞价、按需、预留实例间的利弊，都很容易理解。
关键是找到一种实例类型，为你和你的项目带来成本、稳定性与灵活性间的完美平衡。
按需实例
按需实例是什么？
按需实例本质上是在需要时才购入的实例。可以看作是“随用随付型”实例，按小时或按秒收费。云计算容量可按需购买、随时购买，无长期承诺。不再需要时，撤回工作负载并取消实例即可，可随着计算需求的变更，增加或减少云容量。
按需实例的优势
- 扩展不费吹灰之力——这样一个稳定、随用随付的模式可使客户在云中运行 CI 和 CD 等进程时，获得关键好处：可扩展性。用户可在任何时候轻松增加或减少所使用的实例，而无需受限于某项支出或实例数量。
- 灵活——无法预测项目需要多少云容量时，按需实例将是完美选择。用户可反复评估需求，并增加和减少实例，以适应需求，而非受限于购入从不会使用的容量。
- 稳定——需要的按需实例永远属于用户，且云供应商不会撤销用户对服务器的访问权限。
按需实例的劣势
- 成本——按需实例是最为昂贵的云实例类型——需要在灵活与自由之间有所权衡，可根据需要扩大或缩小容量。
- 定价可能令人困惑——由于不同的实例类型和服务器地区有着不同的费率，弄清所需实例的费用可能是主要问题。好消息是，如果计算错误、成本开始增加，可以轻易地调整所用实例，使成本得到控制。
- 容量不足错误可能成为痛点（但较为罕见）——如果请求后无法获得所需容量，将会出现容量不足错误 (ICE)。如果想要获得所需实例类型，需要不断尝试手动请求实例，直到成功获取。然而，ICE 极为罕见；当客户试图通过切换到按需实例保护容量时，云停机期间才需关注这类错误。
何时该使用按需实例？
对稳定性和灵活性有需求时，可调用按需实例。运行工作负荷不均衡的进程时，无法在不中断应用程序的情况下中断进程，这通常意味着用户不会使用按需实例。
尽量坚持在短期项目中使用按需实例，因为难以预测任何特定时间所需的容量。如果项目运行时间较长，或者可以在某种程度上准确预测计算需求，那么使用预留实例将更具成本效益。
预留实例
预留实例是什么？
预留实例配置与按需实例配置几近相同。唯一的区别是，不是在需要时申请实例，而是将实例“预留”一或三年。
因为与按需实例相比，预留实例具有极大折扣，因此这种承诺是有回报的。
预留实例有两种类型：
- 如果使用标准预留实例，则仅可使用同一操作系统上，同一实例族中的实例。
- 如果使用可转换预留实例，则可使用不同操作系统上，不同实例族中的实例。
可转换预留实例显然更为灵活，但相较标准预留实例而言稍显昂贵。
预留实例的优势
- 折扣大——如果想要以风险相对较低的方式优化云支出，预留实例是不错的选择。预留实例在按需实例价格的基础上折扣了 40% 到 60%（视实例类型和云供应商而定）。
- 云账单无意外——使用预留实例不存在令人厌恶的意外。一年或三年承诺期满之前，预留实例的价格不会变更，所以永远没有价格随着需求增加而飙升的后顾之忧。
预留实例的劣势
- 较不灵活、承诺更多——只要合同未到期，就需要为所预留的实例付费——即使不再使用全部实例。如果计算要求在期限结束前发生变更，可能无法支付不需要的容量。
- 固定价格可能导致无法享受优惠——显然，固定价格可使用户免受价格飙升的影响，但也意味着最终可能需要支付更多的钱。可转换预留实例可以帮助用户避免此类情况。如果用户希望减少支出，预留实例允许用户切换到其他更便宜的实例系列。一些计划，如 AWS 储蓄计划，要求用户承诺特定支出，而非特定服务——取决于用户凑满支出的实例数量和类型。
预留实例分配于特定可用性区域，所以如果用户需要在全球范围内控制应用程序性能，这可能是一个缺点。
何时该使用预留实例
预留实例最适合具有相当均匀、可预测计算需求的项目。
如果用户打算承诺使用预留实例（并为其付费）一到三年，其应该比较确定将在整个预订期内的大部分所用容量。如此一来，用户便能放心。因为其已经持有全部所需容量，而且不会把钱浪费在最终只使用一次或两次的实例上。
竞价实例
竞价实例是什么？
云计算供应商需要保留一些可用空间容量，以防客户需求大增——但在大部分时间里，这些备用容量只是闲置着。
购买竞价实例，实际是在一定时期内从云供应商那里借用多余容量。“借用”在这里是一个关键词。如果需求增加，而云供应商需要额外容量，他们将会回收容量——通常在清除工作负荷前不到一分钟才会通知。
但这并不意味着应该完全避免使用竞价实例——只是意味着应该战略性地使用它们。
竞价实例的优势
- 折扣巨大——当用户权衡按需实例与竞价实例的价格时，结果不言而喻。因为竞价实例无需云供应商的任何承诺，所以竞价实例的成本比按需实例低 90%。这就是竞价实例经常受赞为克服云采用主要障碍之一工具的原因，特别是对于那些面临降低云成本压力的游戏开发人员而言。
- 灵活——一旦知道所需实例的类型，便可申请竞价实例，并迅速启动和运行。此外，当用户不再需要时，便可直接关闭。无论何时，只需使用真正需要的云容量即可。
竞价实例的劣势
- 竞价实例可能不可靠——有待权衡：无承诺意味着用户能以低廉的价格购入竞价实例，但这也意味着用户不能真正依靠单个竞价实例开发任何关键应用。如果云供应商需要额外容量，他们只会在收回竞价实例几分钟前进行通知。这意味着在竞价实例上运行任何不能在短时间内暂停或转移关键业务的应用程序，通常不是明智之举。
- 定价难以确定——竞价实例每小时的价格根据需求而变化，也就是说，如果经常使用竞价实例，有时很难准确预测实际费用。其结果是，即使存在折扣价格加持，成本也会意外飙升。
何时该使用竞价实例
一般来说，建议用户将竞价实例用于运行短期任务的无状态、容器化应用程序。随着云使用方式的发展，以及团队对更灵活、独立的云构建的寻求，竞价实例的使用前景将会极为明朗。竞价实例是 CI 构建等项目的完美选择，仅需低廉的成本即可获得不错的灵活性（点击此处，浏览更多关于如何在 AWS 上使用 GitHub Runner 的内容）。
总的来说，应该避免在竞价实例上运行关键业务的应用程序——如此一来，即使应用程序发生故障，也不会对客户造成干扰。
然而，也有一些方法可以解决这个问题。如果想在更广泛的项目中使用竞价实例，而不为应用带来风险，可以尝试使用 Spot Fleet 的云优化服务——将竞价实例组合的集合。如果其中一个竞价实例遭到撤销，可以切换到另一个。
应当选择哪种实例？
选择实例类型并不是要找到一种类型的实例后不再变更；大多数团队会意识到自己正在使用全部三种类型的组合，视情况而定。
云实例的类型一开始看起来似乎很混乱，但一旦深入挖掘，它们就会变得很简单。就像开发人员在优化支出和理顺进程时所面临的大多数问题一样，这一切都与平衡有关——在成本、灵活性和可靠性之间找到“最佳击球点”，并选择适合自己的组合。
