在本篇文章的末為還有福利，在等著大家哦~

前言

近年來(lái)，公有云、混合云等技術(shù)在全球迅速發(fā)展，云的普及度越來(lái)越高，Docker、Kubernetes、DevOps、Service Mesh等云原生技術(shù)蓬勃發(fā)展。但在“上云”之后，企業(yè)卻往往發(fā)現(xiàn)“用云”卻并不是那么容易。

麥肯錫的一份研究報(bào)告表示，全球服務(wù)器的平均每日利用率通常最高僅為6％。Garter統(tǒng)計(jì)，全球數(shù)據(jù)中?利用率不足12%。以上數(shù)據(jù)都表明，數(shù)據(jù)中心的服務(wù)器成本及資源消耗方面會(huì)給企業(yè)造成巨大的“浪費(fèi)”。

根據(jù)中國(guó)信息通信研究院調(diào)查數(shù)據(jù)顯示，云原生技術(shù)給企業(yè)帶來(lái)的價(jià)值中，提升資源利用率以節(jié)約成本連續(xù)兩年排名第一，2021 年已有九成用戶認(rèn)可該項(xiàng)價(jià)值。

隨著企業(yè)用云程度加深，越來(lái)越多的應(yīng)用遷移到云原生架構(gòu)上，然而2021 年 CNCF《FinOps Kubernetes Report》調(diào)研報(bào)告顯示，遷移至 Kubernetes 平臺(tái)后，68% 的受訪者表示所在企業(yè)計(jì)算資源成本有所增加，36% 的受訪者表示成本飆升超過(guò) 20%，這都說(shuō)明即使是資源利用率更高的云原生架構(gòu)也需要合理的資源成本管理。

圖1 CNCF統(tǒng)計(jì)企業(yè)遷移至kubernetes平臺(tái)成本變化調(diào)查

針對(duì)相同統(tǒng)計(jì)口徑，騰訊云對(duì)1000多云客戶進(jìn)行了資源利用情況分析，抽樣超過(guò)一萬(wàn)計(jì)算節(jié)點(diǎn)發(fā)現(xiàn)，42%的節(jié)點(diǎn)資源利用率低于10%，72%的節(jié)點(diǎn)資源利用率低于20%。

圖2 騰訊云資源利用率調(diào)查

為了幫助企業(yè)更好的遷移到云原生架構(gòu)，我們基于之前多年成本優(yōu)化的經(jīng)驗(yàn)系統(tǒng)的整理了云原生成本優(yōu)化的各種手段，可以歸結(jié)為三個(gè)層面：

第一層：通過(guò)使用混合云或多云服務(wù)自動(dòng)化工具無(wú)縫使用性價(jià)比最高的服務(wù)器資源（例如，異地部署、Intel換成AMD、私有云與公有云平衡等），達(dá)到跨云算力的最優(yōu)調(diào)度。

第二層：通過(guò)K8s容器切割，對(duì)高配服務(wù)器進(jìn)行切割后的再分配，讓CPU、內(nèi)存最小單位不受限制，這樣有不同類型資源需求的業(yè)務(wù)可以實(shí)現(xiàn)混合部署，以最大程度提升節(jié)點(diǎn)的資源利用率。

第三層：對(duì)業(yè)務(wù)的算力使用情況進(jìn)行建模量化并建立水位線、冗余度等配套指標(biāo)體系，再通過(guò)削峰填谷、在離線整合、自動(dòng)化擴(kuò)縮容等方式不斷優(yōu)化資源配置，從而幫企業(yè)最大程度的降本增效。

然而以上各種手段實(shí)現(xiàn)成本有高有低，諸如異地部署、在離線整合對(duì)大部分企業(yè)來(lái)說(shuō)技術(shù)挑戰(zhàn)相當(dāng)大，不同的企業(yè)也需要按照自己的實(shí)際情況來(lái)選擇，為此我們整理了企業(yè)云原生成本優(yōu)化的一般步驟，以供大家參考。

成本節(jié)省第一步：做到成本可觀測(cè)

要想降低云原生成本，首先要做到成本可觀測(cè)。具體來(lái)講，就是要知道成本具體花在哪里，通常企業(yè)內(nèi)部會(huì)劃分為多個(gè)部門，每個(gè)部門對(duì)資源的需求以及資源的掌控力度都不盡相同，要想讓各個(gè)部門對(duì)成本的認(rèn)識(shí)以及能力保持一致，就必須有清晰的成本認(rèn)識(shí)，可以從以下兩個(gè)方面來(lái)執(zhí)行：

建立資源利用率指標(biāo)

