想要獲得云端動(dòng)態(tài)而靈活的規模擴充性,并非只是把系統放到云上執行就能得到預期效益,應用程式執行的方式,可能也必須有所調整
在前文中我們談到所謂的「規模可擴充性(scalability)」,一個(gè)系統有沒(méi)有規模可擴充性,我們看的并不是單一計算節點(diǎn)上跑多快,而是當你增加計算資源(例如機器、頻寬)時(shí),能否通過(guò)增加計算資源,來(lái)?yè)Q取更大規模的處理能力。
當在解決大型規模的計算問(wèn)題時(shí),人們關(guān)心能否通過(guò)增加伺服器、頻寬、儲存空間的方法,來(lái)服務(wù)更大規模的用量,更勝于在單一伺服器上可以執行多快。
要得到規模可擴充性,并不是一件容易的事情,但如果可以從平臺本身獲得支持,包括計算能力及資料存取等,對應用程式來(lái)說(shuō),會(huì )簡(jiǎn)單許多。而這也正是一些所謂「云端計算平臺」的作用所在。
另一方面,我們談到了「云端計算平臺」,并不是建構在「云端計算平臺」上的應用程式,就必然具備規模可擴充性。
例如,對于應用程式來(lái)說(shuō),它有可能是建構在IaaS(Infrastructure as a Service)的層次之上,或者,也可能是在PaaS(Platform as a Service)層次上所發(fā)展的。
通常,建立在IaaS上的應用程式,無(wú)法直接得到規模可擴充性,平臺通常可以提供的部分,只是「依用量可隨時(shí)動(dòng)態(tài)彈性配置的資源」。就像在A(yíng)WS的EC2上運行應用程式,并不能保證應用程式的規模可擴充性,充其量,只能在你需要伺服器、頻寬、儲存空間時(shí),EC2能夠盡可能地動(dòng)態(tài)滿(mǎn)足你的需要。
所以說(shuō),并不是把應用程式搬上了「云端」,就必然獲得了規模可擴充性,當你只是在 IaaS 平臺上開(kāi)發(fā)時(shí),是否具備規模可擴充性,仍舊取決于你的系統架構及特性。
不過(guò),當你是在PaaS上開(kāi)發(fā)時(shí),情況又有所不同。PaaS平臺本身,會(huì )處理掉許多和規模可擴充性相關(guān)的問(wèn)題,就像是在Google的App Engine上面,它所提供的資料存取操作,就不同于傳統的關(guān)聯(lián)式資料庫,而是以BigTable 為基礎的操作模式,這使得它有能力處理海量資料的存取。而立足在A(yíng)pp Engine之上的應用程式,自然而然,具備著(zhù)更好的規模可擴充性。
因此,在一個(gè)專(zhuān)門(mén)為了更大規模而設計的平臺上開(kāi)發(fā),對于想要得到規模可擴充性的應用程式開(kāi)發(fā)者來(lái)說(shuō),可以省去不少的力氣。其中像 Hadoop 便是一個(gè)為了大規模計算而設計出來(lái)的平臺,其中,利用所謂MapReduce的計算方式,可以將計算量分散到各個(gè)能提供計算的機器之上,集合眾多機器之力,因而在更短的時(shí)間內,解決想要解決的計算問(wèn)題。而且,可以彈性投入所能配置的資源數量,投入的愈多,解決的愈快。例如,動(dòng)用更多的伺服器,就能更快的解決計算問(wèn)題。倘若預算不那么充分,也可以使用較少的機器,但耗費較多的時(shí)間,而這正是規模可擴充性的意義所在。
分散式計算的迷思
雖然說(shuō),分散式計算的目的之一,就是希望通過(guò)將計算量分散到多部、不同的機器上,來(lái)增加整體的計算能力,但是,并不是所有的應用程式都可以輕易拆散到多部機器之上去運行,而且更重要的是,并不是將應用程式拆分到多部機器之上,就必然帶來(lái)整體計算量的提升。
舉例來(lái)說(shuō),倘若你將你的應用程式拆成多份,并且同時(shí)傳輸至多部機器之上執行,而這幾個(gè)程式之間需要溝通,也就是交換資料,它們之間甚至需要做同步(synchronization),以致于不同機器上的程式之間需要等待特定工作的完成,接著(zhù)才能繼續執行,那么,這樣的應用程式就不見(jiàn)得具有規模可擴充性,因為,等待的環(huán)節,會(huì )造成規模無(wú)法隨著(zhù)計算資源投入而跟著(zhù)成長(cháng)的因素。
這說(shuō)明了,即使試著(zhù)將計算拆分成為多份,并且置于多部機器上執行,也不見(jiàn)得可以獲得多倍的效能改進(jìn),很可能因為計算模式的特性所限,而僅能獲得少數的效能成長(cháng),而且隨著(zhù)規模愈大,成長(cháng)的比例愈低。因此,如何拆分計算工作,使得它們被散布到多部不同的機器后,可以得到對應的計算規模提升,就成了這件事情的核心議題。
通過(guò)分而治之的方式,將大問(wèn)題拆開(kāi)許多個(gè)小問(wèn)題,個(gè)個(gè)擊破,降低解決問(wèn)題的難度
像Hadoop的MapReduce,就是一種拆分計算工作的方式。想要通過(guò)拆分工作來(lái)解決計算問(wèn)題,傳統的「分而治之(Divide and Conquer)」其實(shí),就是一種可行的方式。所謂的「分而治之」,就是將一個(gè)大問(wèn)題,拆解成多個(gè)小問(wèn)題,而分別解決這些小問(wèn)題的答案之后,再將這些答案通過(guò)某種方式合并起來(lái),就可以得到大問(wèn)題的答案。這種方式常常可以遞回為之,也就是拆成比較小的問(wèn)題之后,還可以接著(zhù)再繼續拆解,直到拆解至適合解決問(wèn)題的規模為止。
如果,我們可以運用「分而治之」的方式來(lái)解決問(wèn)題,就很容易得到規模可擴充性,因為,我們可以將原始的問(wèn)題拆解成若干個(gè)較小規模的問(wèn)題,然后把這些問(wèn)題分別置放在不同的機器上解決,因為解決這些小問(wèn)題的計算是互相獨立的、它們之間也不需要溝通,所以,當可運用的機器數量變多時(shí),就可以將問(wèn)題的規模拆解的更小,使得在單一機器上解決它們的速度更快,更使得整體解決它們的時(shí)間可以縮短。而 MapReduce 正是此種「分而治之」的解題計算模式,當你運用MapReduce時(shí),便得以此種方式來(lái)思考解決問(wèn)題的方法。
函數式程式設計開(kāi)始流行
在另一方面來(lái)看,你可能也會(huì )發(fā)現到,所謂「函數式(functional)」的程式設計方式,在這種「分而治之」的分散式計算模式里,開(kāi)始受歡迎了起來(lái)。函數式的程式語(yǔ)言已經(jīng)有幾十年的歷史,早期像 Lisp 的程式語(yǔ)言,主要是應用在人工智慧的領(lǐng)域。但是,為什么在這個(gè)應用領(lǐng)域里,反而流行起來(lái)了?
函數式的程式語(yǔ)言有一些特性,包括程式中是沒(méi)有狀態(tài)(stateless),而且每次函式之值被評估(或說(shuō)被執行)時(shí),是沒(méi)有副作用的(side effect )。
所謂的副作用,代表的是函式被執行時(shí),除了它主要應該達成的作用之外,還有一些其他附屬的效果,此即其副作用。主要的作用,就像是函式的回傳值,而副作用,則像是除了回傳函式之值以外,還同時(shí)改變全域變數的值。你可以想像,函式的回傳值,除了被其輸入參數所影響之外,還同時(shí)被其他的狀態(tài),像是全域變數所影響時(shí),會(huì )產(chǎn)生許多意想不到的結果。
但是如果我們從數學(xué)上的函數的角度來(lái)看,f(x) 之值,完全取決于 x ,沒(méi)任何 f() 內部的狀態(tài)或是外部的狀態(tài)足以在 x 相同時(shí),造成 f(x) 之值不同。而所謂的函數式程式設計方式,便是在特性上有著(zhù)此種取向,因此,它沒(méi)有狀態(tài)、也沒(méi)有副作用。
這種特性之所以能對分散式計算帶來(lái)好處,我想是因為在有這樣的特性之后,計算工作會(huì )更容易分配到不同的機器上去計算。正如數學(xué)的函數一樣,只要給定相同的輸入值,就一定會(huì )算出相同的輸出值。計算工作之間的相依性降低了,不論在那部機器上算、在什么時(shí)間點(diǎn)算,都不會(huì )影響到計算的結果。因此,當以「分而治之」的原則來(lái)拆解計算工作,以進(jìn)行分散式的計算時(shí),更容易拆解工作、更容易合成計算結果,以成為最后的結果。
通過(guò)一個(gè)更高階的云端計算平臺,以及計算模式,其實(shí),可以讓程式設計者更容易的取得規模可擴充性。而從現在的趨勢來(lái)看,函數式的設計方式,應該還會(huì )再流行好一陣子。