想要獲得云端動(dòng)態(tài)而靈活的規(guī)模擴(kuò)充性，并非只是把系統(tǒng)放到云上執(zhí)行就能得到預(yù)期效益，應(yīng)用程式執(zhí)行的方式，可能也必須有所調(diào)整

　　在前文中我們談到所謂的「規(guī)模可擴(kuò)充性（scalability）」，一個(gè)系統(tǒng)有沒(méi)有規(guī)�？蓴U(kuò)充性，我們看的并不是單一計(jì)算節(jié)點(diǎn)上跑多快，而是當(dāng)你增加計(jì)算資源（例如機(jī)器、頻寬）時(shí)，能否通過(guò)增加計(jì)算資源，來(lái)?yè)Q取更大規(guī)模的處理能力。

　　當(dāng)在解決大型規(guī)模的計(jì)算問(wèn)題時(shí)，人們關(guān)心能否通過(guò)增加伺服器、頻寬、儲(chǔ)存空間的方法，來(lái)服務(wù)更大規(guī)模的用量，更勝于在單一伺服器上可以執(zhí)行多快。

　　要得到規(guī)�？蓴U(kuò)充性，并不是一件容易的事情，但如果可以從平臺(tái)本身獲得支持，包括計(jì)算能力及資料存取等，對(duì)應(yīng)用程式來(lái)說(shuō)，會(huì)簡(jiǎn)單許多。而這也正是一些所謂「云端計(jì)算平臺(tái)」的作用所在。

　　另一方面，我們談到了「云端計(jì)算平臺(tái)」，并不是建構(gòu)在「云端計(jì)算平臺(tái)」上的應(yīng)用程式，就必然具備規(guī)�？蓴U(kuò)充性。

　　例如，對(duì)于應(yīng)用程式來(lái)說(shuō)，它有可能是建構(gòu)在IaaS（Infrastructure as a Service）的層次之上，或者，也可能是在PaaS（Platform as a Service）層次上所發(fā)展的。

　　通常，建立在IaaS上的應(yīng)用程式，無(wú)法直接得到規(guī)模可擴(kuò)充性，平臺(tái)通常可以提供的部分，只是「依用量可隨時(shí)動(dòng)態(tài)彈性配置的資源」。就像在AWS的EC2上運(yùn)行應(yīng)用程式，并不能保證應(yīng)用程式的規(guī)�？蓴U(kuò)充性，充其量，只能在你需要伺服器、頻寬、儲(chǔ)存空間時(shí)，EC2能夠盡可能地動(dòng)態(tài)滿足你的需要。

　　所以說(shuō)，并不是把應(yīng)用程式搬上了「云端」，就必然獲得了規(guī)�？蓴U(kuò)充性，當(dāng)你只是在 IaaS 平臺(tái)上開(kāi)發(fā)時(shí)，是否具備規(guī)�？蓴U(kuò)充性，仍舊取決于你的系統(tǒng)架構(gòu)及特性。

　　不過(guò)，當(dāng)你是在PaaS上開(kāi)發(fā)時(shí)，情況又有所不同。PaaS平臺(tái)本身，會(huì)處理掉許多和規(guī)�？蓴U(kuò)充性相關(guān)的問(wèn)題，就像是在Google的App Engine上面，它所提供的資料存取操作，就不同于傳統(tǒng)的關(guān)聯(lián)式資料庫(kù)，而是以BigTable 為基礎(chǔ)的操作模式，這使得它有能力處理海量資料的存取。而立足在App Engine之上的應(yīng)用程式，自然而然，具備著更好的規(guī)模可擴(kuò)充性。

