一名網工的情懷

從初出茅廬到資深網工也用了十年時間吧，在專業的運維公司呆過、在政府外包單位幹過、再到生產型企業最後在化工行業。有過淚、有過痛，輾轉多年見過形形式式的人和事一轉眼又過去了數年，從去年開始暗下決心開始進行新知識的學習和儲備學習了Cisco運營商，學習了OCP。直到有一天聽說了阿裏雲大學才知道原來雲計算還可以這麽玩……
這段時間在阿裏雲計算的班教、導師指導下終於完成了教學內容和考試，在此特別感謝雲大學裏的那些認真負責的教輔人員感謝他們半夜十一點還在為我們解惑，因此才有了以下的文章為大家奉獻上希望同行的一起交流指正未入行的也一起了解學習一下，因為剛接觸雲計算不久如有表達錯誤還請多多擔待。

連載雲計算文章主題

後續的連載如下
1、 無業務不伸縮之一，雲計算有ESS
2、 無業務不伸縮之二，雲監控搭配雲計算ESS
3、無訪問不均衡，雲計算有SLB
4、無互動不加速，雲計算有CDN
5、無對像不存儲，雲計算有OSS
6、無文件不存儲，雲計算有”文件存儲”
7、淺談彈性IP的運用
這些文章將會在接下來的一段時間向各位一一呈現出，本期第一篇“無業務不伸縮一，雲計算有ESS”

進入主題。第一篇：無業務不伸縮一，雲計算有ESS

前言

無論是傳統的自建IDC還是當今流行的雲上IDC都避免不了在業務突發增長時對可用行和穩定性的追求，對於雲來說有很多技術手段來控制這些而對於自建IDC來說這是他們的心病與痛因為企業不會平白無故的采購很多可能用不上的服務器閑置在機櫃上。

企業常見的服務器部署如下：

這是很多企業在機房構建服務器的一個常見案例，這樣的架構對於小企業來說是沒有什麽問題的，當我們服務器不夠用的時候再買就是了也不在乎這麽點時間，可是如果對於依靠互聯網增值為業務的公司來說這種情況是不允許出現的吧，時間就是金錢啊，耽誤我掙錢，哼！那好你自己看著辦吧。沒辦法老板就是這麽難侍候既不想投入高成本又想在業務上加速發展，那我們到底有沒有這麽一樣技術即可以實現業務突發時自動增加可用服務又能夠在業務低峰時減少可用服務來降低成本呢？

ESS閃亮登場

Ess(Elastic Scaling Service)顧名思義，彈性縮放是阿裏雲的一項技術可以用來自動增減服務器、還可以在服務器出現健康問題是提供自愈功能等的一種服務方式。

請看下圖：

ESS使用場景

那麽在什麽樣的情況下我們才會需要使用ESS技術呢，比如說遊戲服務器、淘寶寶、這些訪問量波動比較大的網，可能前一秒有1000萬人在訪問下一秒就突破2000萬人次，在這樣巨大的訪問量下就需要使用這樣的技術了對吧，總不可能你讓我一臺一臺的手工上服務器吧要這樣的話那就不如關門大吉了。

ESS技術演示
我們以一臺WEB服務器來做下簡單運用演示，首先我們先創建一臺網站服務器（僅僅用來演示）ip為47.101.181.236，並訪問一下頁面是否正常。

好的一切正常，接下來我就應該先給這臺服務器做一個鏡像這樣ESS之後會調用這個鏡像來做彈性伸縮，我們在創建自定義鏡像中填入鏡像名稱、寫好備註後直接點擊創建。

創建好了之後我們來到 “彈性伸縮”中開始創建伸縮組在這裏按你的實際需求填寫，我這裏設置“伸縮最大實例數”為2臺，“伸縮最小實例數”為0臺，冷卻時間默認，網絡類型選擇專有網絡，交換機也選擇專有網絡中的交換機，其它如不需要改動就保持默認。

接著我們選擇好合適的服務器配置方案，操作系統為自義定的鏡像文件，選擇分配公網IP地址，最後輸入伸縮配置名稱並創建。

然後我們在伸縮管理控制臺中選擇ECS實例列表-添加已有實例中將實例添加進去，接著在伸縮規則中創建規則，填入規則名，調整至2臺並確定。接下來我們選擇“定時任務”同樣的方法先創建名稱然後選擇你需要進行彈性擴充的時間和我們建好的伸縮組和規則並確認。

下面我們測試在規定的時間以規定的規則來看彈性伸縮是否正常生效，當第二臺服務器自動創建出來後我們同樣可以用不同的IP來訪問網站，先看狀態：

未生效前的狀態：可以看到只有一臺服務器在工作

生效後的狀態：可以看到已經有兩臺服務器在工作了

我們再回到ECS控制臺中查看一下服務器的狀態：可以看出在之前的實例中又多出一臺實例由此說明操作都是正常的，我們可以用新生成的服務器IP來訪問一下網站是否正常，在IE輸入106.14.216.94 好了看來一切是正常的。

總結

在這篇文章中，我們一起討論並學習了什麽是ESS和在什麽情況下使用ESS，最後展示了如何配置ESS。
總結如下：

1.ESS是彈性的服務器伸縮服務，我們可以想像成彈簧有張有弛。
2.ESS可以很好的保障因突發性訪問所產生的服務器壓力過大問題。
3.ESS具有通俗的使用特點，不需要有過多的操作技術簡單實用。

無業務不伸縮，雲計算有ESS