Joseph Sibony
云账单有点像小狗。
死死盯着的时候表现相当乖巧。但是，只要稍微移开视线哪怕一秒钟，它们就会以迅雷不及掩耳之势鲸吞预算，速度堪比小拉布拉多犬咬破你最爱的那双运动鞋。
意料之外的云费用是软件开发的众多隐性成本之一，特别是随着云使用方式的不断发展，这一现象愈发明显。而云账单带来的冲击——面对云供应商意料之外的巨额费用时，那种令人毛骨悚然的时刻——一直是令开发团队头痛不已的问题。
更令人担忧的是，据 Anodot 调查，64% 的受访者表示，他们需要几天、几周、甚至几个月的时间才能发现成本激增。
最重要的是，大多数团队需要找到更佳方法，来保持云中开发进程的运行，同时控制云账单成本，以免团队为并不需要的容量付费。
如果使用正确的话，云竞价实例将是改进云优化规划，并可确保用户使用仅在特定时刻需要的云容量的绝佳方式。
来看看这些好处——然后我们将展示帮助客户免受云竞价实例最大缺陷影响的技巧。
云竞价实例是什么？
竞价实例本质上是云供应商目前尚未使用的容量包。
所有云供应商都会保留一些备用容量，确保足以应对客户任一容量激增需求。但大多数时候，这些备用容量都是闲置的——这就是 AWS（亚马逊网络服务）、Microsoft Azure（微软智能云）和 Google Cloud（谷歌云）这类云供应商需要用户在短期内购买备用容量的原因。
还有一个关键问题：用户能以比按需实例低 90% 的价格购买这类“竞价实例”。
听起来像做梦一样，对吧？好吧，这里有点小问题。
这些竞价实例以极大折扣出售的原因是：用户无法永久持有。如果云需求激增，云供应商则有必要收回竞价实例——而且只会提前几分钟通知用户清除工作负载。
如果无法快速将工作负载切换到另一实例，可能面临数据不一致、数据丢失和活跃用户会话中断的情况。
对于任何支持面向客户服务的应用程序，这都是灾难性后果。Facebook 敢于公开承诺零停机时间事出有因。如今，客户早就习惯了应用程序、游戏和实时服务的不间断供应。任何经常掉线的服务很快就会遭到他们的摒弃——此外，如果提供的是付费服务，应用程序离线期间，很可能错失销售良机。
何时该使用竞价实例
由于云竞价实例的定价折扣极高，使用竞价实例可以有效改善云支出情况。但没必要全然依赖竞价实例。
一般来说，仅对运行短期任务的无状态应用程序使用竞价实例——如果云供应商收回容量，这些实例可能会中断，这样才不会使全部应用程序无法使用。
诸如：
- 网络服务
- 容器化应用程序与微服务
- 应用程序测试
- CI 和 CD 操作
- 数据分析
简而言之，就是任何可以轻松重新部署（通过 GitHub Actions Runner 之类的工具），而不会导致服务中断或团队工作无法展开的事物。
Spot fleet：不破坏服务的情况下降低成本的聪明方法
由于云竞价实例较之某些替代性云成本管理方法，变动更多也更不可靠，因此使用云竞价实例仍有相当大的压力。
就像是把压力和担忧从一个地方转移到另一个地方；虽然没必要再像鹰一样盯着云账单，但却要时刻关注云实例，准备好随时清除工作负载。
这就是最佳云优化服务使用变通方法节省云成本，而用户无需面临停机风险的原因。Spot fleet 做到了这一点。
Spot fleet 是同时启动竞价实例（有时是按需实例）的集合。以下是它的工作原理：
- 用户指定所需容量，就像申请竞价实例一样。
- Spot fleet 并非启动提供所需全部容量的竞价实例，而是启动诸多较小实例——按需提供容量。
- 如果最坏的情况发生了，云供应商需要收回一些竞价实例，spot fleet 将会自动启动新实例，以取代云开发商收回的实例。
也就是说，可将风险分摊到很多较小实例中，而不是孤注一掷在一个竞价实例上。用户不会面临毫无容量的风险。
因此，用户使用竞价实例时，无需冒着停机风险，也不会使人压力倍增。
而且，最重要的是，可以把云账单情况牢牢掌握在手中。
