前言

近年來，公有云、混合雲等技術在全球迅速發展，雲的普及度越來越高，Docker、Kubernetes、DevOps、Service Mesh等雲原生技術蓬勃發展。但在“上雲”之後，企業卻往往發現“用雲”卻並不是那麼容易。

麥肯錫的一份研究報告表示，全球伺服器的平均每日利用率通常最高僅為6％。Garter統計，全球資料中⼼利用率不足12%。以上資料都表明，資料中心的伺服器成本及資源消耗方面會給企業造成巨大的“浪費”。

根據中國資訊通訊研究院調查資料顯示，雲原生技術給企業帶來的價值中，提升資源利用率以節約成本連續兩年排名第一，2021 年已有九成使用者認可該項價值。

隨著企業用雲程度加深，越來越多的應用遷移到雲原生架構上，然而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是否要將彈性的例項轉化為成本更便宜的常備例項。

除了要建立每日賬單機制，最好還要有預算機制，從叢集-業務線-產品線多個層次確立每日資源的正常消耗，結合每日賬單就可以判斷出哪些叢集、哪些業務線或者哪些產品線的資源使用超標，這樣可以及時發現找到超標的原因從而快速加以改進。

完成第一步成本可觀測之後，企業就能清楚的知道具體某個業務線或者某個叢集的資源利用率低，緊接著就可以執行下面的步驟來具體節省成本。

成本節省第二步：公有云物盡其用

企業上雲的第一步往往是把業務從原有的物理機或者虛擬機器遷移到公有云，但往往因為對雲的產品本身不是很瞭解以及對雲的成本本身認識不足導致實際並未節省成本，甚至因為引用了公有云導致業務複雜度提升，相應的成本反而提高了。仔細剖析，主要有兩方面的原因導致：

1. 考慮到業務的穩定性以及高可用性，往往系統預留的資源是按照業務峰值再疊加一定的buffer來制定的，這就必然導致除了高峰時段資源利用率高，非高峰時段資源利用率低，甚至在業務低峰時段資源利用率極低。
2. 對業務本身的資源需求缺乏精確的認識，有許多業務對資源的需求不規範，僅憑經驗或者出於業務效能的考慮，配置越高越好，然而業務實際執行中發現出現嚴重的資源浪費情況。

如果能夠充分利用公有云的彈性以及退改靈活性，則可以透過定時擴縮容和機型降配兩種手段，就可以在不對業務進行任何變更的情況下，直接有效的降低公有云的使用成本。

定時擴縮容

有很多網際網路業務的流量具備週期性，尤其是一些社交應用如微博、抖音等峰值流量出現在中午1點和晚上10點左右，可能達到日常流量的1.5倍甚至更多，若是用常備伺服器支撐日常峰值流量，在非峰值時段伺服器的利用率顯然是不足的。除此之外，通常在凌晨之後大部分公司的業務流量極低，這個時候只需要少數伺服器即可支撐線上流量。對於這一類業務，實際上若是能根據實際業務的流量定時擴縮容，比如中午12點擴容，下午2點縮容，晚上8點擴容，凌晨12點縮容，顯然可以大幅降低伺服器成本。

還有一些典型場景如電商的大促，因為時間點比較明確，流量可預期，可在大促到來前定時擴容一批機器，待活動結束後再釋放。疫情的影響，導致一部分網課以及線上會議流量暴漲，但因為時間可預期，也可以採用定時擴容的方式來應對。相比購買包年包月的機器，成本可以大幅降低。

機型調配

因為公有云上提供了各種配置的機型，業務可以根據自己對CPU、記憶體、磁碟、網絡卡以及IO的實際需求來購買適合自己業務需求的機型，而且公有云提供了包周、包月以及包年等多種方式的訂購方式，大部分業務對自己的實際資源需求是不準確的，可以有針對性的進行壓測，確定實際需要的資源配置。針對包年包月包周購買的伺服器，可以在到期時根據實際的配置需求重新訂購。如果是按量付費的話，則可以隨時更改擴容配置。

除此之外，大多數公有云還提供了兩種不被太多人關注的價效比更高的產品，一種是AMD例項，一種是競價例項。

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可快速的使用公有云的各種產品。