　　因此，在一個(gè)專門為了更大規(guī)模而設(shè)計(jì)的平臺(tái)上開(kāi)發(fā)，對(duì)于想要得到規(guī)�？蓴U(kuò)充性的應(yīng)用程式開(kāi)發(fā)者來(lái)說(shuō)，可以省去不少的力氣。其中像 Hadoop 便是一個(gè)為了大規(guī)模計(jì)算而設(shè)計(jì)出來(lái)的平臺(tái)，其中，利用所謂MapReduce的計(jì)算方式，可以將計(jì)算量分散到各個(gè)能提供計(jì)算的機(jī)器之上，集合眾多機(jī)器之力，因而在更短的時(shí)間內(nèi)，解決想要解決的計(jì)算問(wèn)題。而且，可以彈性投入所能配置的資源數(shù)量，投入的愈多，解決的愈快。例如，動(dòng)用更多的伺服器，就能更快的解決計(jì)算問(wèn)題。倘若預(yù)算不那么充分，也可以使用較少的機(jī)器，但耗費(fèi)較多的時(shí)間，而這正是規(guī)模可擴(kuò)充性的意義所在。

　　分散式計(jì)算的迷思

　　雖然說(shuō)，分散式計(jì)算的目的之一，就是希望通過(guò)將計(jì)算量分散到多部、不同的機(jī)器上，來(lái)增加整體的計(jì)算能力，但是，并不是所有的應(yīng)用程式都可以輕易拆散到多部機(jī)器之上去運(yùn)行，而且更重要的是，并不是將應(yīng)用程式拆分到多部機(jī)器之上，就必然帶來(lái)整體計(jì)算量的提升。

　　舉例來(lái)說(shuō)，倘若你將你的應(yīng)用程式拆成多份，并且同時(shí)傳輸至多部機(jī)器之上執(zhí)行，而這幾個(gè)程式之間需要溝通，也就是交換資料，它們之間甚至需要做同步（synchronization），以致于不同機(jī)器上的程式之間需要等待特定工作的完成，接著才能繼續(xù)執(zhí)行，那么，這樣的應(yīng)用程式就不見(jiàn)得具有規(guī)模可擴(kuò)充性，因?yàn)�，等待的環(huán)節(jié)，會(huì)造成規(guī)模無(wú)法隨著計(jì)算資源投入而跟著成長(zhǎng)的因素。

　　這說(shuō)明了，即使試著將計(jì)算拆分成為多份，并且置于多部機(jī)器上執(zhí)行，也不見(jiàn)得可以獲得多倍的效能改進(jìn)，很可能因?yàn)橛?jì)算模式的特性所限，而僅能獲得少數(shù)的效能成長(zhǎng)，而且隨著規(guī)模愈大，成長(zhǎng)的比例愈低。因此，如何拆分計(jì)算工作，使得它們被散布到多部不同的機(jī)器后，可以得到對(duì)應(yīng)的計(jì)算規(guī)模提升，就成了這件事情的核心議題。

　　通過(guò)分而治之的方式，將大問(wèn)題拆開(kāi)許多個(gè)小問(wèn)題，個(gè)個(gè)擊破，降低解決問(wèn)題的難度

　　像Hadoop的MapReduce，就是一種拆分計(jì)算工作的方式。想要通過(guò)拆分工作來(lái)解決計(jì)算問(wèn)題，傳統(tǒng)的「分而治之（Divide and Conquer）」其實(shí)，就是一種可行的方式。所謂的「分而治之」，就是將一個(gè)大問(wèn)題，拆解成多個(gè)小問(wèn)題，而分別解決這些小問(wèn)題的答案之后，再將這些答案通過(guò)某種方式合并起來(lái)，就可以得到大問(wèn)題的答案。這種方式常�？梢赃f回為之，也就是拆成比較小的問(wèn)題之后，還可以接著再繼續(xù)拆解，直到拆解至適合解決問(wèn)題的規(guī)模為止。