成本的管理實(shí)際上是資源的使用管理，如何快速并且準(zhǔn)確的識(shí)別出資源的分配、消耗，以及浪費(fèi)是成本優(yōu)化的前提條件。因此成本管理首先要做到的是資源消耗和資源利用率的可視化。

通常的做法是對(duì)資源的各種指標(biāo)，如CPU使用率、內(nèi)存使用率、磁盤使用率、進(jìn)出帶寬使用率等數(shù)據(jù)進(jìn)行采集并展示。采集的方案可以通過(guò)在資源上部署自己研發(fā)的agent，或者對(duì)接云廠商已有的監(jiān)控?cái)?shù)據(jù)。

這里需要注意的是要對(duì)資源打好標(biāo)簽，一般企業(yè)內(nèi)部都有成熟的CMDB系統(tǒng)，可以將資源按照類似產(chǎn)品線-業(yè)務(wù)線-集群等層次組織起來(lái)，也可以通過(guò)云廠商提供的資源標(biāo)簽功能進(jìn)行標(biāo)注組織，這樣可以從多維度多層次的洞察資源的消耗與利用率情況。

建立每日對(duì)賬機(jī)制

公有云廠商雖然默認(rèn)提供每日賬單機(jī)制，但主要是從產(chǎn)品維度來(lái)區(qū)分的，企業(yè)內(nèi)部則應(yīng)該按照產(chǎn)品線-業(yè)務(wù)線-集群多個(gè)層次來(lái)觀察每日的消耗，以便找出資源消耗異常的地方，如使用的彈性資源實(shí)例過(guò)多或者彈性時(shí)間過(guò)長(zhǎng)，這時(shí)候就可以review是否要將彈性的實(shí)例轉(zhuǎn)化為成本更便宜的常備實(shí)例。

除了要建立每日賬單機(jī)制，最好還要有預(yù)算機(jī)制，從集群-業(yè)務(wù)線-產(chǎn)品線多個(gè)層次確立每日資源的正常消耗，結(jié)合每日賬單就可以判斷出哪些集群、哪些業(yè)務(wù)線或者哪些產(chǎn)品線的資源使用超標(biāo)，這樣可以及時(shí)發(fā)現(xiàn)找到超標(biāo)的原因從而快速加以改進(jìn)。

完成第一步成本可觀測(cè)之后，企業(yè)就能清楚的知道具體某個(gè)業(yè)務(wù)線或者某個(gè)集群的資源利用率低，緊接著就可以執(zhí)行下面的步驟來(lái)具體節(jié)省成本。

成本節(jié)省第二步：公有云物盡其用

企業(yè)上云的第一步往往是把業(yè)務(wù)從原有的物理機(jī)或者虛擬機(jī)遷移到公有云，但往往因?yàn)閷?duì)云的產(chǎn)品本身不是很了解以及對(duì)云的成本本身認(rèn)識(shí)不足導(dǎo)致實(shí)際并未節(jié)省成本，甚至因?yàn)橐昧斯性茖?dǎo)致業(yè)務(wù)復(fù)雜度提升，相應(yīng)的成本反而提高了。仔細(xì)剖析，主要有兩方面的原因?qū)е拢?/p>

1. 考慮到業(yè)務(wù)的穩(wěn)定性以及高可用性，往往系統(tǒng)預(yù)留的資源是按照業(yè)務(wù)峰值再疊加一定的buffer來(lái)制定的，這就必然導(dǎo)致除了高峰時(shí)段資源利用率高，非高峰時(shí)段資源利用率低，甚至在業(yè)務(wù)低峰時(shí)段資源利用率極低。

   
   

2. 對(duì)業(yè)務(wù)本身的資源需求缺乏精確的認(rèn)識(shí)，有許多業(yè)務(wù)對(duì)資源的需求不規(guī)范，僅憑經(jīng)驗(yàn)或者出于業(yè)務(wù)性能的考慮，配置越高越好，然而業(yè)務(wù)實(shí)際運(yùn)行中發(fā)現(xiàn)出現(xiàn)嚴(yán)重的資源浪費(fèi)情況。

   
   

如果能夠充分利用公有云的彈性以及退改靈活性，則可以通過(guò)定時(shí)擴(kuò)縮容和機(jī)型降配兩種手段，就可以在不對(duì)業(yè)務(wù)進(jìn)行任何變更的情況下，直接有效的降低公有云的使用成本。

定時(shí)擴(kuò)縮容

