應(yīng)用程序自動(dòng)規(guī)模伸縮以適應(yīng)負(fù)載需求確實(shí)非常理想,但其中也蘊(yùn)含著嚴(yán)重的復(fù)雜性與潛在風(fēng)險(xiǎn)。
不管大家有沒(méi)有聽(tīng)說(shuō)過(guò),最近幾年市場(chǎng)上出現(xiàn)了一類極具吸引力的新方案——也就是云服務(wù)器。雖然這個(gè)名稱本身并沒(méi)有實(shí)際意義,但大家可以將云服務(wù)器理解成一系列包含有計(jì)算與I/O資源的實(shí)例,我們能夠根據(jù)自己的需求隨時(shí)將其實(shí)例化或者關(guān)閉。總之,亞克西。
不過(guò)單靠云技術(shù)概念還遠(yuǎn)不足以構(gòu)建起理想國(guó)。沒(méi)錯(cuò),它的出現(xiàn)讓構(gòu)建可擴(kuò)展環(huán)境變得非常輕松,但管理這類環(huán)境同樣非常復(fù)雜——特別是考慮到由業(yè)務(wù)變動(dòng)引發(fā)的自動(dòng)縮放與服務(wù)增長(zhǎng)問(wèn)題。在這種情況下,大家可能會(huì)突然發(fā)現(xiàn)自己找不到一種能夠搞定一切狀況的標(biāo)準(zhǔn)化方案。
我們過(guò)去一直將可擴(kuò)展能力視為一種相對(duì)比較緩慢的調(diào)整選項(xiàng)。如果我們剛剛招徠到一大批新員工,那么IT部門(mén)就需要為他們提供額外的擴(kuò)展服務(wù)器資源以支撐其存儲(chǔ)與應(yīng)用需求,有時(shí)候甚至還得另行構(gòu)建強(qiáng)大的數(shù)據(jù)庫(kù)集群等方案。我們需要花幾個(gè)月甚至幾年時(shí)間來(lái)不斷規(guī)劃規(guī)模伸縮機(jī)制。相比之下,大型互聯(lián)網(wǎng)站點(diǎn)則包含有大量物理服務(wù)器,而不必考慮當(dāng)前實(shí)際負(fù)載——這是因?yàn)樗麄冃枰獮闀r(shí)刻可能出現(xiàn)的峰值以及日常狀態(tài)下的平穩(wěn)資源需求做好準(zhǔn)備。而在多數(shù)情況下,這些服務(wù)器設(shè)備都處于閑置狀態(tài)。
但現(xiàn)在規(guī)??s放已經(jīng)成為一項(xiàng)能夠瞬間完成的任務(wù)。我們可以根據(jù)意愿生成新的實(shí)例,并在負(fù)載峰值結(jié)束后將其棄用。我們能夠在幾分鐘而非像過(guò)去那樣利用幾個(gè)月完成規(guī)模伸縮調(diào)整。不過(guò)這種自動(dòng)化機(jī)制當(dāng)中也包含有潛在風(fēng)險(xiǎn),而且很難得到準(zhǔn)確調(diào)整。自動(dòng)化應(yīng)用程序在規(guī)模伸縮當(dāng)中包含眾多變量與調(diào)整空間,而不同應(yīng)用在這些方面擁有著獨(dú)特的要求——換言之,對(duì)某款應(yīng)用非常適用的方案在遷移至另一應(yīng)用時(shí)往往效果極差。總結(jié)來(lái)講,細(xì)節(jié)就是其原罪。
舉例來(lái)說(shuō),我們可以設(shè)想一套典型的分層Web應(yīng)用程序。在這里,我們擁有數(shù)據(jù)庫(kù)、存儲(chǔ)以及前端應(yīng)用服務(wù)器這幾大元素。為了能讓這套基礎(chǔ)設(shè)施根據(jù)負(fù)載變化情況實(shí)現(xiàn)動(dòng)態(tài)規(guī)模伸縮,我們需要監(jiān)控所有這些組成部分,并根據(jù)實(shí)際負(fù)載決定其變動(dòng)方式——同時(shí)又要考慮到其它部分負(fù)載給其帶來(lái)的影響。
如果我們的前端服務(wù)器開(kāi)始出現(xiàn)峰值,那么我們則需要引入更多前端資源,但同一時(shí)間數(shù)據(jù)庫(kù)服務(wù)器的負(fù)載強(qiáng)度可能并沒(méi)那么大,這代表著我們需要在增加前端服務(wù)器數(shù)量的同時(shí)降低數(shù)據(jù)庫(kù)服務(wù)器數(shù)量。接下來(lái),存儲(chǔ)I/O又會(huì)帶來(lái)新的問(wèn)題,因此我們也需要為其添加更多資源。
在此之后,當(dāng)負(fù)載開(kāi)始重新回歸平穩(wěn)時(shí),我們則需要在基礎(chǔ)設(shè)施當(dāng)中釋放這些多余資源——但不能釋放得太多,也不能釋放得太快。我們還需要在調(diào)整規(guī)模的同時(shí)為各處負(fù)載添加標(biāo)簽,因?yàn)橐粋€(gè)區(qū)域的容量降低可能會(huì)對(duì)另一區(qū)域產(chǎn)生負(fù)面影響。如果我們減少了數(shù)據(jù)庫(kù)資源,那么應(yīng)用程序服務(wù)器上的負(fù)載可能會(huì)因此出現(xiàn)瓶頸,同時(shí)前端服務(wù)器則不受影響——總之,我們需要對(duì)其關(guān)聯(lián)保持高度關(guān)注。而且單純?cè)鲩L(zhǎng)應(yīng)用程序服務(wù)器而不解決負(fù)載資源緊張的問(wèn)題,顯然也是于事無(wú)補(bǔ)。
正如大家所見(jiàn),在這種情況下我們的決策樹(shù)將變得極為龐大,而且其中很可能包含有重大缺陷。我們需要部署大量監(jiān)控機(jī)制與計(jì)時(shí)工具,記錄等待狀態(tài)、閾值以及計(jì)數(shù)。此外,我們還得將無(wú)數(shù)聲明與比較規(guī)則納入進(jìn)來(lái)以構(gòu)建起一套自適應(yīng)基礎(chǔ)設(shè)施,且其邏輯本身也需要受到監(jiān)控與調(diào)整。這絕不僅僅是一項(xiàng)單純的目標(biāo),而是一段不斷延續(xù)的摸索過(guò)程。
如果基礎(chǔ)設(shè)施的實(shí)際復(fù)雜程度超出我們之前設(shè)定的簡(jiǎn)單Web應(yīng)用,那么可能還會(huì)涉及多種公共API集成、緩存與查詢服務(wù)器、隊(duì)列 NoSQL數(shù)據(jù)庫(kù)服務(wù)器或者數(shù)量不等的現(xiàn)代服務(wù)組件,這將使得動(dòng)態(tài)負(fù)載管理機(jī)制的復(fù)雜性呈指數(shù)級(jí)增長(zhǎng)。很明顯,這絕不是一句簡(jiǎn)單的“如果一臺(tái)服務(wù)器超載了,就使用另一臺(tái)”所能概括。
哦,另外需要強(qiáng)調(diào)的是,我們還沒(méi)有考慮到相關(guān)應(yīng)用程序在設(shè)計(jì)當(dāng)中是否考慮到了快速規(guī)模伸縮場(chǎng)景。如果答案是否定的,那么我們將很難甚至根本無(wú)法對(duì)后端資源進(jìn)行調(diào)整。
動(dòng)態(tài)規(guī)模伸縮能力帶來(lái)的收益是顯而易見(jiàn)的。它能夠以更低的使用成本為我們提供理想的性能水平與可用性表現(xiàn),這無(wú)疑是一種雙贏局面。然而,要發(fā)揮其固有優(yōu)勢(shì)也需要大家投入心血與代價(jià),各位千萬(wàn)不要等閑視之才好。