橫向擴展英文簡稱：Scale Out，全稱：Scale horizontally，橫向擴展，向外擴展。
縱向擴展英文簡稱：Scale Up，全稱：Scale vertically，縱向擴展，向上擴展。
不管橫向擴展還是縱向擴展都是一種架構的概念。
橫向擴展：比如可以增加一臺節點/機器 比如：mysql新增加一個從庫、tomcat新增加一臺機器;
縱向擴展：比如可以通過修改mysql參數內存比例、修改tomcat的線程數;
在體系結構中使用縱向擴展和橫向擴展
我們很少能準確預測系統負載。 面向公衆的應用程序可能會在普及程度和使用量上快速增長，內部應用程序也可能隨着業務增長而需要支持更大的用戶羣。 即使我們能預測負載，負載也往往不是恆定的。 零售商在節假日期間的需求更高，而體育網站在季後賽期間達到訪問高峯。
在本單元中，我們將：
- 定義縱向的擴展或縮減以及橫向的擴展或縮減
- 討論 Azure 可改善縮放功能的一些方法
- 看看無服務器和容器技術如何提高體系結構的縮放能力
什麼是縮放？
當我們瞭解如何增加或降低應用程序的計算容量和相對成本時，定義兩個關鍵概念非常重要：“縮放”和“資源”。
- 縮放是管理資源以幫助應用程序滿足一組性能要求的過程。 有太多資源爲用戶服務時，將無法有效地使用這些資源，並且會浪費資金。 可用資源太少時，應用程序的性能可能會受到不利影響。 目標是要在優化成本的同時滿足你定義的性能要求。
- “資源”可以指管理和運行應用程序需要的任何內容。 虛擬機的內存和 CPU 是最明顯的資源，但某些 Azure 服務可能會要求考慮帶寬或抽象，例如 Azure Cosmos DB 請求單位 (RU)。
假設應用程序需求不變，很容易預測所需的適當資源量。 但是在現實中，應用程序的需求隨時間的推移而變化，因此預測所需的適當資源量較爲困難。 如果幸運的話，這種變化是可預測或週期性的，但這並非所有場景的典型情況。 理想情況下，你希望預配適當數量的資源來滿足需求，然後根據需求變化調整數量。
在本地場景中（即你購買和管理自己的服務器時），進行縮放比較困難。 添加資源可能成本高昂，而且通常需要很長時間才能使資源聯機。 有時甚至會超出增加容量實際需要的時間。 在系統需求低時縮減資源也同樣困難，你可能不得不面對成本增加這一問題。
輕鬆縮放是 Azure 的一個重要優勢。 大多數 Azure 資源都提供在需求變化時輕鬆添加或刪除資源的能力。 許多服務都有自動選項，可監控需求並做出調整。 自動縮放功能通常被稱爲“自動縮放”。 通過自動縮放，你可以爲可用的最小和最大實例數級別設置閾值。 該功能還根據性能指標（例如 CPU 使用率） 添加或刪除實例。
什麼是縱向擴展或縮減？
使用服務的單個實例（如虛擬機）時，可能需要縮放實例可用的資源數量。
- “縱向擴展”是增加給定實例的容量的過程。 例如，若要增加處理容量，可以將虛擬機從 1 個 vCPU、3.5 GB RAM 增加到 2 個 vCPU、7 GB RAM。
- “縱向縮減”是減少給定實例的容量的過程。 例如，你可以將虛擬機的容量從 2 個 vCPU 和 7 GB 的 RAM 減少到 1 個 vCPU 和 3.5 GB 的 RAM。 通過這樣的方式來縮減容量和成本。
下圖顯示了更改虛擬機大小的示例。
我們來從 Azure 資源的角度看一看縱向擴展或縱向縮減的含義：
- 在 Azure 虛擬機中，根據虛擬機大小進行縮放。 每個 VM 大小具有一定數量的 vCPU、RAM 和與之相關的本地存儲。 例如，你可以從 Standard_DS1_v2 虛擬機（1 個 vCPU、3.5 GB 的 RAM）縱向擴展到 Standard_DS2_v2 虛擬機（2 個 vCPU、7 GB 的 RAM）。
- Azure SQL 數據庫是 Microsoft SQL Server 的一種平臺即服務 (PaaS) 實現。 你可以基於數據庫事務單位 (DTU) 或 vCPU 的數量對數據庫進行縱向擴展。 DTU 是基礎資源的抽象，也是 CPU、IO 和內存的混合。 例如，可以將 Azure SQL 數據庫中的數據庫從具有 250 DTU 的 P2 擴展到具有 500 DTU 的 P4，以爲數據庫提供更高吞吐量和容量。
- Azure 應用服務是 Azure 上的 PaaS 網站託管服務。 網站在虛擬服務器場（也稱爲應用服務計劃）上運行。 你可以在層級之間縱向擴展或縮減應用服務計劃。 這些層級內也提供了容量選擇。 例如，S1 應用服務計劃的每個實例具有 1 個 vCPU 和 1.75 GB 的 RAM。 你可以縱向擴展到 S2 應用服務計劃，其中每個實例具有 2 個 vCPU 和 3 GB 的 RAM。
若要在本地環境中縮放這些類型的功能，通常必須等待所需硬件採購和安裝完畢，才能開始使用新的縮放級別。 在 Azure 中，物理資源已部署並可供使用。 只需選擇要使用的備用縮放級別即可。
你可能需要考慮在解決方案中縱向擴展的影響。 你的決定取決於選擇的雲服務。
例如，如果選擇在 Azure SQL 數據庫中縱向擴展，則該服務將處理單個節點的縱向擴展並繼續運行服務。 更改數據庫的服務層或性能級別會在新的性能級別創建原始數據庫的副本。 然後將連接切換到副本。 在這個過程中數據不會丟失。 服務切換到副本時，只有短暫的中斷。 中斷時間通常不到 4 秒。
或者，如果選擇縱向擴展或縮減虛擬機，則可通過選擇其他實例大小來實現。 在大多數情況下，如果 VM 已在運行，需要重啓 VM。 考慮到這一點，預計在縮放 VM 時需要重新啓動。 你需要在計劃中考慮這種可能性。
最後，始終應查找可縱向縮減的地方。 如果應用程序可在較低的價格層提供足夠的性能，則可以減少 Azure 帳單。
什麼是橫向擴展或縮減？
你現在已瞭解了縱向擴展和縮放是調整單個實例可用的資源量。 橫向擴展和縮減調整實例總數。
- 橫向擴展是添加更多實例來支持解決方案負載的過程。 例如，如果你的網站前端託管在虛擬機上，則在負載級別增加時，你可以增加虛擬機數。
- 橫向縮減是刪除支持解決方案負載不再需要的實例的過程。 如果你的網站前端使用率較低，你可以希望減少實例數以節省成本。
下圖顯示了更改虛擬機實例數的示例。
下面是橫向擴展或橫向縮減在 Azure 資源上下文中的含義的一些示例：
- 對於基礎結構層，可能會使用虛擬機規模集自動添加和刪除額外的實例。
- 使用虛擬機規模集可以創建並管理一組完全相同的、負載均衡的 VM。
- 可以根據需求或定義的計劃自動增減 VM 實例的數目。
- 在 Azure SQL 數據庫實現中，可以通過分片在數據庫實例之間共享負載。 分片是一項可跨許多獨立數據庫分發大量相同結構數據的技術。
- 在 Azure 應用服務中，應用服務計劃是託管應用程序的虛擬 Web 服務器。 以這種方式進行橫向擴展意味着要增加服務器場中的虛擬機數。 與虛擬機規模集一樣，可以根據特定指標或計劃自動增加或減少實例數。
通常可以通過 Azure 門戶、命令行工具或 Azure 資源管理器模板輕鬆進行橫向擴展。 在大多數情況下，用戶可以無縫過渡。
自動縮放
可以配置其中一些服務，讓其使用“自動縮放”功能。 藉助自動縮放，無需再爲手動縮放服務而費心。 你可以設置實例數的最小和最大閾值。 你可以根據特定指標（如隊列長度或 CPU 利用率）進行縮放。 還可以根據計劃進行縮放。 例如工作日下午 5:00 至晚上 7:00 之間。 下圖顯示了自動縮放功能如何管理用於處理負載的實例。
橫向擴展和橫向縮減注意事項
橫向擴展時，應用程序的啓動時間可能會影響應用程序縮放的速度。 如果 Web 應用需要 2 分鐘才能啓動並可供用戶使用，這意味着每個實例都將需要 2 分鐘才能供用戶使用。 在確定縮放速度時，需要考慮該啓動時間。
此外，還需要考慮應用程序如何處理狀態。 應用程序橫向縮減時，存儲在從環境中刪除的實例上的任何狀態都將丟失。 如果用戶連接到沒有狀態的實例，應用程序可能會強制用戶登錄或重新選擇數據。 這會導致用戶體驗不佳。 一種常見模式是將狀態外部化到另一種服務（如 Azure Cache for Redis 或 SQL 數據庫），使 Web 服務器變成無狀態。 現在，你的 Web 前端是無狀態的，你無需擔心哪些單個實例可用。 這些實例執行相同的作業，並且部署方式相同。
限制
我們已經確定應用程序的負載會隨着時間的推移而變化。 這種變化可能歸因於活躍或併發用戶數以及正在執行的活動。 可使用自動縮放添加容量，但也可使用限制機制來限制來自數據源的請求數。 你可以通過在應用程序級別設置已知限制來保護性能限制。 這樣，可以防止應用程序中斷。 限制最常用於公開 API 終結點的應用程序中。
應用程序確定其將違反某條限制後，限制便會開始並確保不違反整體系統 SLA。 例如，如果你公開 API 供客戶用於獲取數據，則可以將請求數限制爲每分鐘 100 個。 如果任何一個客戶超過此限制，你可以使用 HTTP 429 狀態代碼進行響應，並顯示可成功提交另一個請求前的等待時間。
無服務器
無服務器計算提供雲託管執行環境，可運行應用，但會將基礎環境完全抽象化。 你創建一個服務實例，並添加代碼。 不需要甚至不允許管理或維護基礎設施。
可配置無服務器應用以響應事件。 事件可以是 REST 終結點、計時器或從其他 Azure 服務接收的消息。 無服務器應用僅在被事件觸發時運行。
使用無服務器應用時，你不用負責基礎結構。 系統自動處理縮放和性能。 你僅需爲使用的資源付費。 沒有必要保留容量。 Azure Functions、Azure 容器實例和 Azure 邏輯應用就是 Azure 上提供的無服務器計算的示例。
容器
容器是一種在虛擬化環境中運行應用程序的方法。 虛擬機在硬件級別進行虛擬化，在該級別，虛擬機監控程序使其可以在一個物理服務器上運行多個虛擬化操作系統。 容器將虛擬化提升了一個級別。 在 OS 級別完成虛擬化，這樣就有可能在同一個 OS 中運行多個相同的應用程序實例。
容器是輕量級的，非常適合用於橫向擴展場景。 它們被設計爲根據環境和需求變化實現動態創建、橫向擴展和停止。 使用容器的另一個好處是能夠在每個虛擬機上運行多個獨立的應用程序。 由於容器在內核級別受到保護和隔離，因此不一定需要單獨的 VM 來處理單獨的工作負載。
雖然可以在虛擬機上運行容器，但有一些 Azure 服務可簡化容器的管理和縮放：
-
Azure Kubernetes 服務 (AKS)
藉助 Azure Kubernetes 服務，可設置虛擬機作爲節點。 Azure 託管 Kubernetes 管理平面。 僅對在運行的託管容器的工作器節點節點收費。
若要增加 Azure 中的工作器節點數，你可以使用 Azure CLI 手動增加該數量。 撰寫本文時，可以使用 AKS 上的羣集自動縮放程序來自動縮放工作器節點。 在 Kubernetes 羣集上，你可以使用水平 Pod 自動縮放程序對要部署的容器的實例數進行橫向擴展。
AKS 還可以使用下一部分中所述的虛擬 Kubelet 進行縮放。
-
Azure 容器實例
Azure 容器實例是無服務器方法，可用於按需創建和執行容器。 僅需爲按秒計的執行時間付費。
你可以使用虛擬節點將 Azure 容器實例連接到 Kubernetes 環境，包括 AKS。 AKS 的虛擬節點加載項基於開源虛擬 Kubelet。 對於虛擬節點，當 Kubernetes 羣集需要其他容器實例時，可從容器實例滿足這些要求。 由於容器實例是無服務器的，因此無需具有保留容量。 你可以利用 Kubernetes 縮放的控制和靈活性，以及無服務器的按秒計費。
知識檢查
什麼是橫向擴展和縱向擴展？
現代應用程序不斷變化，隨着新要求的發展而發展，並且存在於對資源的不同需求的環境中。擴展應用程序可以根據資源需求適當調整其大小，以確保客戶滿意並降低基礎設施成本。
如果您不知道如何有效地擴展，您不僅會損害您的應用程序，還會給您的運營團隊帶來不必要的壓力。手動嘗試確定何時擴大或擴大規模非常困難。如果您購買更多基礎設施來適應高峯流量，那麼當負載不是高峯時，您可能會超支。如果您以平均負載爲目標，流量高峯將影響您的應用程序性能，並且當流量下降時，這些資源將被閒置。
什麼是縱向擴展與橫向擴展
橫向擴展(「Scale-out」)或水平縮放與縱向擴展(「Scale-up」)或垂直縮放形成對比。
擴展雲資源的想法可能很直觀。隨着您的雲工作負載發生變化，可能需要增加基礎架構以支持增加的負載，或者在需求低時減少基礎架構可能是有意義的。“向上或向外”部分可能不太直觀。橫向擴展是並行添加更多等效功能組件以分散負載。這將從兩個負載平衡的 Web 服務器實例變爲三個實例。相比之下，擴大規模是使組件更大或更快以處理更大的負載。這會將您的應用程序移動到具有 2 個 CPU 的虛擬服務器 (VM) 到具有 3 個 CPU 的虛擬服務器。縮減則相反。
兩個比喻
火車動力
傳統火車和動車。傳統的存儲Scale-up架構的存儲就好像傳統的火車一樣，當後面的磁盤越掛越多的時候，控制器性能以及背板帶寬卻不能相應提升，因此傳統存儲在磁盤容量擴容到一定程度時候，往往性能下降。
集羣存儲就好像新一代的動車組火車一樣，當火車車廂增加的時候，前面的火車頭動力也隨之增加，因此不會發生性能瓶頸。
所謂動車組的設計理念和傳統火車設計理念的最大區別在於傳統火車主要動力來自於火車頭(就像傳統模塊化陣列的兩個控制器)，而動車組則不一樣，除了車頭配有動力裝置外，每一節車廂都配有動力推動裝置。集羣存儲大多都是由一個個節點(X86 服務器)組成，每一個節點添加進去後，不僅能夠添加容量，還能夠添加整個存儲器的整體處理能力。
魚缸啓示
其實我認爲Scale-out和Scale-up的概念可以用一個簡單的例子來解釋。
不知您有沒有養過魚? 當你只有六七條魚的時候，一個小型魚缸就夠了;可是過一段時間新生了三十多條小魚，這個小缸顯然不夠大了。
如果用Scale-up解決方案，那麼你就需要去買一個大缸，把所有沙啊、水草啊、佈景啊、加熱棒、溫度計都從小缸裏拿出來，重新佈置到大缸。這個工程可不簡單哦，不是十分鐘八分鐘能搞得定的，尤其水草，糾在一起很難分開(不過這跟遷移數據的工程複雜度比起來實在是毛毛雨啦，不值一提)。
那麼現在換個思路，用Scale-out方案，就相當於是你在這個小缸旁邊接了一個同樣的小缸，兩個缸聯通。魚可以自動分散到兩個缸，你也就省掉了上面提到的那一系列挪沙、水草、佈景等的折騰了。
回到存儲架構。用戶在採購之初很難準確預測未來數據增長的速度和總量。用戶往往不得不採購比自己目前實際需求容量更大的存儲，這就導致兩個問題，一是預算的浪費，很多存儲空間都是爲未來數據增長採購的，花了10TB的錢，但是可能只利用上了5TB，另5TB的資金都白白放在那裏。另一個問題是，隨着時間推移，數據增長，數據量超過了10TB。
按照過去Scale-up的理念，解決方案就是購買更大容量的存儲，那麼難免面臨數據遷移的問題，用戶必須停機遷移數據，意味着服務的中斷。而Scale-out架構解決了這個矛盾。用戶按需採購存儲，一旦容量不夠了，再購置一臺接到原有存儲上就可以了。
舉個例子
常見的存儲設備擴展案例，下圖展示了scale-out存儲方案的架構。在圖中，系統只能通過增加具有完整功能的節點進行擴展，但一個scale-out系統可以有很多節點，而且節點之間的內部物理互聯距離也可以很遠。
Scale-up，即縱向擴展架構。從下面的拓撲圖我們可見，縱向擴展是利用現有的存儲系統，通過不斷增加存儲容量來滿足數據增長的需求。
Scale-up 和 scale-out 並非不能融合在一起，很多存儲系統就可以同時實現縱向擴展和橫向擴展,下面的示意圖就展示了這種方案。
究竟選擇scale-up還是scale-out架構,主要考慮以下因素：
| 成本 | Scale-up架構只有容量升級的成本，不會增加控制器或基礎設施的開銷。如果我們主要衡量每GB存儲的單位價格，scale-up的擴展方式無疑更便宜一些 |
|---|---|
| 容量 | 兩種解決方案都可以滿足容量需求，但scale-up架構也許會有些限制，主要取決於單個系統最大支持多少個磁盤數量和多大的容量 |
| 性能 | Scale-out架構在性能上具有擴展潛力，在多個存儲控制器下，IOPS處理能力和吞吐帶寬都可以聚合。雖然節點之間的通信會引發延遲，但那是部署時的細節問題 |
| 管理 | Scale-up架構本身就是以單一系統的方式來進行管理的。而Scale-out架構通常有聚合管理的能力，但每個廠商提供的產品可能會有所不同 |
| 複雜性 | Scale-up架構的存儲相對簡單，而scale-out架構的系統會更復雜一些，畢竟每個節點都需要管理 |
| 可用性 | 多個節點可以提供更好的可用性，假使有一個部件故障或失效，系統也不至於整體宕機。這一點與具體的實施方案也有關係 |
在選擇scale-up還是scale-out的時候，我們要考慮大量的因素。而結果往往取決於哪個廠商有比其他人更好的整體方案、實施能力和技術優勢。但我們最好從瞭解最基本的信息起步，瞭解這兩種技術及其之間的差別。