在本文中，我們將注意力集中在動態縮放，即自動擴展，以及為什么我們需要可以自動擴展的應用程序。
你將學習
-
什么是自動或動態擴展。
-
為什么動態擴展在微服務環境中很重要。
-
如何在雲中實現動態擴展。
應用程序的負載變化
應用程序的負載取決於一天中的某個時間，一個月中的某一天或一年中的某個月。
以www.taobao.com為例。在雙11期間它的負荷非常高，高達正常負荷的很多倍。然而，在春節和重大環境災難期間，負載量可能會少得多 - 因為每個人都在忙着觀看春節聯歡晚會或者交通不便導致的商品無法快遞。
如何為應用程序設置基礎架構以管理不同的負載？
基礎設施很可能需要處理正常負載的10倍。如果您通過預置的基礎架構，則需要一個大型基礎架構來處理峰值負載。
在負載較少的時期，許多基礎設施將閑置。
及時雨－雲計算
這就是為什么架構圖中需要添加雲。使用雲，您可以在負載較高時請求更多資源，並在負載較少時將其返回雲端。
這稱為Scale Out（在負載增加時創建更多實例）和Scale In（在負載下降時減少實例）
如何構建支持雲的應用程序，即在雲中運行良好的應用程序？
微服務架構出現在了架構圖中。
自動擴展簡介
使用微服務構建應用程序使您可以在高負載期間增加微服務實例的數量，並在負載較少的情況下減少它們。
請考慮以下CurrencyConversionService(貨幣交換服務)示例：
CurrencyConversionService與ForexService進行通信。ForexService關注的是計算1美元可以產生多少人民幣，或者1歐元可以產生多少人民幣。
CurrencyConversionService獲取一袋貨幣和金額，並以您選擇的貨幣生成總金額。例如，它將表示人民幣的總價值為10歐元和25美元。
ForexService也可能來自許多其他微服務。
擴展基礎架構以匹配負載
ForexService上的負載可能與CurrencyConversionService上的負載不同。您可能需要具有不同數量的CurrencyConversionService和ForexService實例。例如，可能有兩個CurrencyConversionService實例，以及ForexService的五個實例：
在稍后的時間點，CurrencyConversionService上的負載可能很低，只需要兩個實例。另一方面，ForexService上的更高負載可能需要50個實例。來自兩個CurrencyConversionService實例的請求分布在ForexService的50個實例中。
實質上，這就是自動擴展的要求 - 動態變化的微服務實例數量，並在它們之間均勻分配負載。
實現自動擴展
實現自動擴展涉及一些重要的概念。以下內容將詳細討論它們。
注冊中心
注冊中心啟用稱為位置透明的東西。每個微服務都向命名服務注冊。任何需要與另一個微服務器通信的微服務都會向注冊中心詢問其位置。
每當出現CurrencyConversionService或ForexService的新實例時，它都會向命名服務器注冊。
當CurrencyConversionService想要與ForexService通信時，它會向命名服務器詢問可用的實例。
實施位置透明度
CurrencyConversionService知道有五個ForexService實例。
它如何在所有這些實例中分配負載？
負載均衡器出現在了人們的腦中。
一個流行的客戶端負載平衡框架是Ribbon。
讓我們看一個圖表來了解發生的事情：
只要CurrencyConversionService或ForexService的任何實例出現，它就會向命名服務器注冊自己。如果CCSInstance2想知道ForexService實例的URL，它會再次與命名服務器通信。命名服務器響應ForexService的所有實例列表 - FSInstance1和FSinstance2 - 及其相應的URL。
功能區負載均衡器在ForexService實例中進行循環，以平衡實例之間的負載。
Ribbon提供多種負載均衡算法供您選擇。
何時增加和減少微服務實例
我們沒有真正談論過一個問題。
我們如何知道何時增加或減少微服務的實例數？
這就是應用程序監視和容器（Docker）編排（使用Kubernetes）需要被考慮。
需要監視應用程序以找出它有多少負載。為此，應用程序必須公開我們的指標以跟蹤負載。
您可以使用Docker對每個微服務進行容器化並創建映像。
Kubernetes具有管理容器的能力。可以將Kubernetes配置為基於負載自動縮放。Kubernetes可以識別應用程序實例，監控其負載，並自動向上和向下擴展。