有很多互聯(lián)網(wǎng)業(yè)務(wù)的流量具備周期性，尤其是一些社交應(yīng)用如微博、抖音等峰值流量出現(xiàn)在中午1點(diǎn)和晚上10點(diǎn)左右，可能達(dá)到日常流量的1.5倍甚至更多，若是用常備服務(wù)器支撐日常峰值流量，在非峰值時(shí)段服務(wù)器的利用率顯然是不足的。除此之外，通常在凌晨之后大部分公司的業(yè)務(wù)流量極低，這個(gè)時(shí)候只需要少數(shù)服務(wù)器即可支撐線上流量。對(duì)于這一類業(yè)務(wù)，實(shí)際上若是能根據(jù)實(shí)際業(yè)務(wù)的流量定時(shí)擴(kuò)縮容，比如中午12點(diǎn)擴(kuò)容，下午2點(diǎn)縮容，晚上8點(diǎn)擴(kuò)容，凌晨12點(diǎn)縮容，顯然可以大幅降低服務(wù)器成本。

還有一些典型場(chǎng)景如電商的大促，因?yàn)闀r(shí)間點(diǎn)比較明確，流量可預(yù)期，可在大促到來(lái)前定時(shí)擴(kuò)容一批機(jī)器，待活動(dòng)結(jié)束后再釋放。疫情的影響，導(dǎo)致一部分網(wǎng)課以及在線會(huì)議流量暴漲，但因?yàn)闀r(shí)間可預(yù)期，也可以采用定時(shí)擴(kuò)容的方式來(lái)應(yīng)對(duì)。相比購(gòu)買包年包月的機(jī)器，成本可以大幅降低。

機(jī)型調(diào)配

因?yàn)楣性粕咸峁┝烁鞣N配置的機(jī)型，業(yè)務(wù)可以根據(jù)自己對(duì)CPU、內(nèi)存、磁盤、網(wǎng)卡以及IO的實(shí)際需求來(lái)購(gòu)買適合自己業(yè)務(wù)需求的機(jī)型，而且公有云提供了包周、包月以及包年等多種方式的訂購(gòu)方式，大部分業(yè)務(wù)對(duì)自己的實(shí)際資源需求是不準(zhǔn)確的，可以有針對(duì)性的進(jìn)行壓測(cè)，確定實(shí)際需要的資源配置。針對(duì)包年包月包周購(gòu)買的服務(wù)器，可以在到期時(shí)根據(jù)實(shí)際的配置需求重新訂購(gòu)。如果是按量付費(fèi)的話，則可以隨時(shí)更改擴(kuò)容配置。

除此之外，大多數(shù)公有云還提供了兩種不被太多人關(guān)注的性價(jià)比更高的產(chǎn)品，一種是AMD實(shí)例，一種是競(jìng)價(jià)實(shí)例。

AMD實(shí)例

在 x86 服務(wù)器市場(chǎng)上，Intel 的 CPU 得益于其長(zhǎng)久以來(lái)出色的穩(wěn)定性和性能，占據(jù)了絕大多數(shù)的市場(chǎng)份額。但隨著 AMD Zen 架構(gòu)的 EPYC 處理器的推出，在同等性能下每核心的價(jià)格相比 Intel 的 CPU 更低。以公有云廠商為例，同等規(guī)格的實(shí)例若采用 AMD 處理器價(jià)格能降低 30%以上。

AMD實(shí)例可以兼容不同版本的操作系統(tǒng)，但因?yàn)锳MD Zen架構(gòu)發(fā)布于2017年，處理器的部分新特性在舊版操作系統(tǒng)上會(huì)出現(xiàn)部分功能支持上的缺陷。所以需要企業(yè)可以根據(jù)應(yīng)用的實(shí)際情況，自行決定需要使用的操作系統(tǒng)版本。

競(jìng)價(jià)實(shí)例

競(jìng)價(jià)實(shí)例也叫搶占式實(shí)例是一種按需實(shí)例，旨在降低部分場(chǎng)景下使用ECS的成本，合理的使用ECS競(jìng)價(jià)實(shí)例，最高可以降低50% – 90% 的運(yùn)營(yíng)成本(相比按量付費(fèi)的實(shí)例)，可以用相同的預(yù)算，將計(jì)算容量提升2–10倍。

創(chuàng)建競(jìng)價(jià)實(shí)例時(shí)，必須為指定的實(shí)例規(guī)格設(shè)置一個(gè)價(jià)格上限，當(dāng)指定的實(shí)例規(guī)格的當(dāng)前市場(chǎng)價(jià)格低于出價(jià)時(shí)，就能成功創(chuàng)建競(jìng)價(jià)實(shí)例，并按當(dāng)前市場(chǎng)價(jià)格計(jì)費(fèi)。默認(rèn)能穩(wěn)定持有實(shí)例1小時(shí)。1小時(shí)之后每5分鐘會(huì)檢查一下，當(dāng)市場(chǎng)價(jià)格高于出價(jià)或者資源供需關(guān)系變化時(shí)，實(shí)例會(huì)被自動(dòng)釋放。

