在上一篇文章《架构师视角看云成本管理》中，我们从宏观角度分享了一些成功企业的最佳实践和云成本优化的成熟度模型；这是云成本管理的第二部分，主要讲云上的计算成本，以及一些常见认知误区的拆解。

我觉得计算是一个众所周知的领域，尤其是虚拟机，但不得不说，理解的越深，我就越觉得，掌握云上的计算实例真的不容易。

很多时候，我们往往以为自己很熟悉，却很容易失去宝贵的好奇心，阻碍我们真正了解云上的计算。

杜绝浪费是基本原则。

AWS成本优化的一个基本原则是“避免浪费”。在成本优化和避免浪费的过程中，客户自然会走向云原生架构。虽然过程是痛苦的，但客户的技术“肌肉”会越来越强，面对各种挑战时会更加灵活，更有竞争力。

有人问平台如何规范市场，每个云服务的上线运营至少有一个小团队负责。价格是市场的调节器，也是云服务的试金石。在不浪费的前提下，每个云服务，包括云合作伙伴的解决方案，都是在充分竞争的情况下赢得客户，最终客户受益。

你遇到过以下计算浪费场景吗？

应用底层虚拟机集群采用固定数量。

即使晚上用户少，集群机也不会关机。

很多机器资源利用率极低，但是没人敢关。

默认情况下，每台机器装载100GB或更多的磁盘。

机器很少升级到新型号。

很少使用ARM和AMD平台来优化价格更高的英特尔芯片。

只使用虚拟机，很少使用其他计算服务。

“计算”并没有看起来那么简单。

客户通常会给出机器的CPU/内存配置以及需要的机器数量，照常询价。这种想法实际上停留在IDC范式中。默认情况下，这样做的客户有几个假设：

忽略应用在云端的架构优化，限制云服务提供商只提供计算资源。

对计算资源的需求是固定的(通常是日常业务的使用高峰)

资源是“占有欲”的，柜子的数量还是在我脑子里算。

默认情况下，所有厂商的CPU/内存计算能力都是一样的。

忽略云服务的技术升级和服务能力价值。

这个阶段，我们通常认为是迁移的初级阶段，从IDC复制到云端，忽略了两者巨大的技术差异。从成本管理的角度，我们强烈建议客户不要停留在这个阶段太久。迁移过程是一个非常好的偿还技术债务的机会，团队不转型。原套还是直接放在云上，很难达到理想的业务效果。

计算真的那么简单吗？

误区一：计算==虚拟机？

云服务发展到今天，从最初的物理机虚拟化和提供虚拟机服务，到今天丰富多样的计算能力和不同的计算市场，给了客户不同的选择。

丰富的虚拟机类型选择

在类别上，以AWS为例，提供了270多个根据场景优化的模型，涵盖了各种工作负载，如通用、内存优化、存储优化、高性能计算密集型、GPU和图形计算、机器学习推理等等。

对于CPU平台，提供Intel、AMD和ARM功能的各种处理器机器。

不仅提供虚拟机，还提供裸机。

单机组网已经进入100Gbps(太比特以太网)时代

为您的工作负载选择最佳虚拟机类型是成本管理的第一步。

推荐延伸阅读：《你真的了解 AWS 实例“经济学”吗？》使用Python和Pandas库分析AWS实例。

按使用收费，不收费。

云服务被说成是按使用付费，类似于水电等基础设施。不占用资源，完全没有成本。对于机器来说，关机就停止充电，一般都是先用后结算。

毕竟虚拟机对于客户来说还是底层资源，企业往往需要支撑商业价值的应用。从应用的角度来看，成本模型对企业意义重大。应用需要的计算资源可以分为虚拟机、容器、无服务器三类，其中无服务器成本模型在很多场合对企业有帮助。

比如AWS Lambda，主要成本是每个接口按百万次调用收费，不调用不收费，但是你的服务是随时可用的。

另一个例子是容器。许多客户习惯于管理底层虚拟机。为了优化成本，他们需要能够管理虚拟机的灵活扩展和收缩，并不断提高虚拟机的利用率。而AWS Fargate减少了客户使用容器管理底层虚拟机的麻烦，直接对容器持续时间占用的容器资源进行计费，用户无需考虑底层虚拟机。

甚至数据库可以根据访问次数自动帮助客户扩展和收缩底层资源，节约成本；比如亚马逊Aurora Servless，NoSQL数据库Amazon DynamoDB等等。

从业务特点出发，细分应用场景，先无服务器架构。

