1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        彈性伸縮

        共 5440字,需瀏覽 11分鐘

         ·

        2021-09-30 21:12

        彈性伸縮逐漸變成了各大云廠商的標(biāo)配。比如國內(nèi)的阿里云。

         
         
        國外的亞馬遜云。
         
         
        如果是公司內(nèi)部自己用的私有云,那就看公司規(guī)模了。規(guī)模小的可能沒有彈性伸縮,或者僅僅提供一小部分簡單的功能,規(guī)模大的則必然有單獨的彈性伸縮產(chǎn)品。
         
        什么是彈性伸縮呢?簡單說就是,在需要很多機器的時候,自動擴容機器數(shù)量,在不需要那么多機器的時候,自動縮減機器數(shù)量。
         
        比如正常情況下,你的項目 1 臺服務(wù)器就夠了,但節(jié)假日的時候訪問人數(shù)突然增多,需要 5 臺機器才能扛得住,那就把機器臨時加到 5 臺,然后節(jié)假日結(jié)束了,再縮減回原來的 1 臺。
         
        這個過程完全可以由人手動去操作,可是人操作就會失誤,也會增加人力成本。而且這還只是簡單的情況,如果是完全無法預(yù)測的高峰,比如突然有一條新聞上熱搜了,而你恰好是做資訊類的產(chǎn)品,那必然訪問人數(shù)突然增加,這時候你手動擴充機器根本來不及。
         
        而彈性伸縮,就是把這部分盡可能智能化,解放人們在這方面浪費的時間,并且要做得比人更好,更智能,更靠譜。
         
        怎么做呢?讓我們從最初沒有彈性伸縮時的場景開始出發(fā)。
         
         

        無彈性

         
         
        我們假設(shè)部署一個服務(wù),已經(jīng)有了一個自動化運維的平臺,在這個平臺下你新建一個服務(wù),一個服務(wù)下有多臺服務(wù)器,具體數(shù)量可以在服務(wù)配置里手動填寫,每臺服務(wù)器都部署著同樣的代碼。
         
        服務(wù)名稱:flash-demo
        代碼倉庫或鏡像地址:https://xxx
        服務(wù)器數(shù)量:10
        服務(wù)器規(guī)格:4核 8G 100G硬盤
         
        然后這個平臺下,你可以選擇一個服務(wù),并且選擇對應(yīng)的最新代碼,或者最新鏡像,點擊發(fā)布。之后這個平臺就會為你申請你指定數(shù)量的機器,并且部署上你的代碼。
         
        你這個服務(wù)的特征是,每個周末訪問的人就變多,于是你在每個周五晚上,在服務(wù)器配置中把服務(wù)器數(shù)量改成 20。然后還要在每個周日晚上,把服務(wù)器數(shù)量改回成 10。
         
        就這樣日復(fù)一日,年復(fù)一年。
         
         

        定時任務(wù)

         
         
        你再也受不了這種重復(fù)性的勞動了,打算把它自動化!
         
        于是你在服務(wù)器配置中,增加一項配置,參數(shù)為時間數(shù)量,可以配置多個。表示達到某個時間,機器數(shù)量就調(diào)整多少。
         
        服務(wù)名稱:flash-demo
        代碼倉庫或鏡像地址:https://xxx
        服務(wù)器數(shù)量:10
        服務(wù)器規(guī)格:4核 8G 100G硬盤
        時間:周五晚上 8:00
        數(shù)量:+10
        時間:周日晚上 8:00
        數(shù)量:-10
         
        這就把你剛剛的重復(fù)勞動自動化了,程序會自動在每周五晚上 8:00 增加 10 臺機器,每周日晚上 8:00 再減少 10 臺機器。
         
        你從中解脫!你管它叫定時任務(wù)。
         
         

        報警任務(wù)

         
         
        直到有一天,你的網(wǎng)站不知道什么原因,訪問人數(shù)瞬間增多,可是你隔了好久才反應(yīng)過來。

        你趕緊手動增加機器數(shù)量,才逐漸緩解下來。但由于時間的耽誤,損失的利益已經(jīng)不可挽回了。于是你決定,由程序來自動監(jiān)控并處理。
         
        接著剛剛定時任務(wù)的思路,你又增加了一項配置。
         
        服務(wù)名稱:flash-demo
        代碼倉庫或鏡像地址:https://xxx
        服務(wù)器數(shù)量:10
        服務(wù)器規(guī)格:4核 8G 100G硬盤
        時間:周五晚上 8:00
        數(shù)量:+10
        時間:周日晚上 8:00
        數(shù)量:-10
        觸發(fā)條件:QPS > 100
        數(shù)量:+2
        觸發(fā)條件:QPS < 50
        數(shù)量:-2
         
        這樣,每當(dāng)網(wǎng)站訪問人數(shù)突增時,單機 QPS 一旦高于 100,就自動觸發(fā)增加機器的操作,加 2 臺機器。同時,如果 QPS 降下來了,小于 50,則減少 2 臺機器,節(jié)省資源。
         
        你管它叫報警任務(wù)。
         
         

        拆分出獨立的彈性伸縮模塊

         
         
        服務(wù)配置項越來越多,不但頁面越來越丑,而且也不好管理。另外如果有其他服務(wù)想要復(fù)用,只能完全復(fù)制一份。于是你想到了解耦的思想,把彈性伸縮任務(wù)這個功能,單獨抽成一個模塊。
         
        服務(wù)名稱:flash-demo
        代碼倉庫或鏡像地址:https://xxx
        服務(wù)器數(shù)量:10
        服務(wù)器規(guī)格:4核 8G 100G硬盤
        綁定的任務(wù):task-1,task-2,task-3,task-4
         
        任務(wù)名稱:task-1
        任務(wù)類型:定時任務(wù)
        時間:周五晚上 8:00
        數(shù)量:+10
         
        任務(wù)名稱:task-2
        任務(wù)類型:定時任務(wù)
        時間:周日晚上 8:00
        數(shù)量:-10
         
        任務(wù)名稱:task-3
        任務(wù)類型:報警任務(wù)
        觸發(fā)條件:QPS > 100
        數(shù)量:+2
         
        任務(wù)名稱:task-4
        任務(wù)類型:報警任務(wù)
        觸發(fā)條件:QPS < 50
        數(shù)量:-2
         
        這樣,服務(wù)是一個模塊,彈性伸縮是一個模塊,彈性伸縮模塊下就是各種彈性任務(wù),分別綁定到不同的服務(wù)上,一下就清爽多了,方便管理,也可以復(fù)用。
         
         

        拆分出伸縮組

         
         
        你發(fā)現(xiàn),目前彈性擴張的機器規(guī)格和部署的項目,都是和原服務(wù)相同的。
         
        而且,假如原服務(wù)有 5 臺機器,你設(shè)置的某一個彈性伸縮任務(wù)一觸發(fā)減少了 5 臺機器,結(jié)果導(dǎo)致你原服務(wù)一臺機器都沒有了,那就危險了。
         
        再有,你的服務(wù)下的機器列表,你也無法分辨出哪個是你原有的機器,哪個是彈性伸縮得到的機器,雖然你可以通過加標(biāo)簽的方式。
         
        所以,暴露的問題就是,彈性伸縮的這部分機器,沒有一個統(tǒng)一的管理。那么很自然,再抽出來一個概念就好了,你叫它伸縮組
         
        同一個伸縮組下的機器規(guī)格是一樣的,你可以個性化指定,這樣就可以做到原服務(wù)有的非彈性機器規(guī)格是 4核 8G,然后彈性擴容的機器是不同的 2核 4G,已達到個性化的需求。
         
        伸縮組需要綁定一個伸縮任務(wù),那么一個伸縮任務(wù)觸發(fā)后,就只在伸縮組里面進行擴展和收縮,不會影響原服務(wù)固定的非彈性機器數(shù)量。然后伸縮組也可以配置最大實例數(shù)與最小實例數(shù),以便更精細(xì)地控制。伸縮組還可以增加監(jiān)控,單獨監(jiān)控某一伸縮組內(nèi)的機器情況,就與原非彈性機器解耦開了。
         
        任務(wù)名稱:task-1
        任務(wù)類型:定時任務(wù)
        時間:周五晚上 8:00
        綁定伸縮組:伸縮組 A
        數(shù)量:+10
         
        伸縮組名稱:伸縮組 A
        機器規(guī)格:4核8G
        最大實力數(shù):30
        最小實力數(shù):10
         
        總之,一切解耦帶來的便利,都因為一個伸縮組被拆出來,而得到。
         
         

        拆分出彈性規(guī)則

         
         
        我們看剛剛的一個人物,其中有一項其實表示了如何在伸縮組里變更機器的含義。
         
        任務(wù)名稱:task-1
        任務(wù)類型:定時任務(wù)
        時間:周五晚上 8:00
        綁定伸縮組:伸縮組 A
        數(shù)量:+10
         
        這表示當(dāng)觸發(fā)某條件時,就增加 10 臺機器。
         
        但這個規(guī)則也會慢慢變得復(fù)雜,可能不僅僅是單純增加幾臺或者減少幾臺,還有可能表達調(diào)整至幾臺,根據(jù)超出閾值的程度動態(tài)增減幾臺等等。一旦復(fù)雜起來,把規(guī)則描述放在任務(wù)中就不太合適了,那好辦,拆出來。
         
        任務(wù)名稱:task-1
        任務(wù)類型:定時任務(wù)
        時間:周五晚上 8:00
        綁定伸縮組:伸縮組 A
        綁定彈性規(guī)則:單純增加 10 臺
         
        彈性規(guī)則名稱:單純增加 10 臺
        規(guī)則類型:簡單規(guī)則
        執(zhí)行操作類型:增加
        數(shù)量:10
        實例預(yù)熱時間:300 ms
         
        顧名思義,大家應(yīng)該能看懂,這里有個實例預(yù)熱時間,意思是實例啟動成功后,過 300 ms 再加入負(fù)載均衡策略池里,允許被上層應(yīng)用訪問,這樣就可以留一部分預(yù)熱時間,用于比如 Java 應(yīng)用程序的類加載過程。
         
        總之,你能想到的更靈活的改動,都直接在某一規(guī)則當(dāng)中就好了。你可以配置一個特別復(fù)雜精細(xì)的規(guī)則,然后綁定給任務(wù)去用,這一部分復(fù)雜性就完全不影響一個任務(wù)本身了,任務(wù)可以專注于自己的判斷條件,而不用去管具體觸發(fā)后的執(zhí)行規(guī)則是什么。
         
         

        操作智能化

         
         
        有的時候,你可能希望達到某個需求,就是希望 CPU 維持在 10% 左右。為了達到這個需求,其實可以通過兩個報警任務(wù)來實現(xiàn),一個是 CPU 大于 12% 時增加 2 臺機器,一個是 CPU 小于 8% 時減少 2 臺機器,通過兩個報警任務(wù),大概實現(xiàn)將 CPU 維持在 10% 左右這個用戶需求。
         
        但這時候你完全可以發(fā)揮你的產(chǎn)品思維,報警任務(wù)是底層的控制手段,而用戶訴求很可能是它們的組合和抽象,那我們完全可以就讓用戶配置一個 CPU 維持在 10% 這樣一個最終目標(biāo),然后由程序自動將其拆解為對應(yīng)的多個報警任務(wù)和彈性規(guī)則的組合,以滿足用戶的這一目標(biāo)。
         
        這樣,方便了用戶的配置,將底層復(fù)雜的配置實現(xiàn)對用戶保持了透明。這樣做的好處是顯而易見的,當(dāng)然壞處就是有潛規(guī)則了,用戶不知道你底層是怎么玩的,可能會心里沒底。畢竟用彈性伸縮的用戶,都是開發(fā)人員嘛,開發(fā)人員還是希望能夠知道更多細(xì)節(jié)的。
         
         

        可預(yù)測智能化

         
         
        如果說上面的操作智能化可以簡化一部分不希望關(guān)注太多細(xì)節(jié)的用戶,那可預(yù)測智能化就是更加簡化了。
         
        我們可以根據(jù)用戶服務(wù)的歷史數(shù)據(jù),基于機器學(xué)習(xí)的方式,了解這個服務(wù)什么時候有可能處于高峰,什么時候又處于低谷,然后自動幫忙配置出一系列的定時任務(wù)和報警任務(wù)。
         
        定時任務(wù)用于提前預(yù)測可能出現(xiàn)的高峰和低谷,動態(tài)調(diào)整機器數(shù)。而報警任務(wù)作為一個兜底方案,萬一沒預(yù)測到的地方,也不至于就沒有辦法了。
         
        此時用戶僅僅需要一鍵開啟智能化,就可以完全不用管彈性伸縮這玩意了,當(dāng)然,你得有足夠的歷史數(shù)據(jù)供彈性伸縮平臺去分析,不能直接丟過去一個任務(wù)就讓人家給你智能管理。
         
        可預(yù)測智能化有兩個方向可以做,一個方向是前置預(yù)測,就是完全基于歷史數(shù)據(jù),提前就把該擴容的機器擴好,流量洪峰來的時候直接就穩(wěn)穩(wěn)接住,這樣是最 Q 彈的。另一個方向是后置預(yù)測,就是當(dāng)一波流量洪峰來的時候,發(fā)現(xiàn)這波流量比較迅猛,之后短時間內(nèi)可能很快達到一個高峰,那就別兩臺兩臺擴了,直接先擴個 20 臺再說,當(dāng)然這樣還是有一小段時間是沒有完美接住流量的,不過已經(jīng)比無預(yù)測無腦一點點擴容的策略智能一些了。
         
         

        原理是啥

         
         
        有人問彈性伸縮的原理是啥,我覺得沒有多大意義,因為沒什么原理。這個產(chǎn)品難點在于整個思想的設(shè)計和細(xì)節(jié)的處理,具體原理就三個重點:
         
        一、如何獲取指標(biāo)數(shù)據(jù)
         
        因為彈性伸縮主要是根據(jù)某些指標(biāo)達到設(shè)定的閾值了,然后觸發(fā)什么什么操作。所以指標(biāo)獲取是第一步,比如 CPU 負(fù)載、內(nèi)存使用率等系統(tǒng)指標(biāo),以及 QPS 等業(yè)務(wù)指標(biāo),無論哪種指標(biāo),一定是有另外一個統(tǒng)一的打點監(jiān)控平臺去收集的,只需要調(diào)他們接口獲取就好了,就是一個數(shù)值的獲取嘛。
         
        二、如何進行指標(biāo)聚合
         
        比如你的用戶配置了一個
        CPU 使用率大于 10% 增加 1 臺機器
         
        又配置了一個
        CPU 使用率大于 10% 增加 2 臺機器
         
        那此時你的邏輯是,提示用戶不能這樣進行配置,還是有自己的一套聚合邏輯,比如取最大值,就增加 2 臺。這是你要去綜合考慮的細(xì)節(jié)問題。
         
        三、如何調(diào)度機器
         
        觸發(fā)閾值后,最后一步就是增加或減少機器,或者更復(fù)雜的運維操作比如重啟機器、執(zhí)行一些 shell 腳本等。這些也一定是有一個專門的調(diào)度產(chǎn)品和團隊在去做的,他們的底層就是 k8s 調(diào)度 docker 容器那一套了,對于彈性計算產(chǎn)品來說,也是調(diào)幾個接口的事情,無需關(guān)心底層具體調(diào)度邏輯。
         
        所以也能看出,當(dāng)分工足夠細(xì)致時,每一層都在做 CRUD 和調(diào)包俠的事情,一旦變得復(fù)雜了,那就該考慮再拆出一層讓另一個團隊或產(chǎn)品去做了。
         
        關(guān)于彈性伸縮,你了解了么?了不了解我也就寫到這了,哈哈哈。本篇文章并不是自己想像出來的一步步優(yōu)化和解耦,而是根據(jù)阿里云的彈性伸縮產(chǎn)品實際的發(fā)展路線來梳理的。
         
         
        你看,這些概念,就是我們上面講的概念。而且它們也并不是一蹴而就的,也是有一個不斷迭代的發(fā)展過程,具體我們可以看產(chǎn)品發(fā)布記錄。
         
         
        可以看到 2019 年 1 月開始支持的這個目標(biāo)追蹤伸縮規(guī)則,其實就是我們的操作智能化的意思,新建一個目標(biāo)追蹤伸縮規(guī)則,就等于建立了多個報警任務(wù),并且綁定簡單擴縮容規(guī)則,以達到追蹤一個指定的監(jiān)控值,比如將 CPU 使用率追蹤保持為 10%。
         
        而阿里云的彈性伸縮還有很多更復(fù)雜的設(shè)計,大家感興趣也可以去體驗一下。
         
        本文所講的彈性伸縮如果你都能理解了,那市面上大部分彈性伸縮的設(shè)計,都不會復(fù)雜過本文介紹的了。甚至大多數(shù)公司的所謂彈性伸縮,就只是我們講的最初設(shè)計,僅僅在服務(wù)配置上多一個參數(shù),以最簡單的增減機器的方式來實現(xiàn),這對大部分小規(guī)模的業(yè)務(wù)場景,已經(jīng)足夠了。
        瀏覽 56
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            操屄好视频 | 亚洲中文在线视频 | 小说www黄 | 深爱激情丁香五月天 | 好大好粗好多水 | 夜夜爽7777精品国产三级 | 成人免费无遮挡无码黄漫视频 | 久久久又黄又爽 | 三级在线观看视频 | 91麻豆成人精品国产 |