為了保證盡可能高概率的彈出競(jìng)價(jià)實(shí)例，可以設(shè)置多個(gè)地域多個(gè)可用區(qū)多個(gè)規(guī)格進(jìn)行競(jìng)價(jià)，可以大大提升了競(jìng)價(jià)實(shí)例的創(chuàng)建成功率。除此之外，因?yàn)楦?jìng)價(jià)實(shí)例可能隨時(shí)會(huì)被自動(dòng)釋放，就需要業(yè)務(wù)具備彈性伸縮能力，在競(jìng)價(jià)實(shí)例被回收前，能夠自動(dòng)的重新選擇其它競(jìng)價(jià)實(shí)例來(lái)替代，如果沒(méi)有競(jìng)價(jià)實(shí)例了，再可以擴(kuò)容按量付費(fèi)的實(shí)例。

競(jìng)價(jià)實(shí)例適用于無(wú)狀態(tài)的應(yīng)用場(chǎng)景，例如可彈性伸縮的Web站點(diǎn)服務(wù)、圖像渲染、大數(shù)據(jù)分析和大規(guī)模并行計(jì)算等。應(yīng)用程序的分布度、可擴(kuò)展性和容錯(cuò)能力越高，越適合使用競(jìng)價(jià)實(shí)例節(jié)省成本和提升吞吐量。有狀態(tài)應(yīng)用不宜使用競(jìng)價(jià)實(shí)例，例如數(shù)據(jù)庫(kù)。因?yàn)楦?jìng)價(jià)失敗等原因?qū)е聦?shí)例被釋放時(shí)，應(yīng)用狀態(tài)難以保存。

私有云與公有云平衡

通常都認(rèn)為使用公有云比自己采購(gòu)服務(wù)器更加節(jié)約成本，然后實(shí)際并不一定。企業(yè)在實(shí)際使用過(guò)程中發(fā)現(xiàn)大批量采用公有云的包年包月機(jī)器后，按年攤銷的話相比自建機(jī)房采購(gòu)?fù)扰渲玫膯闻_(tái)服務(wù)器成本要高。所以已確定的長(zhǎng)期需要使用的包年包月的機(jī)器可以轉(zhuǎn)化為自己采購(gòu)的機(jī)器，短期內(nèi)無(wú)法確定是否是長(zhǎng)期需求的可繼續(xù)使用公有云。企業(yè)在每經(jīng)過(guò)一段時(shí)間，就需要對(duì)自己的公有云上的包年包月機(jī)器進(jìn)行review，確定哪些適合采用私有云，哪些繼續(xù)使用公有云。以字節(jié)和快手最為典型，快速發(fā)展的初期大量使用了公有云的包年包月資源，在企業(yè)穩(wěn)定發(fā)展后，開始逐步將這些資源轉(zhuǎn)化為私有機(jī)房的資源。

以上手段業(yè)務(wù)無(wú)須改造只需要做一些運(yùn)維層面的變更即可直接實(shí)現(xiàn)成本節(jié)省，適合大多數(shù)上云的企業(yè)。這個(gè)階段理論上負(fù)責(zé)運(yùn)維的團(tuán)隊(duì)即可執(zhí)行，不需要業(yè)務(wù)深度參與，執(zhí)行難度比較小。但當(dāng)前公有云的產(chǎn)品眾多，公有云的控制臺(tái)操作復(fù)雜不適合直接拿來(lái)使用，為此可借助一些二次開發(fā)的平臺(tái)，如開源算力引擎BridgX（https://github.com/galaxy-future/bridgx/），基于多個(gè)云廠商的SDK封裝并提供了簡(jiǎn)單易用的API以及WEB UI可快速的使用公有云的各種產(chǎn)品。

若企業(yè)若想進(jìn)一步優(yōu)化成本，則需要執(zhí)行成本節(jié)省的第三步：充分利用彈性與共享，來(lái)進(jìn)一步提高資源利用率，以降低成本。

成本節(jié)省第三步：充分利用彈性與共享

K8s資源切割

大部分企業(yè)內(nèi)部不同的業(yè)務(wù)對(duì)機(jī)器的資源需求不同，有的業(yè)務(wù)是計(jì)算密集型，對(duì)CPU的要求較高，有的業(yè)務(wù)是內(nèi)存密集型，對(duì)內(nèi)存的大小要求較高，有的業(yè)務(wù)是網(wǎng)絡(luò)密接型，對(duì)網(wǎng)卡的要求較高，有的業(yè)務(wù)是離線計(jì)算型，對(duì)磁盤空間要求較高，然而實(shí)際購(gòu)買的機(jī)器并不一定能夠與不同業(yè)務(wù)的需求完全吻合，這就造成大部分機(jī)器的資源無(wú)法充分利用。

