前面有一篇博文對雲平臺的基礎知識和核心概念進行了一次梳理（https://blog.csdn.net/yejingtao703/article/details/82321286），本篇在此基礎上深入解析下雲實例選擇時需要注意的一些問題以及出現故障時平臺的遷移策略。

本地盤與雲盤：

在雲平臺啟用例項時我們經常會看到一個選擇，磁碟是選擇本地盤還是雲盤，單獨從例項本身來說，我們很難發現這兩種機制的區別和意義，如果考慮到雲平臺的容災機制，雲盤的優勢將會體現出來。

冷遷移和熱遷移：

關於冷遷移和熱遷移在不同平臺上定位略有不同，但在大體方向上平臺都希望90%的容災通過熱遷移來完成，因為熱遷移代表著快速、對生產服務影響最小、風險小；而冷遷移代表著低效、影響服務、有失敗的風險。

說到這可能還是一頭霧水，我們通過圖片來看下冷遷移和熱遷移的區別。

有A、B兩臺例項，A使用本地磁碟，B使用雲盤

當例項出現故障需要遷移時A、B的策略是有區別的。

基於Image做例項建立的技術目前已經非常成熟，特別是對公共映象例項平臺都有預熱池的概念，所以一旦發生故障我們最頭疼的部分就是故障例項內的資料如何解決。

先看A：

新啟動的例項A+需要完成磁碟內容的拷貝，可能直接對拷，也可能先拷貝到雲盤後再從雲盤拷貝回來，總之這一步時間會很久，而且有失敗的可能。

再看例項B：

可以將原例項的雲盤直接掛載給新啟動的例項B+，效率高，風險小。

上述A使用的是冷遷移，B使用的熱遷移，可以看得出網盤在熱遷移中的決定性作用。

InstanceType的選擇：

我們在購買雲實例時會困擾自己選擇哪種機型，這是跟你的應用場景有關的，本文再詳細介紹下InstancType相關的知識點。

首先，最容易被忽視的一點是，每個Region的可用機型可能是不一樣的！！

原因有很多，可能是售罄了，可能是硬體迭代，總之對於API呼叫的場景一定要根據服務端提供的介面確認下你想要的機型在該區域是否還存在。

InstanceType的命名規則是：{應用場景}{幾代}.{規格}，例如C4.large

{規格}最好理解，代表你雲實例面板的物理效能，CPU核數、記憶體大小等，會按照英文的意義從小到達nano、micro、small

{幾代}也好理解，硬體也在升級，同等場景和規格下，代數越高代表技術越先進，效能也會略好，一般體現在cpu和記憶體的頻率上。

前兩個還算好理解，{應用場景}有點複雜，雲平臺根據客戶的需要把例項分為標準型、記憶體密集型、計算密集型、儲存密集型和網路密集型等場景。

標準型，屬於家庭式或者平衡型的型別，廠家會按照常用的比例為我們配置CPU、記憶體、磁碟等硬體。

計算密集型，一般用於企業的web應用等需要大量運算的場景，廠商會側重加強CPU的運算能力和穩定性。

記憶體密集型，一般用於Redis伺服器這類記憶體資料庫場景，對記憶體的分配和拷貝能力要求較高。

儲存密集型，一般用於MySql、HBase、ElasticSearch這類場景，對磁碟的吞吐、IOPS、時延、容量要求較高。

網路密集型，這類場景比較複雜，像以遊戲伺服器為代表的TCP長連線場景，以彈幕、http請求為代表的TCP短連線場景，除開長短連線這個維度，還有內網和公網這個維度也有網路上需要優化的空間。

本文這裡介紹的InstanceType只針對應用伺服器的選型，隨著AI技術的發展雲廠商們也推出了針對於深度學習的GPU機型。