近年来，公有云、混合云等技术在全球迅速发展，云的普及度越来越高，Docker、Kubernetes、DevOps、Service Mesh等云原生技术蓬勃发展。但在“上云”之后，企业却往往发现“用云”却并不是那么容易。
麦肯锡的一份研究报告表示，全球服务器的平均每日利用率通常最高仅为6％。Garter统计，全球数据中⼼利用率不足12%。以上数据都表明，数据中心的服务器成本及资源消耗方面会给企业造成巨大的“浪费”。
根据中国信息通信研究院调查数据显示，云原生技术给企业带来的价值中，提升资源利用率以节约成本连续两年排名第一，2021 年已有九成用户认可该项价值。
选项 |
2020年 |
2021年 |
提升资源利用率 |
76% |
90.59% |
提升弹性伸缩效率 |
63% |
76.98% |
提升交付效率 |
38% |
66.83% |
简化运维系统 |
30% |
67.57% |
随着企业用云程度加深，越来越多的应用迁移到云原生架构上，然而2021 年 CNCF《FinOps Kubernetes Report》调研报告显示，迁移至 Kubernetes 平台后，68% 的受访者表示所在企业计算资源成本有所增加，36% 的受访者表示成本飙升超过 20%，这都说明即使是资源利用率更高的云原生架构也需要合理的资源成本管理。
图1 CNCF统计企业迁移至kubernetes平台成本变化调查
针对相同统计口径，腾讯云对1000多云客户进行了资源利用情况分析，抽样超过一万计算节点发现，42%的节点资源利用率低于10%，72%的节点资源利用率低于20%。
图2 腾讯云资源利用率调查
为了帮助企业更好的迁移到云原生架构，我们基于之前多年成本优化的经验系统的整理了云原生成本优化的各种手段，可以归结为三个层面：
第一层：通过使用混合云或多云服务自动化工具无缝使用性价比最高的服务器资源（例如，异地部署、Intel换成AMD、私有云与公有云平衡等），达到跨云算力的最优调度。
第二层：通过K8s容器切割，对高配服务器进行切割后的再分配，让CPU、内存最小单位不受限制，这样有不同类型资源需求的业务可以实现混合部署，以最大程度提升节点的资源利用率。
第三层：对业务的算力使用情况进行建模量化并建立水位线、冗余度等配套指标体系，再通过削峰填谷、在离线整合、自动化扩缩容等方式不断优化资源配置，从而帮企业最大程度的降本增效。
然而以上各种手段实现成本有高有低，诸如异地部署、在离线整合对大部分企业来说技术挑战相当大，不同的企业也需要按照自己的实际情况来选择，为此我们整理了企业云原生成本优化的一般步骤，以供大家参考。
要想降低云原生成本，首先要做到成本可观测。具体来讲，就是要知道成本具体花在哪里，通常企业内部会划分为多个部门，每个部门对资源的需求以及资源的掌控力度都不尽相同，要想让各个部门对成本的认识以及能力保持一致，就必须有清晰的成本认识，可以从以下两个方面来执行：
成本的管理实际上是资源的使用管理，如何快速并且准确的识别出资源的分配、消耗，以及浪费是成本优化的前提条件。因此成本管理首先要做到的是资源消耗和资源利用率的可视化。
通常的做法是对资源的各种指标，如CPU使用率、内存使用率、磁盘使用率、进出带宽使用率等数据进行采集并展示。采集的方案可以通过在资源上部署自己研发的agent，或者对接云厂商已有的监控数据。
这里需要注意的是要对资源打好标签，一般企业内部都有成熟的CMDB系统，可以将资源按照类似产品线-业务线-集群等层次组织起来，也可以通过云厂商提供的资源标签功能进行标注组织，这样可以从多维度多层次的洞察资源的消耗与利用率情况。
公有云厂商虽然默认提供每日账单机制，但主要是从产品维度来区分的，企业内部则应该按照产品线-业务线-集群多个层次来观察每日的消耗，以便找出资源消耗异常的地方，如使用的弹性资源实例过多或者弹性时间过长，这时候就可以review是否要将弹性的实例转化为成本更便宜的常备实例。
除了要建立每日账单机制，最好还要有预算机制，从集群-业务线-产品线多个层次确立每日资源的正常消耗，结合每日账单就可以判断出哪些集群、哪些业务线或者哪些产品线的资源使用超标，这样可以及时发现找到超标的原因从而快速加以改进。
完成第一步成本可观测之后，企业就能清楚的知道具体某个业务线或者某个集群的资源利用率低，紧接着就可以执行下面的步骤来具体节省成本。
企业上云的第一步往往是把业务从原有的物理机或者虚拟机迁移到公有云，但往往因为对云的产品本身不是很了解以及对云的成本本身认识不足导致实际并未节省成本，甚至因为引用了公有云导致业务复杂度提升，相应的成本反而提高了。仔细剖析，主要有两方面的原因导致：
考虑到业务的稳定性以及高可用性，往往系统预留的资源是按照业务峰值再叠加一定的buffer来制定的，这就必然导致除了高峰时段资源利用率高，非高峰时段资源利用率低，甚至在业务低峰时段资源利用率极低。
对业务本身的资源需求缺乏精确的认识，有许多业务对资源的需求不规范，仅凭经验或者出于业务性能的考虑，配置越高越好，然而业务实际运行中发现出现严重的资源浪费情况。
如果能够充分利用公有云的弹性以及退改灵活性，则可以通过定时扩缩容和机型降配两种手段，就可以在不对业务进行任何变更的情况下，直接有效的降低公有云的使用成本。
有很多互联网业务的流量具备周期性，尤其是一些社交应用如微博、抖音等峰值流量出现在中午1点和晚上10点左右，可能达到日常流量的1.5倍甚至更多，若是用常备服务器支撑日常峰值流量，在非峰值时段服务器的利用率显然是不足的。除此之外，通常在凌晨之后大部分公司的业务流量极低，这个时候只需要少数服务器即可支撑线上流量。对于这一类业务，实际上若是能根据实际业务的流量定时扩缩容，比如中午12点扩容，下午2点缩容，晚上8点扩容，凌晨12点缩容，显然可以大幅降低服务器成本。
还有一些典型场景如电商的大促，因为时间点比较明确，流量可预期，可在大促到来前定时扩容一批机器，待活动结束后再释放。疫情的影响，导致一部分网课以及在线会议流量暴涨，但因为时间可预期，也可以采用定时扩容的方式来应对。相比购买包年包月的机器，成本可以大幅降低。
因为公有云上提供了各种配置的机型，业务可以根据自己对CPU、内存、磁盘、网卡以及IO的实际需求来购买适合自己业务需求的机型，而且公有云提供了包周、包月以及包年等多种方式的订购方式，大部分业务对自己的实际资源需求是不准确的，可以有针对性的进行压测，确定实际需要的资源配置。针对包年包月包周购买的服务器，可以在到期时根据实际的配置需求重新订购。如果是按量付费的话，则可以随时更改扩容配置。
除此之外，大多数公有云还提供了两种不被太多人关注的性价比更高的产品，一种是AMD实例，一种是竞价实例。
在 x86 服务器市场上，Intel 的 CPU 得益于其长久以来出色的稳定性和性能，占据了绝大多数的市场份额。但随着 AMD Zen 架构的 EPYC 处理器的推出，在同等性能下每核心的价格相比 Intel 的 CPU 更低。以公有云厂商为例，同等规格的实例若采用 AMD 处理器价格能降低 30%以上。
AMD实例可以兼容不同版本的操作系统，但因为AMD Zen架构发布于2017年，处理器的部分新特性在旧版操作系统上会出现部分功能支持上的缺陷。所以需要企业可以根据应用的实际情况，自行决定需要使用的操作系统版本。
竞价实例也叫抢占式实例是一种按需实例，旨在降低部分场景下使用ECS的成本，合理的使用ECS竞价实例，最高可以降低50% – 90% 的运营成本(相比按量付费的实例)，可以用相同的预算，将计算容量提升2–10倍。
创建竞价实例时，必须为指定的实例规格设置一个价格上限，当指定的实例规格的当前市场价格低于出价时，就能成功创建竞价实例，并按当前市场价格计费。默认能稳定持有实例1小时。1小时之后每5分钟会检查一下，当市场价格高于出价或者资源供需关系变化时，实例会被自动释放。
为了保证尽可能高概率的弹出竞价实例，可以设置多个地域多个可用区多个规格进行竞价，可以大大提升了竞价实例的创建成功率。除此之外，因为竞价实例可能随时会被自动释放，就需要业务具备弹性伸缩能力，在竞价实例被回收前，能够自动的重新选择其它竞价实例来替代，如果没有竞价实例了，再可以扩容按量付费的实例。
竞价实例适用于无状态的应用场景，例如可弹性伸缩的Web站点服务、图像渲染、大数据分析和大规模并行计算等。应用程序的分布度、可扩展性和容错能力越高，越适合使用竞价实例节省成本和提升吞吐量。有状态应用不宜使用竞价实例，例如数据库。因为竞价失败等原因导致实例被释放时，应用状态难以保存。
通常都认为使用公有云比自己采购服务器更加节约成本，然后实际并不一定。企业在实际使用过程中发现大批量采用公有云的包年包月机器后，按年摊销的话相比自建机房采购同等配置的单台服务器成本要高。所以已确定的长期需要使用的包年包月的机器可以转化为自己采购的机器，短期内无法确定是否是长期需求的可继续使用公有云。企业在每经过一段时间，就需要对自己的公有云上的包年包月机器进行review，确定哪些适合采用私有云，哪些继续使用公有云。以字节和快手最为典型，快速发展的初期大量使用了公有云的包年包月资源，在企业稳定发展后，开始逐步将这些资源转化为私有机房的资源。
以上手段业务无须改造只需要做一些运维层面的变更即可直接实现成本节省，适合大多数上云的企业。这个阶段理论上负责运维的团队即可执行，不需要业务深度参与，执行难度比较小。但当前公有云的产品众多，公有云的控制台操作复杂不适合直接拿来使用，为此可借助一些二次开发的平台，如开源算力引擎BridgX（https://github.com/galaxy-future/bridgx/），基于多个云厂商的SDK封装并提供了简单易用的API以及WEB UI可快速的使用公有云的各种产品。
若企业若想进一步优化成本，则需要执行成本节省的第三步：充分利用弹性与共享，来进一步提高资源利用率，以降低成本。
大部分企业内部不同的业务对机器的资源需求不同，有的业务是计算密集型，对CPU的要求较高，有的业务是内存密集型，对内存的大小要求较高，有的业务是网络密接型，对网卡的要求较高，有的业务是离线计算型，对磁盘空间要求较高，然而实际购买的机器并不一定能够与不同业务的需求完全吻合，这就造成大部分机器的资源无法充分利用。
所以需要一种更灵活的资源分配方式，如果业务能够根据自己的需求任意定制是最好的，这一点自己采购机器显然是无法满足的，公有云虽然提供了多种多样配置的机型选择，但对CPU、内存等的规格还存在固定限制，要求CPU和内存比为1:2以上。
云原生时代以Kubernetes技术为代表的容器云平台，可以把企业现有的服务器资源统一管理起来，通过Kubernetes的资源隔离技术，按照业务实际的需求，给业务分配实际需要的资源。但因为Kubernetes技术本身的复杂性，企业要想自己搭建一套可稳定运行投入到线上生产环境的云平台，需要投入相当大的研发人力，为此许多云厂商也提供了可托管的kubernetes集群，虽然在一定程度上降低了使用kubernetes的门槛，但仍然需要充分掌握Kubernetes技术本身，如交付的Pod的IP是动态变化的，并且需要有与之配套的网络、监控、日志等解决方案，企业原有面向固定IP的运维基础设施将不再适用，所以说迁移成本以及使用门槛还是相当高的。
针对大部分企业的现状，我们建议企业首先利用Kubernetes切割现有资源并以固定IP形式交付资源，这样企业既能充分利用Kubernetes的资源隔离能力提高资源的利用率，又可以继续复用原有的运维解决方案，以便以低成本的方式迁移到Kubernetes容器云平台，之后再根据自己的实际情况来决定后续的技术建设。
前面在介绍定时扩缩容时提到有很多互联网业务的流量具有明显的周期性规律，例如中午和晚上流量明显较高，而凌晨以后流量极低，可以使用定时扩缩容固定数量的机器来解决。然后现实中业务的流量增长模型并不是一成不变的，有可能某一天流量增长超出以往，或者某一时间有突发的流量增长，这时候仅仅靠定时扩缩容显然难以满足，这就需要靠自动扩缩容来应对。
当前基于Kubernetes的容器云平台提供了一些根据CPU、内存使用率等简单的指标来进行弹性伸缩的手段，但对于大部分企业的业务来说，实际线上服务模型要复杂得多，很难依靠某个单一指标来衡量是否要扩缩容。
一个更合理的方案是对流量模型进行抽象，既要考虑QPS的变化，又要考虑业务实际性能。可以定义系统冗余度的指标，它代表了系统实际能承受的最大消耗与实际消耗之间的比，其中系统实际能承受的最大消耗可以通过压测来衡量，再结合各业务的实际情况定义一个最小冗余度和最大冗余度，若系统冗余度低于最小冗余度则自动扩容，高于最大冗余度则自动缩容。
除了上面提到的一个业务流量通常在一天之中会有波峰波谷，如果企业内部有多个业务并且不同业务的流量高峰低谷的时间不尽相同，则可以根据各业务的流量特点做错峰调度。
正如前面提到的通常各业务都是按照流量高峰做常备冗余部署资源，所以可以根据各业务的实际流量情况只保留最小程度的冗余，而将过度冗余的资源统一纳管到一个虚拟资源池当中，这样的话就可以保证波峰波谷不同的业务能够相互利用各自冗余的资源，提高系统整体的资源利用率。
错峰调度的挑战在于能否准确并及时的衡量各业务的冗余度，以便在业务需要资源的时候能够及时的从虚拟资源池回收，并且如果虚拟资源池中资源不足时，还要及时的从外部申请资源。
更进一步可以通过收集分析各业务的历史指标数据，对未来一段时间的指标趋势进行预测，从而确定各个业务的流量高峰及低谷对应的周期，并指导后续的资源调度。
随着AI技术的逐步成熟，越来越多的企业开始构建自己的AI应用，并将AI应用迁移到云。其中AI应用对GPU资源的需求最为强烈，当前基于 Kubernetes的容器云平台在调度GPU资源时，通常是将一张完整的GPU卡分配给一个容器。随着显卡技术的不断发展，半导体制造工艺的进步，单张GPU卡的算力越来越强，同时价格也越来越高。但在很多的业务场景下，一个AI应用并不需要一整张的GPU卡。显然若能使多个容器共享一张GPU卡，并保证业务的安全隔离，则可以显著提升GPU利用率，节约成本。
一些第三方如公有云提供了基于Kubernetes实现的GPU共享解决方案，如果企业在GPU资源上花费成本较高，并且资源利用率不高，可以考虑使用GPU共享的解决方案，以便节省成本。
通过以上手段，业务可按照自己的实际需求利用弹性与共享来实现最大化的资源利用，不过需要有企业级的统一云平台提供K8s切割、自动扩缩容、错峰调度以及GPU共享等能力。通常有两种方案，一种是自建基于K8s的云平台，不过考虑到技术门槛和生产环境的复杂性，一般企业需要投入至少十名以上的研发人员才能建设一个完整的K8s云平台，一种是使用第三方如公有云托管的K8s集群，虽然省去了自行维护K8s集群的精力，但仍需掌握K8s的各种功能特性和开发能力，门槛依然很高。为了我们提供了一个更加容易落地的方案，就是在企业原有的运维设施的基础上，根据需要集成开源的解决方案如开源算力引擎BridgX（https://github.com/galaxy-future/bridgx/），支持web服务自动扩缩容、K8s切割并以固定IP形式输出等功能，只需要很小的开发成本即可拥有以上功能。
当企业达到一定规模后，要想进一步优化成本，就得从更高维度去考虑了。这个时候就可以考虑异地部署、混合编排、在离线整合等复杂度更高的手段了。
企业的IT 成本除了服务器自身的成本外，还包括部署服务器的机架成本、机房建设的成本、电力成本以及网络带宽和专线的成本等。西部地区由于电力资源丰富，土地成本以及各种政策扶持的因素，建设数据中心的成本要远小于东部以及中部地区。综合考虑多方面成本，选择在综合成本更低的地区建设或租用机房，或者选择公有云单价更低的可用区，可以明显地降低成本。以公有云为例，西部地区按量付费实例的价格要比东部地区优惠10%，某些地区如张家口甚至能优惠到30%。
对于企业内部来说，异地部署最大的挑战在于数据同步与时延，不同IDC之间根据距离通常有10-30ms的时延。对于时延比较敏感的在线业务来说，要做到异地部署挑战比较大。但对于时延不敏感的离线业务，可以把存储和计算迁移到成本较低的西部IDC。但离线业务通常数据量比较大，在百T以上甚至达到PB级规模，若通过公网传输则要以月为单位，而专线的解决方案价格又比较昂贵，通常在百万以上。一个成本较低的解决方案可以使用基于开源算力引擎BridgX的数据物流服务DTExpress，支持通过公网在不同的公有云的不同IDC之间传输海量数据，1TB数据的成本只有1000元左右。
上面提到企业不同业务所采用的机型必定存在某一方面的利用率不足，比如计算密集型的web业务通常磁盘使用率不高，内存密集型的NoSQL业务和IO密集型的数据库业务通常CPU利用率也不高，通过使用K8s切割现有的资源虽然可以一定程度的提供资源使用率，但是因为大部分企业内部的机器配置不高，所以即使使用了K8s管理，仍然会存在很多利用不上的资源碎片。一个更好的思路就是把各个业务使用的各种小配置的机器进行整合统一置换为高配机器，再把这些业务混合部署统一编排，这样的话就能做到资源完全互补。
如基于AMD处理器的神龙服务器，单台最高具备256核2T内存2T磁盘，并具备高达60Gps的网络带宽，可以借助Kubernetes的资源隔离技术，对 CPU、内存、磁盘、网络进行精细化的调度，如下图所示一台神龙服务器上可同时切割十几个容器跑web业务，十几个容器跑NoSQL，十几个容器跑MySQL，可满足不同业务的不同资源诉求。
不过多个业务部署到一台大规格机器比较大的风险是一台机器宕机可能影响十几个甚至几十个服务，这时候就需要通过服务/资源治理平台进行快速治理，再加上快速扩容、快速数据分发的能力，则可以达到分钟级的业务迁移。
大部分企业内部往往存在两种业务类型，一种是在线业务，通常流量高峰比较一致，如果流量高了，在线业务都需要很多机器，一种是离线业务，往往是凌晨开始计算，与在线业务的高峰时间错开。一个合理的设想是为什么不在线业务高峰期，把离线计算的机器拆借给在线业务使用，等到凌晨业务低峰期，再把在线业务的机器拆借给离线业务使用，等到早上业务高峰期前再拆分回来，然而在企业内部这两种业务的机器并不能充分利用，主要有以下原因：
1、部门墙
在企业内部机器的产品线一般是固定的，成本和利用率也是按照产品线计算的，所以通常情况下机器是不会在不同部门之间自由流转的。
2、机器配置差异大
一般情况下在线业务对CPU的要求比较高，对磁盘的需求低，以web计算为例，需要的机器配置一般是16核16G内存200G磁盘，而对于离线业务来说，对CPU的要求不高，但对内存和磁盘要求比较高，尤其是磁盘单机可达1T以上，所以两种类型的机器想复用也比较难。
为了解决以上问题，一些企业使用了在离线混部的解决方案，就是将在线业务和离线业务部署在同一个集群同时运行，在线业务流量高时资源主要调度给在线业务，业务低峰期主要运行离线计算，甚至是必要时停掉一些离线任务将资源全部让渡给在线业务，比如阿里双11期间就会停掉离线计算业务，将资源全部留给线上的在线业务。这种方案解决了以上问题，但是对技术的挑战比较大，需要对CPU、内存和网络进行专门的优化，以确保离线计算不会争抢在线计算的资源。
以上手段无论是异地部署、混合编排还是在离线整合都需要涉及不止一个业务，需要从企业整体层面来考虑，通常不是一个部门能解决的。这时候建议企业内部以基础平台或者云平台部门牵头，首先联合关系密切或者对新技术感兴趣的部门成立联合项目组，或者以公司名义成立专项来进行，先从小的业务入手迁移到容器云平台，待验证平台功能完善后，再考虑逐步把核心业务迁移到平台，最终达到优化企业整体资源利用率的目的。
上面详细论述了企业优化成本的实时步骤，建议不同企业根据自己现阶段情况有条件的加以选择。如果是企业刚刚迁移上云，可以重点从第二步入手，充分了解云产品的特性，并结合自己业务的特点，真正做到上云以节省成本。如果企业已经上云并且业务稳定运行，但资源利用率不高，并希望通过技术手段进一步提高资源利用率，除了执行第二步以外，还可以考虑第三步在原有的运维设施基础上结合开源的解决方案，选择适合自己的优化手段。最后如果企业的业务达到一定规模，比如具备上万台服务器时，就可以考虑采用异地部署、混合编排以及在离线整合等更高层次更复杂的方案。
以上论述的云原生成本优化的手段我们也将在首次对外举行的Meetup中详细的阐述，欢迎感兴趣的朋友报名参加。
