雲端構建大規模系統的挑戰
雲計算平臺“按需獲取”的特性使得用戶可以隨時獲取所需計算資源，實現計算資源與業務規模的動態匹配。雲計算時代計算資源已不再是構建大規模系統的瓶頸，多數情況下成本成爲了企業在構建大規模應用時的最大挑戰。
如何降低雲端系統的成本
降低雲端系統的成本，最核心的就是要充分利用雲計算的特點，尤其是“按需獲取”和“按使用付費”。例如，根據業務量變化來及時伸縮計算資源就是常見的降低成本的方式。在架構上以微服務架構替代單體架構，使系統獲得更細的伸縮粒度，從而利用更合適，更便宜的計算資源。
關於降低成本一個容易被忽視的與構建傳統非雲端系統不同的地方是系統的實現也要充分考慮雲計算的定價模式，例如，雲端的消息服務通常是按請求次數來計費的，所以在一次調用中發送多條消息就可以將成本降至原來的幾分之一。
實例即雲端虛擬主機（instance）是最基本的計算資源，當前在大多數的雲上系統中，實例成本在總成本中都佔有很高的比重（目前多數雲端系統都是直接從本地系統遷移過來的，較少採用Serverless等架構），所以，關注實例的收費模式，對於降低系統成本是非常重要的。
以下是3種基本的實例定價模式：
- 按需：隨用隨啓，根據運行的實例以按小時或按秒的方式計算容量並付費。
- 預留：有一定的使用承諾（如：1年，3年的使用承諾），與按需實例的定價相比，預留實例可提供大幅折扣（通常爲按需實例的60%）。
- 競價：是一種由雲商推出的極端彈性和廉價的計算資源。它的價格根據供需關係變化，與按量付費實例的相比具有非常明顯的價格優勢（通常爲按需實例的10%-20%）。同時，競價實例中存在系統中斷機制，系統將根據價格和資源池的存量等情況綜合考慮，決定中斷運行實例。
由以上可見競價實例是最具有價格優勢的計算資源，有效的利用好競價實例將可以大幅節省計算資源的成本。
關於競價實例
收費模式
爲了獲得某一種競價實例資源，用戶需要設置一個最高價，當設置的最高價高於當前該種實例的市場價格時用戶就可以獲得實例。這裏要注意的是用戶根據使用量支付的費用是基於市場價格的，而不是用戶的出價。
實例池
整個競價實例市場按地區（region), 機型，可用區（Availbility Zone）維度切分成了很多不同的實例池，如下圖。每個池都單獨評估自己的供求關係，這意味着每個池都有自己的容量和市場價格。也就是說當某個池的供需關係導致價格發生變化或者實例被中斷回收時並不會影響其他的池。
中斷
競價實例的中斷髮生在以下兩種情況:
- 爲某個實例池設置的最高競價小於當前該池的市場價格
- 實例池出現供需關係緊張，資源短缺
在實例被終止回收前的數分鐘，雲平臺會發出中斷告警。
應用競價實例
由於競價實例存在被中斷的可能性往往嚇退了不少的用戶，而實際上競價實例規模巨大（AWS 曾披露：2016年一週的競價實例的計算能力大於2012一年所有的計算實例），在合理利用的情況下是可以保證集羣中實例容量的穩定性的。雲商也會提供競價實例的歷史價格及回收率查詢（如：AWS的相關數據可以在這裏查到 https://aws.amazon.com/ec2/spot/instance-advisor/）。
典型適用場景
1 時間靈活性
目前，競價實例被較多的使用在大數據計算，機器學習模型訓練等後臺批量任務中，這類任務的通常的特點是與線上系統不同，不要實時的對線上請求給以響應，我們稱之爲時間靈活性。所以，可以利用重試機制實現對中斷進行容錯。目前，如果你使用雲平臺提供的大數據服務或機器學習服務（如：AWS的EMR和SageMaker），雲平臺通常都對使用競價實例提供了內置的支持（可以自動完成任務的重試）。
2 實例靈活性
當在線服務的請求不需要由某個特定實例來進行處理，這樣的服務就具有實例靈活性。如果能夠使線上服務具有良好的彈性，並且有效地處理好中斷的影響，競價實例同樣可以被使用於線上服務集羣。
提升線上系統的彈性通常可以遵循面向失效和麪向恢復的設計原則。詳細內容可以參考我在Qcon2019 北京上的演講“超大規模高可用性雲端系統構建之禪” （https://www.infoq.cn/article/k4aTYPotBB-5IcoAkUVq）。
本篇中將重點介紹競價實例集羣的一些管理實踐，它們可以非常有效的提高集羣容量的穩定性，從而幫助我們減少競價實例回收帶來的對服務可用性的影響。
- “混搭”構建集羣
- 多種價格模式的混搭
可以考慮通過預留實例來保證服務基本的SLA，利用Auto Scaling和競價實例來應付流量變化。
- 不同池的競價實例混搭
如上面提及的不同池的價格變化和中斷回收是獨立的，所以我們在機器中混合來自不同池的主機就可以有效的避免某個池內機器發生短缺而導致中斷引起的集羣大規模容量損失。
- 主動管理中斷
雲計算平臺都會在終止競價實例的數分鐘前發出中斷警告（中斷警告可以通過查詢實例的元數據或者監聽事件管理器來獲得）。有效的利用這段時間，不僅可以實現被中斷實例的完美終止（graceful termination)，還能通過服務及狀態遷移大大提高集羣容量的穩定性從而保證可用性和服務能力。
對於最爲簡單的場景通常包括以下步驟：
對於更爲複雜的情況，
- 有狀態的情況：需要處理數據和狀態的遷移
- 使用其他服務發現機制：需要調用其他服務發現機制來管理服務實例的添加和移除。目前，consul是最常見的服務發現軟件
- 容器化環境：如Kubernetes，這時需要配合kubernetes來完成中斷節點上Pod的遷移及替代node的預先開啓。
在實踐中，我們可以藉助SpotMax的MaxGroup來完成這些複雜的主動中斷管理工作。
- 下載MaxGroup Lite版本 http://spotmax.mobvista.com/pricing
- 獲取免費license：http://spotmax.mobvista.com/user/service
- 快速使用文檔：https://docs.spotmaxtech.com/maxgroup-shuo-ming-wen-dang/kuai-su-ru-men