所以需要一種更靈活的資源分配方式，如果業(yè)務(wù)能夠根據(jù)自己的需求任意定制是最好的，這一點(diǎn)自己采購(gòu)機(jī)器顯然是無(wú)法滿足的，公有云雖然提供了多種多樣配置的機(jī)型選擇，但對(duì)CPU、內(nèi)存等的規(guī)格還存在固定限制，要求CPU和內(nèi)存比為1:2以上。

云原生時(shí)代以Kubernetes技術(shù)為代表的容器云平臺(tái)，可以把企業(yè)現(xiàn)有的服務(wù)器資源統(tǒng)一管理起來(lái)，通過(guò)Kubernetes的資源隔離技術(shù)，按照業(yè)務(wù)實(shí)際的需求，給業(yè)務(wù)分配實(shí)際需要的資源。但因?yàn)镵ubernetes技術(shù)本身的復(fù)雜性，企業(yè)要想自己搭建一套可穩(wěn)定運(yùn)行投入到線上生產(chǎn)環(huán)境的云平臺(tái)，需要投入相當(dāng)大的研發(fā)人力，為此許多云廠商也提供了可托管的kubernetes集群，雖然在一定程度上降低了使用kubernetes的門檻，但仍然需要充分掌握Kubernetes技術(shù)本身，如交付的Pod的IP是動(dòng)態(tài)變化的，并且需要有與之配套的網(wǎng)絡(luò)、監(jiān)控、日志等解決方案，企業(yè)原有面向固定IP的運(yùn)維基礎(chǔ)設(shè)施將不再適用，所以說(shuō)遷移成本以及使用門檻還是相當(dāng)高的。

針對(duì)大部分企業(yè)的現(xiàn)狀，我們建議企業(yè)首先利用Kubernetes切割現(xiàn)有資源并以固定IP形式交付資源，這樣企業(yè)既能充分利用Kubernetes的資源隔離能力提高資源的利用率，又可以繼續(xù)復(fù)用原有的運(yùn)維解決方案，以便以低成本的方式遷移到Kubernetes容器云平臺(tái)，之后再根據(jù)自己的實(shí)際情況來(lái)決定后續(xù)的技術(shù)建設(shè)。

自動(dòng)擴(kuò)縮容

前面在介紹定時(shí)擴(kuò)縮容時(shí)提到有很多互聯(lián)網(wǎng)業(yè)務(wù)的流量具有明顯的周期性規(guī)律，例如中午和晚上流量明顯較高，而凌晨以后流量極低，可以使用定時(shí)擴(kuò)縮容固定數(shù)量的機(jī)器來(lái)解決。然后現(xiàn)實(shí)中業(yè)務(wù)的流量增長(zhǎng)模型并不是一成不變的，有可能某一天流量增長(zhǎng)超出以往，或者某一時(shí)間有突發(fā)的流量增長(zhǎng)，這時(shí)候僅僅靠定時(shí)擴(kuò)縮容顯然難以滿足，這就需要靠自動(dòng)擴(kuò)縮容來(lái)應(yīng)對(duì)。

當(dāng)前基于Kubernetes的容器云平臺(tái)提供了一些根據(jù)CPU、內(nèi)存使用率等簡(jiǎn)單的指標(biāo)來(lái)進(jìn)行彈性伸縮的手段，但對(duì)于大部分企業(yè)的業(yè)務(wù)來(lái)說(shuō)，實(shí)際線上服務(wù)模型要復(fù)雜得多，很難依靠某個(gè)單一指標(biāo)來(lái)衡量是否要擴(kuò)縮容。

一個(gè)更合理的方案是對(duì)流量模型進(jìn)行抽象，既要考慮QPS的變化，又要考慮業(yè)務(wù)實(shí)際性能。可以定義系統(tǒng)冗余度的指標(biāo)，它代表了系統(tǒng)實(shí)際能承受的最大消耗與實(shí)際消耗之間的比，其中系統(tǒng)實(shí)際能承受的最大消耗可以通過(guò)壓測(cè)來(lái)衡量，再結(jié)合各業(yè)務(wù)的實(shí)際情況定義一個(gè)最小冗余度和最大冗余度，若系統(tǒng)冗余度低于最小冗余度則自動(dòng)擴(kuò)容，高于最大冗余度則自動(dòng)縮容。

錯(cuò)峰調(diào)度

