雲上省錢新玩法 教你如何優惠與靈活兼得

熟悉公有云的讀者想必對雲上資源計費模式都有必定了解，雲廠商一般會提供兩種計費方式：後付費和預付費。

後付費是一種基礎計費方式，資源以小時爲單位訂價，按使用時長付費，資源刪除沒有限制，適用於短時間運行，或週期性運行但每個月運行總時長較短的業務；

預付費是一種優惠計費方式，一次性支付數月/數年的費用以得到相應折扣，折算下來每小時的單價會比標準訂價更爲划算，但資源到期前一般不能刪除，適用於長期運行而且沒有周期性刪除重建需求的業務。

爲了儘量地優化上雲成本，多數用戶在上雲初期會之後付費的方式購買資源，在業務運行穩定後傾向於將後付費轉變爲預付費以下降使用成本。可是預付費資源的操做限制在某些場景下會下降資源生命週期管理的便捷性。例如如下兩種狀況，你是否也曾遭遇到過？

• 使用K8S/彈性伸縮部署業務，集羣中的實例受策略或負載影響，須要常常性刪除-重建以進行調整，受限於包年包月資源到期前不支持刪除的限制，即便集羣中實例總體運行時間較長也只能選擇後付費的方式，沒法享受優惠；
• 混合雲場景下，考慮多IDC數據同步和業務延遲，須要調整包年包月資源的可用區。一樣因爲包年包月資源的刪除限制，爲了保證服務正常運行，只能充值而後在新可用區購置資源，再提交工單申請舊可用區資源的刪除和退款，最後申請提現。操做流程複雜且須要技服介入協商。

後付費和預付費雖然是靈活和優惠的兩種取捨，但卻並不是必定沒法兼得，京東智聯雲近期推出的「實例抵扣券」產品，就能夠完美解決上述場景中用戶遇到的問題，幫助用戶進一步節省資源購置投入。

爲了方便你們理解，在介紹實例抵扣券以前，咱們先以停車費爲例子作一個類比假設：

停車場的收費方式你們都很是熟悉，基本的收費模式是「X元/小時」，按停放時長計費在離場時收費。爲了知足長期停放需求，停車場也會提供固定車位月租和年租，車位與車牌綁定，一次性支付費用後登記車牌的車輛將不會再收取費用。不少家庭響應節能減排號召，紛紛購入了新能源汽車，對於有多輛汽車的家庭，就會頭疼於兩個問題：

1. 到底登記哪輛車？
2. 職場或家庭住址變更沒法退租怎麼辦？

這個時候停車場推出了一種「停車卡」，價格和月租、年租至關，購買後天天都有至關於一輛車停放24小時的額度能夠抵扣，不但不限抵扣的具體車牌，還能夠同時給多輛車抵扣（多輛車累加停放時長後，超出24小時部分按標價繳費便可），這樣就解決了A問題的困擾；再進一步，停車場擴大規模在城市內創建了多家連鎖，同時還推出了一類可在城市內任意連鎖機構使用的卡，這樣即便更換生活工做區域也能就近繼續使用，甚至若是家和公司家附近都有一家，還能最大化停車權益，節省原來一半的停車費，這樣B問題也就迎刃而解了。

回到現實，雖然例子中這樣的「停車卡」京小云還沒據說哪裏有賣，車主朋友們可能還要再等等。但若是你是京東智聯雲的用戶，那麼與其功能相似的「實例抵扣券」你能夠即刻擁有。

實例抵扣券是一種全新的計算實例（雲主機、原生容器、POD）付費方式，按月/年預付費單獨購買後，用於後付費的實例在結算時進行抵扣。

實例抵扣券將資源付費和資源生命週期解耦，購買抵扣券須要指定一些屬性，這些屬性決定了可抵扣的實例特徵而不限於具體某個或某些實例，所以很是適合有長期資源使用需求，指望下降成本的同時也要求保持資源創刪靈活的業務。

相似「停車卡」天天提供至關於一輛車停放24小時的抵扣時長，實例抵扣券會根據購買時指定的規格屬性，將其轉換成計算力¹（CPU規格：1計算力=1核；GPU規格：1計算力=1卡），在每一個小時都提供至關於這些規格的實例運行一個小時的計算量²，每當有後付費實例結算時，會優先使用抵扣券扣減，一旦扣減成功將無需支付這次結算費用。