固定成本和弹性成本

我们前面提到，企业的云成本管理越成熟，其柔性成本优化就越好。

客户的购买方式有两个极端。

第一，全弹性成本，比如游戏行业客户，新游戏的发布，通常不清楚游戏能否持续活跃，所以往往更愿意一开始就按需使用，全弹性成本，随时止损。

第二，所有的固定成本，比如企业后台应用，很多都是需要一直提供服务的传统企业应用。在这种情况下，按照固定成本支出的思路，一年的使用可以得到最好的价格。

大多数企业需要在固定成本和弹性成本之间取得平衡，优化的重点是弹性成本。许多企业经常不恰当地应用太多的随需应变的例子，导致高成本。

为什么会有弹性成本？很多都是业务特点带来的。比如流媒体网站网飞，经常是周五开始用户流量上升，周一开始下降，晚上的用户流量大于白天。再比如，很多用户晚上会有很多任务要运行批处理，白天主要依靠分析师的交互查询等。再比如开发测试环境，本身就是短生命周期环境；

如上图所示，云厂商计算资源的成本基线是基于虚拟机的按需单价，不同地区的单价通常略有不同。

建议弹性计算资源的优化从现货实例市场入手或者通过节约计划将弹性资源优化成动态固定成本，往往会有意想不到的好结果。

误区二：所有的虚拟机都一样吗？性价比之差超乎你的想象。

不要只凭vCPU和内存量就凭直觉判断厂商提供的产品都是一样的能力。

从工作量出发，明确自己关注的机器性能指标，先测试，再根据性价比看成本，一般会豁然开朗。

我们期待客户“喜新厌旧”，不断优化现有计算实例的成本；

去年，网易游戏团队在《荒野行动》全球游戏用户的网络加速组件中，用AWS A1模型测试并替换了原有的C4/C5模型，直接获得了40%%u7684的性价比提升。

现在虚拟化技术的发展都是基于AWS。Nitro系统的虚拟化技术和虚拟化软件的资源消耗占主机总量的1%%。

还有就是虚拟机资源的独占使用和“超售”使用，我觉得一直是客户关心的问题。这可以通过长时间测试虚拟机的性能稳定性来判断。

误区三：资源拥有“安全感和成本优化困境”

因为云是公共基础设施，一开始非常不适应的是容量管理挑战，即如何保证企业在任何需要的时候都有足够的资源？

传统

答案是肯定的。唯一的挑战是成本，因为计算资源的容量是留给你的账户的，不管你用不用都会造成费用，因为这部分资源不能被其他客户重用，不管你用不用资源都被锁在你的账户里；通常情况下，当特殊情况导致整个市场的计算资源短缺时(比如大量客户争相使用资源)，他们会为了保证自身业务增长所需的容量而这样做；

大多数客户的虚拟机都是共享资源。如果您释放计算资源，它可能会立即被另一个客户占用。如果你是计算资源的消耗大户，可能会遇到某型飞机可用资源不足导致虚拟机启动失败的情况。

这种不确定性会让许多企业客户不舒服，但一个常见的误解是，客户一直试图在可用的区域尝试同类型的机器，这不是一个聪明的策略；因为资源池由两个因素决定：可用区域和实例类型；减少容量挑战的一个行之有效的策略是使用多可用区域和多实例计算资源；

如上图所示，AWS计算资源在购买方式上有两个市场：一个是市场A，通常拥有大量最新的计算实例资源。如果容量紧张，将从市场B的资源池中调度计算资源来补充；另一个是B市场，闲置推广市场，价格便宜，计算资源没有区别。

云提供商越大，客户遇到计算资源能力挑战的可能性越小；原因在于，整个计算资源市场是被众多大头客户的需求不断扩大的，而计算资源一旦扩大，云厂商就无法将计算资源缩回来，只有老一代的计算实例类型会因为用户的市场需求萎缩而逐渐停止扩大。

因此，在大规模使用云上的计算资源时，一定要有容量管理意识，主动与云服务商沟通容量需求；

对于云服务商来说，一个美好的愿望就是“资源是无限的，想要就能拥有”，而这句话的正确理解是云资源是可以无限扩展的，但不是第一天的超大规模容量，而是根据客户需求逐步动态扩展的。因此，任何计算资源的大规模非线性增长都需要人为的干预和介入。

观看转发是对我最大的鼓励！

更多关于云服务器，域名注册，虚拟主机的问题，请访问西部数码代理官网：www.chenqinet.cn。