除了上面提到的一個(gè)業(yè)務(wù)流量通常在一天之中會(huì)有波峰波谷，如果企業(yè)內(nèi)部有多個(gè)業(yè)務(wù)并且不同業(yè)務(wù)的流量高峰低谷的時(shí)間不盡相同，則可以根據(jù)各業(yè)務(wù)的流量特點(diǎn)做錯(cuò)峰調(diào)度。

正如前面提到的通常各業(yè)務(wù)都是按照流量高峰做常備冗余部署資源，所以可以根據(jù)各業(yè)務(wù)的實(shí)際流量情況只保留最小程度的冗余，而將過(guò)度冗余的資源統(tǒng)一納管到一個(gè)虛擬資源池當(dāng)中，這樣的話就可以保證波峰波谷不同的業(yè)務(wù)能夠相互利用各自冗余的資源，提高系統(tǒng)整體的資源利用率。

錯(cuò)峰調(diào)度的挑戰(zhàn)在于能否準(zhǔn)確并及時(shí)的衡量各業(yè)務(wù)的冗余度，以便在業(yè)務(wù)需要資源的時(shí)候能夠及時(shí)的從虛擬資源池回收，并且如果虛擬資源池中資源不足時(shí)，還要及時(shí)的從外部申請(qǐng)資源。

更進(jìn)一步可以通過(guò)收集分析各業(yè)務(wù)的歷史指標(biāo)數(shù)據(jù)，對(duì)未來(lái)一段時(shí)間的指標(biāo)趨勢(shì)進(jìn)行預(yù)測(cè)，從而確定各個(gè)業(yè)務(wù)的流量高峰及低谷對(duì)應(yīng)的周期，并指導(dǎo)后續(xù)的資源調(diào)度。

GPU共享

隨著AI技術(shù)的逐步成熟，越來(lái)越多的企業(yè)開始構(gòu)建自己的AI應(yīng)用，并將AI應(yīng)用遷移到云。其中AI應(yīng)用對(duì)GPU資源的需求最為強(qiáng)烈，當(dāng)前基于 Kubernetes的容器云平臺(tái)在調(diào)度GPU資源時(shí)，通常是將一張完整的GPU卡分配給一個(gè)容器。隨著顯卡技術(shù)的不斷發(fā)展，半導(dǎo)體制造工藝的進(jìn)步，單張GPU卡的算力越來(lái)越強(qiáng)，同時(shí)價(jià)格也越來(lái)越高。但在很多的業(yè)務(wù)場(chǎng)景下，一個(gè)AI應(yīng)用并不需要一整張的GPU卡。顯然若能使多個(gè)容器共享一張GPU卡，并保證業(yè)務(wù)的安全隔離，則可以顯著提升GPU利用率，節(jié)約成本。

一些第三方如公有云提供了基于Kubernetes實(shí)現(xiàn)的GPU共享解決方案，如果企業(yè)在GPU資源上花費(fèi)成本較高，并且資源利用率不高，可以考慮使用GPU共享的解決方案，以便節(jié)省成本。

通過(guò)以上手段，業(yè)務(wù)可按照自己的實(shí)際需求利用彈性與共享來(lái)實(shí)現(xiàn)最大化的資源利用，不過(guò)需要有企業(yè)級(jí)的統(tǒng)一云平臺(tái)提供K8s切割、自動(dòng)擴(kuò)縮容、錯(cuò)峰調(diào)度以及GPU共享等能力。通常有兩種方案，一種是自建基于K8s的云平臺(tái)，不過(guò)考慮到技術(shù)門檻和生產(chǎn)環(huán)境的復(fù)雜性，一般企業(yè)需要投入至少十名以上的研發(fā)人員才能建設(shè)一個(gè)完整的K8s云平臺(tái)，一種是使用第三方如公有云托管的K8s集群，雖然省去了自行維護(hù)K8s集群的精力，但仍需掌握K8s的各種功能特性和開發(fā)能力，門檻依然很高。為了我們提供了一個(gè)更加容易落地的方案，就是在企業(yè)原有的運(yùn)維設(shè)施的基礎(chǔ)上，根據(jù)需要集成開源的解決方案如開源算力引擎BridgX（https://github.com/galaxy-future/bridgx/），支持web服務(wù)自動(dòng)擴(kuò)縮容、K8s切割并以固定IP形式輸出等功能，只需要很小的開發(fā)成本即可擁有以上功能。

當(dāng)企業(yè)達(dá)到一定規(guī)模后，要想進(jìn)一步優(yōu)化成本，就得從更高維度去考慮了。這個(gè)時(shí)候就可以考慮異地部署、混合編排、在離線整合等復(fù)雜度更高的手段了。

成本節(jié)省第四步：應(yīng)用混部與異地部署

異地部署