若企業若想進一步最佳化成本，則需要執行成本節省的第三步：充分利用彈性與共享，來進一步提高資源利用率，以降低成本。

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

K8s資源切割

大部分企業內部不同的業務對機器的資源需求不同，有的業務是計算密集型，對CPU的要求較高，有的業務是記憶體密集型，對記憶體的大小要求較高，有的業務是網路密接型，對網絡卡的要求較高，有的業務是離線計算型，對磁碟空間要求較高，然而實際購買的機器並不一定能夠與不同業務的需求完全吻合，這就造成大部分機器的資源無法充分利用。

所以需要一種更靈活的資源分配方式，如果業務能夠根據自己的需求任意定製是最好的，這一點自己採購機器顯然是無法滿足的，公有云雖然提供了多種多樣配置的機型選擇，但對CPU、記憶體等的規格還存在固定限制，要求CPU和記憶體比為1:2以上。

雲原生時代以Kubernetes技術為代表的容器雲平臺，可以把企業現有的伺服器資源統一管理起來，透過Kubernetes的資源隔離技術，按照業務實際的需求，給業務分配實際需要的資源。但因為Kubernetes技術本身的複雜性，企業要想自己搭建一套可穩定執行投入到線上生產環境的雲平臺，需要投入相當大的研發人力，為此許多雲廠商也提供了可託管的kubernetes叢集，雖然在一定程度上降低了使用kubernetes的門檻，但仍然需要充分掌握Kubernetes技術本身，如交付的Pod的IP是動態變化的，並且需要有與之配套的網路、監控、日誌等解決方案，企業原有面向固定IP的運維基礎設施將不再適用，所以說遷移成本以及使用門檻還是相當高的。

針對大部分企業的現狀，我們建議企業首先利用Kubernetes切割現有資源並以固定IP形式交付資源，這樣企業既能充分利用Kubernetes的資源隔離能力提高資源的利用率，又可以繼續複用原有的運維解決方案，以便以低成本的方式遷移到Kubernetes容器雲平臺，之後再根據自己的實際情況來決定後續的技術建設。

自動擴縮容

前面在介紹定時擴縮容時提到有很多網際網路業務的流量具有明顯的週期性規律，例如中午和晚上流量明顯較高，而凌晨以後流量極低，可以使用定時擴縮容固定數量的機器來解決。然後現實中業務的流量增長模型並不是一成不變的，有可能某一天流量增長超出以往，或者某一時間有突發的流量增長，這時候僅僅靠定時擴縮容顯然難以滿足，這就需要靠自動擴縮容來應對。

當前基於Kubernetes的容器雲平臺提供了一些根據CPU、記憶體使用率等簡單的指標來進行彈性伸縮的手段，但對於大部分企業的業務來說，實際線上服務模型要複雜得多，很難依靠某個單一指標來衡量是否要擴縮容。

一個更合理的方案是對流量模型進行抽象，既要考慮QPS的變化，又要考慮業務實際效能。可以定義系統冗餘度的指標，它代表了系統實際能承受的最大消耗與實際消耗之間的比，其中系統實際能承受的最大消耗可以透過壓測來衡量，再結合各業務的實際情況定義一個最小冗餘度和最大冗餘度，若系統冗餘度低於最小冗餘度則自動擴容，高於最大冗餘度則自動縮容。

錯峰排程

除了上面提到的一個業務流量通常在一天之中會有波峰波谷，如果企業內部有多個業務並且不同業務的流量高峰低谷的時間不盡相同，則可以根據各業務的流量特點做錯峰排程。

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

錯峰排程的挑戰在於能否準確並及時的衡量各業務的冗餘度，以便在業務需要資源的時候能夠及時的從虛擬資源池回收，並且如果虛擬資源池中資源不足時，還要及時的從外部申請資源。

更進一步可以透過收集分析各業務的歷史指標資料，對未來一段時間的指標趨勢進行預測，從而確定各個業務的流量高峰及低谷對應的週期，並指導後續的資源排程。

GPU共享

隨著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預告

以上論述的雲原生成本最佳化的手段我們也將在首次對外舉行的Meetup中詳細的闡述，歡迎感興趣的朋友報名參加。