????????器大活好趁啸，能大能小能伸能縮：AutoScaling
????????我們可以先假設(shè)一個應(yīng)用場景舶斧，比如說我啟動了一個實例桃焕，實例上搭建了一個網(wǎng)站，半夜十二點的時候捧毛，假設(shè)只有幾十人訪問观堂，那這時候只用這一個實例就可以承擔(dān)這幾十人訪問的負載，而在白天呀忧，或是晚上七八點的時候訪問的人會特別多师痕，這一個實例可能就承擔(dān)不了這么多的負載，我需要多啟動幾個實例而账，利用cloudwatch監(jiān)控實例的運行狀況胰坟，當(dāng)實例的cpu利用率過高的時候就開始啟動實例，可是又不能人為地啟動實例泞辐，因為你不知道什么時候流量會增多笔横，這時候就需要利用Autoscaling讓系統(tǒng)自動地為我們啟動實例，而當(dāng)cpu利用率變低的時候咐吼，可以讓Autoscaling為我們終止實例吹缔，利用Autoscaling可以打造自動擴展收縮彈性系統(tǒng)。
????????Auto Scaling能夠根據(jù)需求自動增加或減少啟動實例的數(shù)量锯茄，來確保系統(tǒng)運行所需要的實例數(shù)量厢塘，在需求高峰時Auto Scaling自動增加EC2實例，確保性能穩(wěn)定肌幽，在需求降低時自動減少EC2實例來降低成本晚碾。
????????Autoscaling中還有兩個概念需要理解：
????????啟動配置和Autoscaling組。
????????啟動配置是用于AutoScaling啟動EC2實例的模板喂急。在這里可以指定實例的信息格嘁，例如Amazon系統(tǒng)映像(AMI)的ID、實例類型廊移、安全組和綁定的角色等糕簿。同時在這里可以配置監(jiān)視EC2時使用CloudWatch詳細監(jiān)控涣易，還是基礎(chǔ)監(jiān)控。默認情況下冶伞，當(dāng)手動生成啟動配置的時候新症，是使用的基礎(chǔ)監(jiān)控，當(dāng)利用CLI或者API生成啟動配置的時候响禽，默認使用詳細監(jiān)控徒爹。不同的AutoScaling組可以使用相同的啟動配置，但只能使用一個啟動配置芋类。在啟動配置被生成后隆嗅，是不能被修改的，如果業(yè)務(wù)需要使用新的啟動配置侯繁，只能重新生成新的啟動配置胖喳。當(dāng)使用新的啟動配置時，新生成的實例會使用新的啟動配置中配置的參數(shù)贮竟，但是已有的丽焊，使用舊的啟動配置生成的實例不會受到影響。
????????Autoscaling組中包含的概念比較多咕别。它是ec2實例的集合技健，Autoscaling組可以根據(jù)指定的條件自動擴展實例數(shù)量，或減少實例數(shù)量惰拱，這種維護實例數(shù)量的功能是Autoscaling服務(wù)的核心功能雌贱。
? ? ? ? ? ? ?定義了啟動EC2實例時，使用哪個啟動配置偿短。
? ? ? ? ? ? ?定義了啟動AutoScaling組后初始實例數(shù)欣孤，最小及最大實例數(shù)。初始實例數(shù)是指系統(tǒng)在任何時候都至少擁有的實例數(shù)昔逗。這里定義的最小及最大是極限值降传，即自動啟動EC2實例的時候，不能超過這里定義的范圍纤子。
? ? ????? ? ?定義了在哪個VPC的哪個子網(wǎng)中啟動實例（AutoScaling組不可以跨VPC搬瑰，即不可以跨區(qū)域，但是可以跨某個VPC下的多個子網(wǎng)）控硼。
?????????????是否配合ELB使用。
? ? ? ? ? ? 但配合ELB使用時艾少，通過健康檢查※卡乾，判斷組中的實例是否是健康的，如果不是的話缚够，AutoScaling會將不健康的實例終結(jié)掉幔妨，然后重新啟動新的實例鹦赎。（自動愈合，實例的個數(shù)）误堡。
?????????????Scaling策略古话，定義了在哪種情況下需要增加實例，在哪種情況下需要減少實例锁施。
?????????????SNS通知陪踩，當(dāng)AutoScaling組內(nèi)的實例出現(xiàn)某些情景(啟動，終結(jié)悉抵，啟動失敗肩狂，終結(jié)失敗)時可以通過SNS郵件通知用戶。
? ? ? ? ※健康狀況檢查類型：
????????Auto Scaling中實例的運行狀況有正常和不佳兩種姥饰。一個實例在通過初始運行狀況檢查后傻谁，將被Auto Scaling視為正常。Auto Scaling定期對Auto Scaling組中的實例執(zhí)行運行狀況檢查并標(biāo)識所有運行狀況不佳的實例列粪。Auto Scaling在將一個實例標(biāo)記為運行狀況不佳后审磁，會計劃替換該實例。而確定實例的運行狀況可以使用兩種檢查：一個是ec2實例提供的狀態(tài)檢查岂座，一個是負載均衡器提供的運行狀況檢查力图。
? ? ? ? Ec2實例的狀態(tài)檢查分為兩種：一個是系統(tǒng)狀態(tài)檢查，一個是實例狀態(tài)檢查掺逼。
? ? ? ? ①系統(tǒng)狀態(tài)檢查吃媒，檢查的是實例所在的aws系統(tǒng)，由于是系統(tǒng)問題吕喘，所以一般情況下赘那，如果系統(tǒng)出了問題，我們只能等待aws來修復(fù)氯质，可能導(dǎo)致系統(tǒng)檢查失敗的原因有：
????????????????網(wǎng)絡(luò)連接丟失
????????????????系統(tǒng)電源損耗物理主機上的軟件問題物理主機上影響到網(wǎng)絡(luò)連接狀態(tài)的硬件問題
????????不過如果我們的實例利用的是ebs卷的話募舟，我們可以通過停止并再次啟動實例來解決系統(tǒng)問題，因為再次啟動之后闻察，ec2實例會在新的物理主機上啟動拱礁，所以系統(tǒng)問題應(yīng)該會被解決掉，不過如果實例利用的是實例存儲卷的話辕漂，只能把實例終止掉呢灶，再啟動新的實例，因為把利用實例存儲卷的實例停止后钉嘹，實例中的數(shù)據(jù)都會丟失鸯乃，所以只能啟動新的實例替換原來的。
? ? ? ? ②實例狀態(tài)檢查跋涣，監(jiān)控的是各個實例的軟件和網(wǎng)絡(luò)配置缨睡。如果實例狀態(tài)檢查失敗鸟悴，一般需要自行解決問題(例如，重啟實例或更改實例配置)奖年。
????????可能導(dǎo)致實例狀態(tài)檢查失敗的原因有：
????????系統(tǒng)狀態(tài)檢查故障網(wǎng)絡(luò)或啟動配置不正確內(nèi)存耗盡文件系統(tǒng)損壞內(nèi)核不兼容细诸。
????????再看負載均衡器提供的運行狀況檢查：為了查明EC2實例的可用性，負載均衡器會定期發(fā)送ping陋守、嘗試進行連接或者發(fā)送請求來測試EC2實例震贵。這些測試稱為elb的運行狀況檢查。兩者檢查的對象是不一樣的嗅义，ec2檢查的是這個是實例是否在正常運行屏歹，而elb檢查的是實例上的應(yīng)用是否在正常運行，所以當(dāng)AutoScaling和ELB配合使用時之碗，比較推薦使用elb的狀態(tài)檢查來確定這個實例該不該被替換蝙眶。
? ??????運行狀況檢查寬限期，是為了給實例提供足夠的預(yù)熱時間褪那，默認系統(tǒng)會等300秒后才對EC2和elb進行狀態(tài)檢查以及運行狀況檢查幽纷。
? ??????實例保護，如果啟用了實例保護博敬，則這個autoscaling組中啟動的實例在scale in的時候友浸，也就是當(dāng)系統(tǒng)想要終止我們的實例的時候，是終止不了的偏窝，啟用了實例保護之后收恢，組中所有的實例都啟用這個屬性，從而保護不被終止祭往，當(dāng)然這個屬性也可以單獨對某個實例進行設(shè)置伦意，比如autoscaling組中不設(shè)置，在其中啟動的某個實例上啟用這個設(shè)置硼补，來保護該實例驮肉。
????????配置擴展策略：這里有兩個選項：
? ? ? ? ? ? ①保持初始大小暇赤，利用這個可以保持Auto Scaling組中的實例數(shù)量辅辩，Auto Scaling組首先啟動我們剛才配置的最小數(shù)量的EC2實例。為了保持這個數(shù)量的實例月腋，Auto Scaling對Auto Scaling組內(nèi)運行的實例執(zhí)行定期運行狀況檢查褪储。如果發(fā)現(xiàn)實例運行狀況不佳卵渴，它將終止該實例，并啟動新實例乱豆，從而保證autoscaling組中的總數(shù)量不變奖恰。
? ?????? ②使用擴展策略調(diào)整此組的容量宛裕，這里就是配置當(dāng)系統(tǒng)的某個數(shù)據(jù)滿足某個條件時瑟啃，讓系統(tǒng)自動地增加或減少ec2實例數(shù)量來滿足需求。這里還可以設(shè)置最大和最小值揩尸，系統(tǒng)會在這兩個數(shù)值之間啟動或終止實例蛹屿。
? ? ? ? ? ? ? ??使用擴展策略擴展autoscaling組的話，核心就是當(dāng)系統(tǒng)滿足一定的條件的時候岩榆，系統(tǒng)會自動地添加或者刪除實例错负。這里的條件需要在警報中生成。比如勇边，當(dāng)系統(tǒng)平均的cpu利用率連續(xù)5分鐘低于30%的時候犹撒，自動的刪除1個實例，同時生成一個警報粒褒，向sns的主題發(fā)送該信息识颊；或者當(dāng)系統(tǒng)平均的CPU利用率連續(xù)5分鐘高于80%的時候，要自動添加一個實例奕坟，同時生成一個警報祥款，向SNS的主題發(fā)送該信息。
????????????配置通知月杉，我們還可以當(dāng)這個組中的實例：啟動刃跛，終止，無法啟動苛萎，無法終止桨昙，發(fā)生這些動作變化的時候，發(fā)送信息到sns的主題腌歉，比如當(dāng)系統(tǒng)中新啟動了一個新的實例的時候蛙酪，有了這個配置通知，系統(tǒng)管理員就會收到SNS的通知究履。
????????Autoscaling組是可以進行編輯的滤否，但是啟動配置是無法進行編輯的，如果想要對啟動的ec2實例進行更改最仑，只能再生成一個新的啟動配置藐俺，然后在autoscaling組這里對啟動配置進行更改。
? ? ? ? 這里還有一個比較重要的概念：AutoScaling CoolDown冷卻時間泥彤。當(dāng)系統(tǒng)的CPU急速的被消耗的時候欲芹，CloudWatch會檢測到CPU的變化，從而促使AutoScaling來根據(jù)設(shè)置的擴展策略自動的添加實例個數(shù)吟吝。但是從實例的啟動到正常運行是需要一定的時間的菱父，比如該實例上需要配置很多軟件，那么可能就會花很多時間，如果在這個實例還沒有正常運行的時候浙宜，那么CPU的利用率還是比較高的狀態(tài)官辽，這時CloudWatch就會認為現(xiàn)在的系統(tǒng)仍然需要更多的實例，CloudWatch的警報就會被觸發(fā)后粟瞬，繼而又會添加新的實例同仆。問題就出現(xiàn)了，CloudWatch沒有等到被添加的實例正常運行裙品，就又添加新的實例了俗批，這時候可能就會出現(xiàn)浪費實例的情況。有了冷卻時間之后市怎，AutoScaling在啟動實例后岁忘，就會等待一段時間，這段時間內(nèi)区匠，CloudWatch不會被觸發(fā)干像，擴展策略引起的擴展活動就會被暫停，當(dāng)冷卻時間過后辱志，新添加的實例也正常工作了蝠筑，然后擴展活動會被恢復(fù)，CloudWatch再被觸發(fā)的話揩懒，新的實例就會被添加什乙，同時冷卻時間會再次生效。創(chuàng)建AutoScaling組的時候已球，默認會應(yīng)用冷卻時間（默認300秒）臣镣。
? ? ? ? 總結(jié)：當(dāng)使用AutoScaling的時候，它會使用我們配置好了的啟動配置和AutoScaling組智亮，在某個VPC（自定義）下的某些子網(wǎng)（自定義）中啟動在AutoScaling組中定義的初始實例數(shù)忆某。A：如果不讓系統(tǒng)調(diào)整實例個數(shù)，那么無論發(fā)生什么情況阔蛉，系統(tǒng)都會盡可能的運行固定個數(shù)的實例弃舒，比如說我們的Autoscaling組中設(shè)置了初始所需要的實例個數(shù)是2，那么這時候我們會有兩個實例被自動地啟動状原，最初啟動的實例的個數(shù)就是這個所需的個數(shù)聋呢，如果我們把一個實例刪除了，或者是運行狀況檢查失敗了它還會啟動新的實例颠区，來保證系統(tǒng)中有我們所需個數(shù)的實例削锰，這個就是自我恢復(fù)功能，像金剛狼一樣毕莱。B：如果使用擴展策略來調(diào)整系統(tǒng)中的實例個數(shù)器贩，那么系統(tǒng)會根據(jù)我們設(shè)置的條件颅夺，自動地增加或者減少系統(tǒng)中的實例個數(shù)。比如當(dāng)系統(tǒng)中的CPU利用率超過80%蛹稍，要自動的增加2個實例吧黄，當(dāng)系統(tǒng)中的CPU利用率低于30%，要自動地減少2個實例稳摄，同時冷卻時間會生效稚字，但是無論系統(tǒng)怎樣自動添加或減少實例的個數(shù)饲宿，都不會超過設(shè)置的最小和最大實例個數(shù)厦酬。同時還可以當(dāng)實例的個數(shù)或者狀態(tài)發(fā)生改變的時候，用設(shè)置的SNS通知系統(tǒng)管理員瘫想。
