在我們討論彈性伸縮內容之前，我們先討論下與之相關的知識點—什麼是垂直擴充套件和水平擴充套件。
垂直擴充套件是指提公升單個節點的自身的處理能力，比如通過公升級節點的cpu，記憶體等硬體，這種通過公升級原有的伺服器或將其更換為更強大的硬體來提公升單個節點的處理能力稱為垂直擴充套件；比如對應aws，就是通過改變或提公升例項的型別和大小使其有更強的計算等能力，比如當工作負載增加時，將處理負載的例項從m5.large公升級為m5.24xlarge, 這就是垂直擴充套件。需要注意垂直擴充套件是有上限的，上限取決於aws提供的最大例項的大小。
那什麼是水平擴充套件呢？
水平擴充套件指的是通過增加更多的節點來分散處理工作負載，從而實現節點計算等能力的擴充套件。對應aws舉例，比如我們之前處理某個工作負載使用了一台m5.large，當這個工作負載增加後，我們不是像垂直擴充套件去公升級硬體，而是通過增加多台m5.large例項處理工作負載的方式就是水平擴充套件。 當然，水平擴充套件對您的應用的架構設計是有要求的。另外水平擴充套件理論上是可以無限擴充套件的，除非將aws的所有例項都用完了。可以通過不斷的新增例項，分散工作負載從而提高處理能力。
那麼問題來了，能不能將水平擴充套件自動化執行呢？當工作負載高的時候自動進行架構的水平擴充套件，通過新增更多的例項加快處理工作負載；而當工作負載恢復正常水平時在自動進行縮減例項數量以節省成本呢？當然是可以的，這就是我們接下來要討論的彈性伸縮的內容。
我們先看乙個案例，某公司開發了一款線上辦公系統並已對外提供服務，左圖是這套系統一周中每一天所使用的計算容量。
通過圖中可以看到，因為是辦公系統，週六和週日大部分公司放假訪問量不高，所以使用的計算容量很低；周二和週三訪問量最高，大概比週末高出6，7倍。
按照傳統做法，可通過兩種方式為線上辦公系統這些容量變化做好規劃。第一種是新增足夠多的伺服器，以便線上辦公系統始終具有足夠的容量來滿足需求。週三系統的訪問量最高，就按照週三的最大容量準備伺服器，如果週三的訪問量需要10臺伺服器提供服務，就會部署10臺伺服器。但是，這種做法的缺點是線上辦公系統在某些天並不需要這麼多容量。比如週末可能只需要1，2臺伺服器就可以滿足系統需求。剩下的額外容量閒置不用，實際上提高了系統執行的成本。
第二種做法是只準備線上辦公系統平均需求所需的容量。比如就準備6臺伺服器，可以滿足一周中的4天的計算容量需求。這種做法成本更低，因為不用購買僅僅偶爾使用到的伺服器。然而，這樣做的風險是：當對系統的需求超過其可用容量時，比如尤其是周二和週三，可能造成糟糕的客戶體驗。
前面的兩種方式都不是太理想，要麼會浪費資源提高執行的成本；要麼就是某些高峰時間點可能會給使用者造成糟糕的使用者體驗。
那有沒有更好的做法呢？答案是肯定的，通過設計使我們系統的容量可以彈性伸縮。對應aws ec2，通過使用 amazon ec2 auto scaling，可以僅在需要時才向應用程式新增新例項，並在不再需要這些例項時終止它們，因此只需在使用時為使用的例項付費。
比如對應我們這個案例，通過對auto scaling的配置，週三的時候辦公系統訪問量較大，auto scaling就會自動增加新的例項處理負載；而周四的時候系統訪問量比週三少了一半，auto scaling會自動終止一些例項只保留滿足系統需要的例項數量。這樣的話我們就有了乙個具有成本效益的架構，可在儘量減少支出的同時提供最佳客戶體驗。
ec2 auto scaling可根據業務需求和策略設定擴充套件選項，比如配置擴充套件策略在業務需求增長時自動為您增加例項以保證計算能力，在業務需求下降時自動減少例項數量以節約成本。
在認證考試中，經常會有一些題幹描述的場景為應用系統 一周中不同天 或者 一天的不同時間段 業務量會有波動，有訪問量波峰也有波谷，如一天的不同時間段，晚上高峰時間段的業務量可能最高，然後凌晨之後業務量可能會減少，問如何設計能夠滿足業務波峰時的容量並兼顧成本效益，這個時候就要注意很可能是auto scaling相關的考點。
當然auto scaling不僅適合業務量不斷波動的應用程式，同時也適合業務量穩定的應用程式，這一點我們後面會討論。
我們現在假設要通過ec2 auto scaling，實現彈性伸縮，白天執行乙個例項提供服務，在晚高峰時，執行3個例項提供服務。
可以通過ec2 auto scaling，配置擴充套件策略，然後通過定義auto scaling組平均 cpu 使用率指標實現彈性伸縮。
我們可以定義規則，當auto scaling 組的平均 cpu 使用率大於70%時，新啟動兩台例項處理**負載；然後在配置乙個規則當auto scaling 組的平均 cpu 使用率小於25%時，終止2個例項。
這樣的話，在白天**訪問量不是很高的時候，只會有1臺例項提供**服務，而到晚上19點後訪問量上去後，當cpu使用率大於70%時，auto scaling會啟動兩台新例項處理**負載，加上之前的1臺例項，一共3臺例項提供**服務；而當22點之後，訪問量下去之後，如果平均cpu使用率小於25%，auto scaling就會終止2臺例項，繼續保持最小容量1臺例項執行。
這樣的話，我們通過auto scaling服務，在**訪問量高的時候一共3臺例項處理負載，提公升了**使用者的體驗；當訪問量降低時，只保留1臺例項處理負載，節省了成本。
我已經建立好了auto scaling組，as-test-group為我們已經建立的auto scaling組。
我將組的最小容量配置為1，最大容量配置為3 。
最小容量是指確保始終執行一定數量的例項，按照前面我們的案例，我設定的是1就代表無論怎麼縮減這個auto scaling組始終會保持最少執行1臺例項對外提供服務。如果設定為5呢？就代表始終會保持最少執行5臺例項。
最大容量是指最大限制允許 auto scaling 根據需要向外擴充套件例項數，以滿足增長需求。我們設定的是3，就代表這個auto scaling組最多可擴充套件為3個例項。
然後參照前面我**的案例，我為這個auto scaling組配置了擴充套件策略，策略的內容當auto scaling組的平均 cpu 使用率 大於等於 70%時新增2臺例項；當auto scaling組的平均 cpu 使用率 小於 25% 刪除2臺例項。
這個平均 cpu 使用率 大於等於 70%以及小於25%實際上是通過我在cloudwatch中配置的警報，然後將cloudwatch警報與當auto scaling組相關聯，這樣當 cloudwatch 警報處於 alarm 狀態時，auto scaling組就會執行相應的新增和刪除例項的動作。
我們到cloudwatch控制台看下。
我們在前面auto scaling組關聯的兩個警報實際上是在cloudwatch這裡定義的，可以看到警報的條件， cpu 使用率 大於等於 70%以及小於等於25%，然後配置auto scaling組將其相關聯，當對應 cloudwatch 警報處於 alarm 狀態時，auto scaling組就會執行相應的新增和刪除例項的動作。
關於auto scaling的具體配置我們會在後面的課程詳細討論和實操演示，所以學友們先做了解，後面的課程我們會介紹auto scaling的重要知識點，對建立和配置auto scaling做實操的演示。
好，以上就是我們今天的課程內容。
希望此系列教程能為您通過 aws解決方案架構師認證 professional 認證考試帶來幫助，如您有任何疑問
**：www.iloveaws.cn
彈性伸縮問題
問題 彈性伸縮出來的伺服器主機沒法自己定義,會導致tomcat啟動錯誤 linux的開機啟動順序概述 1 載入bios硬體資訊,並獲取第乙個啟動裝置的代號 2 讀取第乙個啟動裝置的mbr的引導引導程式的啟動資訊 3 載入核心作業系統的核心資訊,核心開始解壓縮,並且嘗試驅動所有的硬體裝置 4 核心執行...
彈性布局（伸縮布局）
彈性布局 伸縮布局 僅僅是網頁布局中的一種新的解決方案。應用場景 當頁面 現多個盒子一行顯示時，可以考慮使用彈性布局 如 兩端對齊，中間自適應居中，兩行屬性即可實現 display flex justify content space between 問 為什麼彈性盒子中的元素會一行顯示？1.在彈性...
彈性伸縮的基本概念
彈性伸縮自動為您調整彈性計算資源大小，以滿足您業務需求的變化。彈性伸縮根據您設定的伸縮規則，在業務需求增長時自動為您增加ecs例項以保證計算能力 彈性擴張，在業務需求下降時自動減少ecs例項以節約成本 彈性收縮。彈性擴張 當您的業務公升級時，彈性伸縮為您自動完成底層資源公升級，避免訪問延時和資源超負...