企業(yè)的IT 成本除了服務(wù)器自身的成本外，還包括部署服務(wù)器的機(jī)架成本、機(jī)房建設(shè)的成本、電力成本以及網(wǎng)絡(luò)帶寬和專線的成本等。西部地區(qū)由于電力資源豐富，土地成本以及各種政策扶持的因素，建設(shè)數(shù)據(jù)中心的成本要遠(yuǎn)小于東部以及中部地區(qū)。綜合考慮多方面成本，選擇在綜合成本更低的地區(qū)建設(shè)或租用機(jī)房，或者選擇公有云單價(jià)更低的可用區(qū)，可以明顯地降低成本。以公有云為例，西部地區(qū)按量付費(fèi)實(shí)例的價(jià)格要比東部地區(qū)優(yōu)惠10%，某些地區(qū)如張家口甚至能優(yōu)惠到30%。

對(duì)于企業(yè)內(nèi)部來(lái)說(shuō)，異地部署最大的挑戰(zhàn)在于數(shù)據(jù)同步與時(shí)延，不同IDC之間根據(jù)距離通常有10-30ms的時(shí)延。對(duì)于時(shí)延比較敏感的在線業(yè)務(wù)來(lái)說(shuō)，要做到異地部署挑戰(zhàn)比較大。但對(duì)于時(shí)延不敏感的離線業(yè)務(wù)，可以把存儲(chǔ)和計(jì)算遷移到成本較低的西部IDC。但離線業(yè)務(wù)通常數(shù)據(jù)量比較大，在百T以上甚至達(dá)到PB級(jí)規(guī)模，若通過(guò)公網(wǎng)傳輸則要以月為單位，而專線的解決方案價(jià)格又比較昂貴，通常在百萬(wàn)以上。一個(gè)成本較低的解決方案可以使用基于開源算力引擎BridgX的數(shù)據(jù)物流服務(wù)DTExpress，支持通過(guò)公網(wǎng)在不同的公有云的不同IDC之間傳輸海量數(shù)據(jù)，1TB數(shù)據(jù)的成本只有1000元左右。

混合編排

上面提到企業(yè)不同業(yè)務(wù)所采用的機(jī)型必定存在某一方面的利用率不足，比如計(jì)算密集型的web業(yè)務(wù)通常磁盤使用率不高，內(nèi)存密集型的NoSQL業(yè)務(wù)和IO密集型的數(shù)據(jù)庫(kù)業(yè)務(wù)通常CPU利用率也不高，通過(guò)使用K8s切割現(xiàn)有的資源雖然可以一定程度的提供資源使用率，但是因?yàn)榇蟛糠制髽I(yè)內(nèi)部的機(jī)器配置不高，所以即使使用了K8s管理，仍然會(huì)存在很多利用不上的資源碎片。一個(gè)更好的思路就是把各個(gè)業(yè)務(wù)使用的各種小配置的機(jī)器進(jìn)行整合統(tǒng)一置換為高配機(jī)器，再把這些業(yè)務(wù)混合部署統(tǒng)一編排，這樣的話就能做到資源完全互補(bǔ)。

如基于AMD處理器的神龍服務(wù)器，單臺(tái)最高具備256核2T內(nèi)存2T磁盤，并具備高達(dá)60Gps的網(wǎng)絡(luò)帶寬，可以借助Kubernetes的資源隔離技術(shù)，對(duì) CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)進(jìn)行精細(xì)化的調(diào)度，如下圖所示一臺(tái)神龍服務(wù)器上可同時(shí)切割十幾個(gè)容器跑web業(yè)務(wù)，十幾個(gè)容器跑NoSQL，十幾個(gè)容器跑MySQL，可滿足不同業(yè)務(wù)的不同資源訴求。

不過(guò)多個(gè)業(yè)務(wù)部署到一臺(tái)大規(guī)格機(jī)器比較大的風(fēng)險(xiǎn)是一臺(tái)機(jī)器宕機(jī)可能影響十幾個(gè)甚至幾十個(gè)服務(wù)，這時(shí)候就需要通過(guò)服務(wù)/資源治理平臺(tái)進(jìn)行快速治理，再加上快速擴(kuò)容、快速數(shù)據(jù)分發(fā)的能力，則可以達(dá)到分鐘級(jí)的業(yè)務(wù)遷移。

在離線整合

