在本文中,咱們將注意力集中在動態縮放,即自動擴展,以及爲何咱們須要能夠自動擴展的應用程序。算法
什麼是自動或動態擴展。服務器
爲何動態擴展在微服務環境中很重要。架構
如何在雲中實現動態擴展。負載均衡
應用程序的負載取決於一天中的某個時間,一個月中的某一天或一年中的某個月。框架
以http://www.javashuo.com/tag/www.taobao.com爲例。在雙11期間它的負荷很是高,高達正常負荷的不少倍。然而,在春節和重大環境災難期間,負載量可能會少得多 - 由於每一個人都在忙着觀看春節聯歡晚會或者交通不便致使的商品沒法快遞。微服務
如何爲應用程序設置基礎架構以管理不一樣的負載?學習
基礎設施極可能須要處理正常負載的10倍。若是您經過預置的基礎架構,則須要一個大型基礎架構來處理峯值負載。雲計算
在負載較少的時期,許多基礎設施將閒置。spa
這就是爲何架構圖中須要添加雲。使用雲,您能夠在負載較高時請求更多資源,並在負載較少時將其返回雲端。3d
這稱爲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能夠識別應用程序實例,監控其負載,並自動向上和向下擴展。