1. AWS AutoScaling簡介
AutoScaling是AWS的一個重要服務，用來彈性的自動創建（ScaleUp）或者刪除（ScaleDown）EC2虛擬機，並且Scale的策略完全是用戶自定義的、或者是基於虛擬機健康狀態檢查結果、或者是按照計劃來實施Scale策略。
例如，考慮如下的業務場景，系統部署在EC2虛擬機上，所有任務分發均是通過AWS SQS來完成的，即請求按照特定格式發送到SQS指定隊列中，而EC2虛擬機上運行的系統從這個隊列讀取消息來運行任務。
藉助於AutoScaling，我們可以簡單的設置下面的伸縮策略：
1）確保至少有2臺EC2虛擬機正常提供服務；
2）ScaleUp：當SQS隊列中的消息個數超過20個的時候，就自動創建一臺或者多臺虛擬機，ScaleUp策略執行之後CoolDown一段時間再次檢查ScaleUp策略。當然創建該虛擬機的鏡像需要提前預製好，確保虛擬機創建之後OS運行的時候，我們的業務系統能夠自動運行起來。
3）ScaleDown：當SQS隊列中的消息個數小於20個的時候，自動刪除一臺虛擬機。
說明：上面的例子只是簡單的演示了AutoScaling的使用方式，可以藉助於CloudWatch來實現更強大更精細的AutoScaling配置。
更多介紹詳見AWS AutoScaling官方文檔：http://aws.amazon.com/autoscaling/
2. AWS AutoScaling的ScaleDown策略存在的問題
對於一般的同步請求業務系統而言，AutoScaling的功能是比較強大的，藉助於它，我們可以方便的實現業務的彈性自動伸縮。
但是，在使用過程中，發現AWS的AutoScaling（下文簡稱AmazonAS）存在一個問題，就是對於長時間運行的業務而言，比如一個視頻轉碼請求需要幾個小時才能處理完的，任務運行的時間幾乎和視頻時長一樣長。在這種情況下，AmazonAS的ScaleDown策略就會出現一個問題：如果在一個虛擬機正在運行任務的時候，AmazonAS根據CloudWatch數據觸發了ScaleDown策略，那麼很有可能會刪除掉該虛擬機，從而引起業務數據丟失或混亂。由此可見，AmzonAS並不適合於我們的業務特性，因此有必要仿照AmazonAS來實現一套定製化的AutoScaling來滿足我們的業務需求。
3. 解決方法
3.1 ScaleUp策略
基本類似AmazonAS的ScaleUp策略來實現，或者說是它的簡化版本。 通過監控SQS中指定隊列的消息個數來自動新建一定數量的虛擬機，來運行隊列中的任務消息，新建虛擬機的同時發送郵件到指定郵箱。
3.2 ScaleDown策略
由上文介紹的AmazonAS存在的問題或不足，我們就不能簡單的根據SQS中消息個數來刪除虛擬機了。我們的策略是讓虛擬機內部自動根據任務運行情況來自我刪除。
實現方式如下： 在虛擬機內部預製好檢查任務運行狀態（我們是通過檢測日誌來實現的）的腳本，如果發現系統空轉一段時間之後就執行關機命令，進而觸發AWS EC2虛擬機的Shutdown Behavior進行自我刪除。備註：這就要求創建虛擬機的時候設置Shutdown Behavior爲Terminate，即刪除。
3.3 流程步驟
簡要的流程圖如下所示：
1） 首先，AutoScaling啓動一個線程，進入循環；
2）在當前循環週期內，根據SQS中消息個數進行ScaleUp策略檢查，如果滿足策略條件，則調用EC2創建虛擬機的API創建一臺或者多臺虛擬機，並將Shutdown Behavior設置爲Terminate，虛擬機參數會在AutoScaling中進行預先配置。如果創建了虛擬機則會根據預製的郵件列表發送郵件通知，並且CooleDown一段時間。
3）在當前循環週期內，ScaleUp完成之後就進行ScaleDown策略檢查，真正運行ScaleDown策略的機制是在EC2虛擬機裏面通過cron任務來執行的，在AutoScaling中僅僅是判斷哪些虛擬機在當前循環週期內被刪除了，如果檢測到有虛擬機被刪除掉，則發郵件通知。
4）ScaleUp和ScaleDown在當前週期全部執行完畢之後，等待一段時間，然後重新進入下一次循環週期。
3.4 代碼實現
使用Java開發了該系統，並且運行在tomcat容器中，所有代碼和腳本全部公開在github上，地址爲：https://github.com/yuanhuan2005/autoscaling.git。
3.4.1 代碼結構
代碼位於autoscaling/src/main/java/com/tcl/autoscaling下面：
awsec2 #EC2創建新的虛擬機接口 awsses #SES接口，用於發郵件 awssqs #SQS接口，用於操作SQS中的消息 common #公共方法 listener #監聽器 mail #發郵件接口 transcode #執行業務Scale的核心代碼 |
3.4.2 配置文件
配置文件位於autoscaling/src/main/resources/autoscaling.propertites中：
| awsAccessKeyId=YOUR_ACCESS_KEY #AWS的access key id awsSecretAccessKey=YOUR_SECRET_KEY #access key對應的secret key queueMessageCheckDuration=600 #隊列中的消息檢查週期，單位：秒 transcodeMonitorQueueURL=https://sqs.us-east-1.amazonaws.com/xxxxxxxxxxxxx/transcoderQueue #隊列地址 transcodeMonitorQueueTotalNumberThreshold=1 #隊列消息個數的閥值 transcodeInstanceLanchNumber=1 #啓動的虛擬機個數 transcodeImageIdToLanchInstances=ami-88888888888 #啓動虛擬機使用的鏡像id transcodeRegion=us-west-2 #虛擬機在哪個region創建 transcodeAvailabilityZones=us-west-2a,us-west-2b,us-west-2c #虛擬機在上面的region中哪個可用分區中創建 transcodeMaxInstancesNum=20 #創建虛擬機的最大個數 transcodeInstanceType=m1.xlarge #虛擬機規格 transcodeKeyPair=transcoder_for_asg #虛擬機keypair，用於ssh登錄 transcodeSecurityGroupId=sg-f321c896 #虛擬機所在的安全組 transcodeInstanceName=test #虛擬機名稱，便於管理 transcodeCoolDownTimeInSeconds=1200 #cooldown時間，單位：秒 [email protected];[email protected];[email protected] #email列表，多個email用分號分割 |
3.4.3 shell腳本
在EC2虛擬機中需要安裝如下的腳本，默認安裝路徑是/home/ec2-user/bin/，如有變化可對應修改。
腳本解釋如下：
check_dispatcher_status.sh #檢查運行狀態。如果空轉，則將idle_number的數字加1，當idle_number達到配置的上限時執行關機命令進行自我刪除；如果沒有空轉即正在運行任務，則將idle_number清零，等待進入下次檢查週期。 idle_number #記錄空轉次數的文件 dispatcher #註冊爲系統服務，以便可以用service命令進行管理，文件路徑：/etc/init.d/dispatcher restart_tomcat.sh #重啓tomcat的腳本 start_tomcat.sh #啓動tomcat的腳本 status_tomcat.sh #檢查tomcat運行狀態的腳本 stop_tomcat.sh #停止tomcat的腳本 |
這些腳本的調用關係見下圖所示：
![clipboard[1]](http://s3.51cto.com/wyfs02/M02/6C/25/wKiom1VAmlyiju0NAAGfLU94cOQ900.jpg "clipboard[1]")