大部分企業(yè)內(nèi)部往往存在兩種業(yè)務(wù)類型，一種是在線業(yè)務(wù)，通常流量高峰比較一致，如果流量高了，在線業(yè)務(wù)都需要很多機(jī)器，一種是離線業(yè)務(wù)，往往是凌晨開始計(jì)算，與在線業(yè)務(wù)的高峰時(shí)間錯(cuò)開。一個(gè)合理的設(shè)想是為什么不在線業(yè)務(wù)高峰期，把離線計(jì)算的機(jī)器拆借給在線業(yè)務(wù)使用，等到凌晨業(yè)務(wù)低峰期，再把在線業(yè)務(wù)的機(jī)器拆借給離線業(yè)務(wù)使用，等到早上業(yè)務(wù)高峰期前再拆分回來(lái)，然而在企業(yè)內(nèi)部這兩種業(yè)務(wù)的機(jī)器并不能充分利用，主要有以下原因：

1、部門墻

在企業(yè)內(nèi)部機(jī)器的產(chǎn)品線一般是固定的，成本和利用率也是按照產(chǎn)品線計(jì)算的，所以通常情況下機(jī)器是不會(huì)在不同部門之間自由流轉(zhuǎn)的。

2、機(jī)器配置差異大

一般情況下在線業(yè)務(wù)對(duì)CPU的要求比較高，對(duì)磁盤的需求低，以web計(jì)算為例，需要的機(jī)器配置一般是16核16G內(nèi)存200G磁盤，而對(duì)于離線業(yè)務(wù)來(lái)說(shuō)，對(duì)CPU的要求不高，但對(duì)內(nèi)存和磁盤要求比較高，尤其是磁盤單機(jī)可達(dá)1T以上，所以兩種類型的機(jī)器想復(fù)用也比較難。

為了解決以上問(wèn)題，一些企業(yè)使用了在離線混部的解決方案，就是將在線業(yè)務(wù)和離線業(yè)務(wù)部署在同一個(gè)集群同時(shí)運(yùn)行，在線業(yè)務(wù)流量高時(shí)資源主要調(diào)度給在線業(yè)務(wù)，業(yè)務(wù)低峰期主要運(yùn)行離線計(jì)算，甚至是必要時(shí)停掉一些離線任務(wù)將資源全部讓渡給在線業(yè)務(wù)，比如阿里雙11期間就會(huì)停掉離線計(jì)算業(yè)務(wù)，將資源全部留給線上的在線業(yè)務(wù)。這種方案解決了以上問(wèn)題，但是對(duì)技術(shù)的挑戰(zhàn)比較大，需要對(duì)CPU、內(nèi)存和網(wǎng)絡(luò)進(jìn)行專門的優(yōu)化，以確保離線計(jì)算不會(huì)爭(zhēng)搶在線計(jì)算的資源。

以上手段無(wú)論是異地部署、混合編排還是在離線整合都需要涉及不止一個(gè)業(yè)務(wù)，需要從企業(yè)整體層面來(lái)考慮，通常不是一個(gè)部門能解決的。這時(shí)候建議企業(yè)內(nèi)部以基礎(chǔ)平臺(tái)或者云平臺(tái)部門牽頭，首先聯(lián)合關(guān)系密切或者對(duì)新技術(shù)感興趣的部門成立聯(lián)合項(xiàng)目組，或者以公司名義成立專項(xiàng)來(lái)進(jìn)行，先從小的業(yè)務(wù)入手遷移到容器云平臺(tái)，待驗(yàn)證平臺(tái)功能完善后，再考慮逐步把核心業(yè)務(wù)遷移到平臺(tái)，最終達(dá)到優(yōu)化企業(yè)整體資源利用率的目的。

總結(jié)

上面詳細(xì)論述了企業(yè)優(yōu)化成本的實(shí)時(shí)步驟，建議不同企業(yè)根據(jù)自己現(xiàn)階段情況有條件的加以選擇。如果是企業(yè)剛剛遷移上云，可以重點(diǎn)從第二步入手，充分了解云產(chǎn)品的特性，并結(jié)合自己業(yè)務(wù)的特點(diǎn)，真正做到上云以節(jié)省成本。如果企業(yè)已經(jīng)上云并且業(yè)務(wù)穩(wěn)定運(yùn)行，但資源利用率不高，并希望通過(guò)技術(shù)手段進(jìn)一步提高資源利用率，除了執(zhí)行第二步以外，還可以考慮第三步在原有的運(yùn)維設(shè)施基礎(chǔ)上結(jié)合開源的解決方案，選擇適合自己的優(yōu)化手段。最后如果企業(yè)的業(yè)務(wù)達(dá)到一定規(guī)模，比如具備上萬(wàn)臺(tái)服務(wù)器時(shí)，就可以考慮采用異地部署、混合編排以及在離線整合等更高層次更復(fù)雜的方案。

Meetup預(yù)告

以上論述的云原生成本優(yōu)化的手段我們也將在首次對(duì)外舉行的Meetup中詳細(xì)的闡述，歡迎感興趣的朋友報(bào)名參加。