　　如果，我們可以運(yùn)用「分而治之」的方式來(lái)解決問(wèn)題，就很容易得到規(guī)�？蓴U(kuò)充性，因?yàn)�，我們可以將原始的�?wèn)題拆解成若干個(gè)較小規(guī)模的問(wèn)題，然后把這些問(wèn)題分別置放在不同的機(jī)器上解決，因?yàn)榻鉀Q這些小問(wèn)題的計(jì)算是互相獨(dú)立的、它們之間也不需要溝通，所以，當(dāng)可運(yùn)用的機(jī)器數(shù)量變多時(shí)，就可以將問(wèn)題的規(guī)模拆解的更小，使得在單一機(jī)器上解決它們的速度更快，更使得整體解決它們的時(shí)間可以縮短。而 MapReduce 正是此種「分而治之」的解題計(jì)算模式，當(dāng)你運(yùn)用MapReduce時(shí)，便得以此種方式來(lái)思考解決問(wèn)題的方法。

　　函數(shù)式程式設(shè)計(jì)開(kāi)始流行

　　在另一方面來(lái)看，你可能也會(huì)發(fā)現(xiàn)到，所謂「函數(shù)式（functional）」的程式設(shè)計(jì)方式，在這種「分而治之」的分散式計(jì)算模式里，開(kāi)始受歡迎了起來(lái)。函數(shù)式的程式語(yǔ)言已經(jīng)有幾十年的歷史，早期像 Lisp 的程式語(yǔ)言，主要是應(yīng)用在人工智慧的領(lǐng)域。但是，為什么在這個(gè)應(yīng)用領(lǐng)域里，反而流行起來(lái)了？

　　函數(shù)式的程式語(yǔ)言有一些特性，包括程式中是沒(méi)有狀態(tài)（stateless），而且每次函式之值被評(píng)估（或說(shuō)被執(zhí)行）時(shí)，是沒(méi)有副作用的（side effect ）。

　　所謂的副作用，代表的是函式被執(zhí)行時(shí)，除了它主要應(yīng)該達(dá)成的作用之外，還有一些其他附屬的效果，此即其副作用。主要的作用，就像是函式的回傳值，而副作用，則像是除了回傳函式之值以外，還同時(shí)改變?nèi)�域變�?shù)的值。你可以想像，函式的回傳值，除了被其輸入?yún)��?shù)所影響之外，還同時(shí)被其他的狀態(tài)，像是全域變數(shù)所影響時(shí)，會(huì)產(chǎn)生許多意想不到的結(jié)果。

　　但是如果我們從數(shù)學(xué)上的函數(shù)的角度來(lái)看，f（x） 之值，完全取決于 x ，沒(méi)任何 f（） 內(nèi)部的狀態(tài)或是外部的狀態(tài)足以在 x 相同時(shí)，造成 f（x） 之值不同。而所謂的函數(shù)式程式設(shè)計(jì)方式，便是在特性上有著此種取向，因此，它沒(méi)有狀態(tài)、也沒(méi)有副作用。

　　這種特性之所以能對(duì)分散式計(jì)算帶來(lái)好處，我想是因?yàn)樵谟羞@樣的特性之后，計(jì)算工作會(huì)更容易分配到不同的機(jī)器上去計(jì)算。正如數(shù)學(xué)的函數(shù)一樣，只要給定相同的輸入值，就一定會(huì)算出相同的輸出值。計(jì)算工作之間的相依性降低了，不論在那部機(jī)器上算、在什么時(shí)間點(diǎn)算，都不會(huì)影響到計(jì)算的結(jié)果。因此，當(dāng)以「分而治之」的原則來(lái)拆解計(jì)算工作，以進(jìn)行分散式的計(jì)算時(shí)，更容易拆解工作、更容易合成計(jì)算結(jié)果，以成為最后的結(jié)果。

　　通過(guò)一個(gè)更高階的云端計(jì)算平臺(tái)，以及計(jì)算模式，其實(shí)，可以讓程式設(shè)計(jì)者更容易的取得規(guī)�？蓴U(kuò)充性。而從現(xiàn)在的趨勢(shì)來(lái)看，函數(shù)式的設(shè)計(jì)方式，應(yīng)該還會(huì)再流行好一陣子。