計算力¹：同一規格族內，反映單實例或多實例集羣計算能力的指標，CPU/GPU規格可認爲分別等同於vCPU核數/GPU卡數，全部實例的計算力相加便是集羣的計算力。（因爲不一樣規格族實例底層的物理資源和CPU內存配比不一樣，所以計算力的比較僅在同規格族內進行纔有意義）

計算量²：必定計算力在必定時間段內能夠完成的計算任務狀況，計算量 = 計算力 * 運行時長（秒）。如，2臺g.n2.large實例運行一小時，則其計算量爲 2×2×3600

好比在華北區域購買了一張一個月時長、g.n2規格族、10計算力的無資源預留型抵扣券，那麼購買後每一個小時都有10*3600（10覈實例運行1個小時）的計算量可使用。同地域同規格族內的多個後付費實例，均可以在每小時結算時優先使用抵扣券抵扣費用，2覈實例運行了1個小時，消耗2*3600；1覈實例運行了30分鐘，消耗1*0.5*1800… …以此類推，超出可用計算量的實例運行時長將按標準小時單價扣費。

實例抵扣券有多種屬性，須要用戶在購買時指定。其中，資源是否預留決定了抵扣券使用的區域範圍和抵扣規則，是實例抵扣券最重要的一個屬性。

• 無預留型，須要指定實例類型（雲主機、容器、POD）、地域、規格族、計算力和時長，因爲系統不作資源預留，所以不限制使用的可用區，同時因爲同一個規格族內後付費實例的單價跟核數或者卡數基本呈線性，所以同規格族內的多數實例規格均可以按比例進行抵扣。

  類比上面的例子，至關於購買了不限使用停車場的「停車卡」，這類卡支持不一樣車型的小汽車抵扣，若是普通小汽車收費6元/小時，中型客車收費9元/小時，那麼中型客車也可以使用「停車卡」，只不過在結算的時候須要按正常車型的1.5倍計算停放時長進行抵扣。

  

  預留型（後續推出），顧名思義會作計算資源的預留，所以必須指定實例類型（雲主機、容器、POD）、可用區、規格、數量和時長，系統將嚴格按照這些屬性預留，以保證不管雲上資源售賣程度如何，在有效期內都承諾有與抵扣券屬性匹配的實例能夠建立，在抵扣的時候也只有徹底匹配的實例纔可以使用。

一樣類比於「停車卡」的例子中，至關於放棄了多停車場可用的靈活性，而選擇僅在一家停車場使用，以保證不管什麼時候都至少有預留數量的車位可停。同時因爲須要根據車型預留車位，所以須要在購卡時就指定是用於小型汽車仍是中型客車，肯定後只有此類車型纔可以使用進行抵扣。

介紹了實例抵扣券這麼多的優勢，那麼如何根據當前的資源規模和使用狀況購買合適計算力的抵扣券呢？

以使用K8S部署的線上web服務爲例，一般業務會以天存在週期性負載波動。其中，穩定負載對應的節點數量必定適合購買與其計算力至關的實例抵扣券，波動負載對應的實例能夠根據波動週期統計下運行時長，而後對比實例小時單價和抵扣券月價，計算有多少數量的實例適合購買抵扣券。在下圖的實例中，節點數量以天爲單位在6~10之間波動，假設該規格對應的抵扣券月價摺合成小時價格後，是標準小時訂價的0.4倍，也就是說日運行時長超過24*0.4=9.6小時的實例使用抵扣券都更爲划算，那麼顯然在這個例子中，除了持續運行的6個節點，有2個節點每日運行時長超過了9.6個小時，所以爲6+2個實例購買抵扣券，能夠最大程度節省費用。

無資源預留型的實例抵扣券已經正式上線，目前在京東智聯雲所有地域支持購買，產品開通僅需提交工單申請便可。同時，抵扣券詳細的產品文檔已經在官網上線，價格、詳細抵扣規則、抵扣明細查看等產品使用細節，均可前往瞭解。

點撃"閱讀原文"，瞭解限時領活動