【51CTO.com快譯】應(yīng)用程序自動規(guī)模伸縮以適應(yīng)負(fù)載需求確實(shí)非常理想，但其中也蘊(yùn)含著嚴(yán)重的復(fù)雜性與潛在風(fēng)險。

[[149427]]

不管大家有沒有聽說過，最近幾年市場上出現(xiàn)了一類***吸引力的新方案——也就是云服務(wù)器。雖然這個名稱本身并沒有實(shí)際意義，但大家可以將云服務(wù)器理解成一系列包含有計算與I/O資源的實(shí)例，我們能夠根據(jù)自己的需求隨時將其實(shí)例化或者關(guān)閉?？傊瑏喛宋?。

不過單靠云技術(shù)概念還遠(yuǎn)不足以構(gòu)建起理想國。沒錯，它的出現(xiàn)讓構(gòu)建可擴(kuò)展環(huán)境變得非常輕松，但管理這類環(huán)境同樣非常復(fù)雜——特別是考慮到由業(yè)務(wù)變動引發(fā)的自動縮放與服務(wù)增長問題。在這種情況下，大家可能會突然發(fā)現(xiàn)自己找不到一種能夠搞定一切狀況的標(biāo)準(zhǔn)化方案。

我們過去一直將可擴(kuò)展能力視為一種相對比較緩慢的調(diào)整選項(xiàng)。如果我們剛剛招徠到一大批新員工，那么IT部門就需要為他們提供額外的擴(kuò)展服務(wù)器資源以支撐其存儲與應(yīng)用需求，有時候甚至還得另行構(gòu)建強(qiáng)大的數(shù)據(jù)庫集群等方案。我們需要花幾個月甚至幾年時間來不斷規(guī)劃規(guī)模伸縮機(jī)制。相比之下，大型互聯(lián)網(wǎng)站點(diǎn)則包含有大量物理服務(wù)器，而不必考慮當(dāng)前實(shí)際負(fù)載——這是因?yàn)樗麄冃枰獮闀r刻可能出現(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ī)模伸縮調(diào)整。不過這種自動化機(jī)制當(dāng)中也包含有潛在風(fēng)險，而且很難得到準(zhǔn)確調(diào)整。自動化應(yīng)用程序在規(guī)模伸縮當(dāng)中包含眾多變量與調(diào)整空間，而不同應(yīng)用在這些方面擁有著獨(dú)特的要求——換言之，對某款應(yīng)用非常適用的方案在遷移至另一應(yīng)用時往往效果極差。總結(jié)來講，細(xì)節(jié)就是其原罪。

舉例來說，我們可以設(shè)想一套典型的分層Web應(yīng)用程序。在這里，我們擁有數(shù)據(jù)庫、存儲以及前端應(yīng)用服務(wù)器這幾大元素。為了能讓這套基礎(chǔ)設(shè)施根據(jù)負(fù)載變化情況實(shí)現(xiàn)動態(tài)規(guī)模伸縮，我們需要監(jiān)控所有這些組成部分，并根據(jù)實(shí)際負(fù)載決定其變動方式——同時又要考慮到其它部分負(fù)載給其帶來的影響。

如果我們的前端服務(wù)器開始出現(xiàn)峰值，那么我們則需要引入更多前端資源，但同一時間數(shù)據(jù)庫服務(wù)器的負(fù)載強(qiáng)度可能并沒那么大，這代表著我們需要在增加前端服務(wù)器數(shù)量的同時降低數(shù)據(jù)庫服務(wù)器數(shù)量。接下來，存儲I/O又會帶來新的問題，因此我們也需要為其添加更多資源。

在此之后，當(dāng)負(fù)載開始重新回歸平穩(wěn)時，我們則需要在基礎(chǔ)設(shè)施當(dāng)中釋放這些多余資源——但不能釋放得太多，也不能釋放得太快。我們還需要在調(diào)整規(guī)模的同時為各處負(fù)載添加標(biāo)簽，因?yàn)橐粋€區(qū)域的容量降低可能會對另一區(qū)域產(chǎn)生負(fù)面影響。如果我們減少了數(shù)據(jù)庫資源，那么應(yīng)用程序服務(wù)器上的負(fù)載可能會因此出現(xiàn)瓶頸，同時前端服務(wù)器則不受影響——總之，我們需要對其關(guān)聯(lián)保持高度關(guān)注。而且單純增長應(yīng)用程序服務(wù)器而不解決負(fù)載資源緊張的問題，顯然也是于事無補(bǔ)。

正如大家所見，在這種情況下我們的決策樹將變得極為龐大，而且其中很可能包含有重大缺陷。我們需要部署大量監(jiān)控機(jī)制與計時工具，記錄等待狀態(tài)、閾值以及計數(shù)。此外，我們還得將無數(shù)聲明與比較規(guī)則納入進(jìn)來以構(gòu)建起一套自適應(yīng)基礎(chǔ)設(shè)施，且其邏輯本身也需要受到監(jiān)控與調(diào)整。這絕不僅僅是一項(xiàng)單純的目標(biāo)，而是一段不斷延續(xù)的摸索過程。

如果基礎(chǔ)設(shè)施的實(shí)際復(fù)雜程度超出我們之前設(shè)定的簡單Web應(yīng)用，那么可能還會涉及多種公共API集成、緩存與查詢服務(wù)器、隊列 NoSQL數(shù)據(jù)庫服務(wù)器或者數(shù)量不等的現(xiàn)代服務(wù)組件，這將使得動態(tài)負(fù)載管理機(jī)制的復(fù)雜性呈指數(shù)級增長。很明顯，這絕不是一句簡單的“如果一臺服務(wù)器超載了，就使用另一臺”所能概括。

哦，另外需要強(qiáng)調(diào)的是，我們還沒有考慮到相關(guān)應(yīng)用程序在設(shè)計當(dāng)中是否考慮到了快速規(guī)模伸縮場景。如果答案是否定的，那么我們將很難甚至根本無法對后端資源進(jìn)行調(diào)整。

動態(tài)規(guī)模伸縮能力帶來的收益是顯而易見的。它能夠以更低的使用成本為我們提供理想的性能水平與可用性表現(xiàn)，這無疑是一種雙贏局面。然而，要發(fā)揮其固有優(yōu)勢也需要大家投入心血與代價，各位千萬不要等閑視之才好。

原文：The dark side of scaling in the cloud

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】