在本文中，我們將注意力集中在動態縮放，即自動擴充套件，以及為什麼我們需要可以自動擴充套件的應用程式。
你將學習
-
什麼是自動或動態擴充套件。
-
為什麼動態擴充套件在微服務環境中很重要。
-
如何在雲中實現動態擴充套件。
應用程式的負載變化
應用程式的負載取決於一天中的某個時間，一個月中的某一天或一年中的某個月。
以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可以識別應用程式例項，監控其負載，並自動向上和向下擴充套件。