今天，收到一封「搜狐雲景」送邀請碼的郵件，價值 200 rmb，立馬前往官網簡單瞭解一下，這個玩意兒是搜狐公司雲戰略的一個產品，一個 PaaS 平臺，簡單瞭解了一下特性：程序員
一、自由定製運行環境，這表示支持多語言環境，官網說支持 Python、Java、PHP、Lua、Ruby、Node.js 等語言，這對於我這 Python 碼農來講是利好啊，200 rmb能夠在這平臺跑跑博客了。post
二、靈活自定義調度，這表示用戶能夠根據自身應用規模設置調度規則，這種高大上的技術目前只在 AWS 的 E2C 上看到，且設置方面很是簡單，「搜狐雲景」做爲國內的 PaaS 平臺可以提供這個功能，實在點贊，可是不知道作的怎麼樣了。性能
開始體驗之自動調度——最小實例調度
按前文所述，比較對「自動調度」好奇，由於這關係到一個應用出現高峯時或出現單點故障時候，保障應用的高可用和高性能（水平擴容），所以開始了體驗之路，看看有哪些神奇的地方，關於怎麼建立應用，這篇文章介紹的很是詳細了，一切就緒後，「自動調度」中一個子功能的關鍵見下圖：測試
看來，「搜狐雲景」的「自動調度」參考了前輩 AWS 啊，上圖紅框標註的，根據個人理解，應該是應用的服務實例範圍，好比如今設置成，最小 1 個對外服務實例，最大 3 個服務實例，那麼果斷猜想「搜狐雲景」對用戶的應用高可用性保障（單點故障）的實現原理就是依靠最小實例數了，那麼怎麼自動完成的了？立刻體驗一把，這時 候我拖動滑動條，把最小實例數設置成 2，此時，個人對外實例數只有 1 個，以下圖：雲計算
過了大概 1分鐘之內，神奇事情發生了，個人對外實例數變成了 2 個，以下圖：spa
因而，我刪除一個實例（僞裝這個出現故障了），一樣也是在 1 分鐘之內幫我水平擴容到 2 個實例，看來「搜狐雲景」的單點故障功能正如上文描述，依靠最小實例數實現，保證用戶對外提供的服務不間斷。.net
爲了驗證這個功能，等待了 1 分鐘之內，很讓我吃驚的是，「搜狐雲景」提供了縮容服務，多餘的實例被自動卸載，由於我這個測試應用確定沒什麼訪問量，一個足以（雖然違背單點故障模式），那麼運行大於 1 個實例數確定是不經濟的行爲，雲計算的內涵不就是按需服務麼。資源
到此，「搜狐雲景」的「自動調度——最小實例數調度」仍是給我很是好的印象，這個功能對於用戶來講仍是比較友愛的，即知足了用戶應用的「單點故障功能」，又爲用戶應用提供最經濟實惠的計算資源「沒訪問量縮容之最小實例數，下降成本」。開發
開始體驗之自動調度——性能調度
做爲開發者，應該都對本身的應用的性能很是關心，由於涉及到用戶體驗，是產品的成功與否因素之一，那麼咱們的應用放到別人的 PaaS 平臺「搜狐雲景」託管，出現了性能問題，是否可以第一時間幫咱們自動處理這些事情？這又勾起了個人好奇心，「自動調度」的子功能以下圖：get
立馬建立一條規則，假如這個應用前 5 分鐘請求數達到 5 次就出現了性能問題（這個程序員是無證上崗的吧？）：
而後，開始連續訪問屢次應用，產生數據（知足本身建立的規則），看看這時候是否如官網描述的那麼神奇「用戶自定義規則」，當用戶的應用的性能達到瓶頸後， 自動幫咱們處理水平擴容這事兒。博主強 F5 刷新中，一共 10 次，看看效果怎麼樣，此時，博主已經作好準備去發微博，號召粉絲吐槽「搜狐雲景」吹牛，這個功能很差用，可是，可是神奇的事兒又發生了，「自動擴容」生效 了，且還發現一個亮點，「實時計算用戶應用的資源」，這功能太強大了，客官不用急，見下圖：
後記
到此，博主把國內 PaaS 平臺新秀「搜狐雲景」的「自動調度」功能都體驗了一番，不得不爲這個平臺的這個功能點贊，貨比三家（你懂的），在國內 PaaS 平臺中算是一匹黑馬。最後，微博上想吐槽這個功能也可恥的失敗了。但願這個 PaaS 平臺像官網文案那樣「更開放、更智能.....」走的更遠，固然能夠「更優惠」，咱們屌死用戶最愛的。