介  紹

當(dāng)分布式系統(tǒng)編程成為你生活中的一部分時(shí)，你需要經(jīng)歷一段學(xué)習(xí)曲線。這篇文章描述了一下我當(dāng)前在這個(gè)領(lǐng)域大致屬于哪個(gè)層次，并希望能為你指出足夠多的錯(cuò)誤，從別人的錯(cuò)誤中學(xué)習(xí)，從而使你能以最優(yōu)的路徑通向成功。先聲明一下，我在1995年時(shí)達(dá)到第1級(jí)，我現(xiàn)在處于第3級(jí)。你自己屬于哪一級(jí)呢？

第0級(jí)：完全一無所知

每個(gè)程序員都從這一級(jí)開始。我不會(huì)在此浪費(fèi)太多口舌，因?yàn)檫@實(shí)在沒什么太多可說的。相反，我會(huì)引用一些我曾經(jīng)經(jīng)歷過的對(duì)話，為從未接觸過分布式系統(tǒng)的開發(fā)者們提供一些建議。

對(duì)話1：

NN：“在分布式系統(tǒng)中，復(fù)制是個(gè)很容易的操作，你只需要讓所有的結(jié)點(diǎn)同時(shí)存儲(chǔ)你要復(fù)制的東東就行了”。

另一段對(duì)話（從我記憶深處挖出來的）：

NN: “為了我們的第一人稱射擊游戲，我們得寫一個(gè)自己的網(wǎng)絡(luò)處理引擎。”

我：“為什么？”

NN: “雖然已經(jīng)有一些優(yōu)秀的商業(yè)引擎了，但獲取license的費(fèi)用非常高昂，我們不想為此買單。”

我：“你之前對(duì)于分布式系統(tǒng)有什么經(jīng)驗(yàn)嗎？”

NN：“是的，我之前寫過一個(gè)套接字服務(wù)器。”

我：“你覺得你要花多久能完成這個(gè)網(wǎng)絡(luò)引擎？”

NN：“我想2周吧。保險(xiǎn)起見，我計(jì)劃用4周時(shí)間。”

好吧，有時(shí)候還是保持沉默比較好。

第1級(jí)：RPC

RMI是一種非常強(qiáng)大的用來構(gòu)建大型系統(tǒng)的技術(shù)。事實(shí)上，這個(gè)技術(shù)用Java來描述的話，結(jié)合一些工作的例子可以在短短幾頁紙內(nèi)描述清楚。RMI技術(shù)非常令人振奮，而且它很容易使用。你可以調(diào)用你所能綁定到的任何服務(wù)器資源，而且你可以構(gòu)建出分布式的網(wǎng)絡(luò)對(duì)象。過去人們常常為構(gòu)建復(fù)雜的軟件系統(tǒng)犯難，現(xiàn)在RMI打開了這道大門。 —— Peter van der Linden, Just Java(第4版, Sun Microsystems)

我先聲明，我并不是說這本書很爛。我清楚的記得這本書讀起來很有趣（尤其是章節(jié)之間插入的軼聞），我曾經(jīng)學(xué)習(xí)Java的時(shí)候就是用的這本書（太久以前了，簡(jiǎn)直不像在一個(gè)時(shí)空里似的）。一般情況下，我覺得作者說的挺好。他對(duì)RMI的態(tài)度就是典型的分布式系統(tǒng)設(shè)計(jì)的第1級(jí)水平。處于這個(gè)等級(jí)的人對(duì)統(tǒng)一的對(duì)象有共同的看法。事實(shí)上，Waldo在他們著名的論文“a note on distributed computing”（1994）上曾深入描述過，這里我做下總結(jié)：

我所倡導(dǎo)的寫分布式應(yīng)用的策略可分為3個(gè)階段。第1階段，寫這個(gè)應(yīng)用時(shí)不用擔(dān)心對(duì)象存儲(chǔ)的位置，以及它們之間的通訊如何實(shí)現(xiàn)。第2階段，通過具體化對(duì)象的位置以及通訊方法來調(diào)整程序性能。第3階段，真槍實(shí)彈的測(cè)試（網(wǎng)絡(luò)隔離、機(jī)器宕機(jī)等各種情況）。這里的思想就是，不管一個(gè)調(diào)用是本地的還是遠(yuǎn)程的，對(duì)程序的正確性都不會(huì)產(chǎn)生任何影響。

同樣還是這篇論文，隨后進(jìn)一步挖掘了這個(gè)主題并展示了其中的問題。這個(gè)觀點(diǎn)是錯(cuò)誤的，而且已經(jīng)錯(cuò)了快20年。不管如何，如果說Java RMI達(dá)成了一個(gè)目標(biāo)，那就是：就算你從等式中拿掉傳輸協(xié)議、命名、綁定以及序列化，它還是不成立。能記得起CORBA的老程序員們同樣也會(huì)記得它也是不好使的，但他們有一個(gè)借口：CORBA還在同各種底層的問題纏斗中。Java RMI將所有這些都拋開了，但使剩下的問題變得更為突出。其中有兩點(diǎn)，第一點(diǎn)純粹就是個(gè)麻煩：

網(wǎng)絡(luò)不是透明的

讓我們看看這段簡(jiǎn)單的Java RMI代碼示例（同樣取自Just Java一書）

public interface WeatherIntf extends java.rmi.Remote {  
    public String getWeather() throws java.rmi.RemoteException;  
} 

想要使用天氣服務(wù)的客戶端需要這樣做：

try {  
    Remote robj = Naming.lookup(“//localhost/WeatherServer”);  
    WeatherIntf weatherserver = (WeatherInf)robj;  
    String forecast = weatherserver.getWeather();  
    System.out.println(“The weather will be “ + forecast);  
}catch(Exception e) {  
    System.out.println(e.getMessage()); 

客戶端代碼需要將RemoteExceptions考慮在內(nèi)。如果你想看看你究竟會(huì)遇到什么樣的異常錯(cuò)誤，可以看看那20多個(gè)子類的定義。這樣你的代碼就會(huì)變得丑陋，好吧，這個(gè)我們就忍了。

局部性錯(cuò)誤

RMI的真正問題在于這些調(diào)用可能會(huì)出現(xiàn)局部性失敗的情況。比如，調(diào)用可能會(huì)在對(duì)其他層的請(qǐng)求操作執(zhí)行前失敗，又或者請(qǐng)求成功了，但之后的返回值又不正確。引起這類局部性失敗的原因非常多。其實(shí)，這些故障模式正是分布式系統(tǒng)特性的明確定義：

如果這個(gè)方法只是去檢索天氣預(yù)報(bào)，出現(xiàn)問題時(shí)你可以簡(jiǎn)單的進(jìn)行重試，但如果你想遞增一個(gè)計(jì)數(shù)器，重試可能會(huì)導(dǎo)致產(chǎn)生0到2次的更新，結(jié)果就不確定了。這個(gè)解決方案應(yīng)該來自冪等操作，但構(gòu)建這樣的操作并不總是可行的。此外，因?yàn)槟銢Q定改變方法調(diào)用的語義，那你基本上就承認(rèn)了RMI與本地調(diào)用是不同的。而這也就承認(rèn)了RMI實(shí)際上是個(gè)悖論。

不論什么情況下，這種范式都是失敗的。因?yàn)榫W(wǎng)絡(luò)的透明度和分布式系統(tǒng)的架構(gòu)抽象從來就是無法實(shí)現(xiàn)的。這也表明了某些軟件所采用的方法比其他軟件為此所受到的影響更多。Scrum的一些變種方法中傾向于做原型化。原型更集中于“好的方面”（happy path），而好的方面通常都不是問題所在之處。這基本上意味著你將永遠(yuǎn)停留在第1級(jí)的水平。（不好意思，我知道這是個(gè)小小的打擊）

那些脫離了第一級(jí)水平的人懂得對(duì)于需要解決的這個(gè)問題，我們要有足夠的尊重。他們摒棄了網(wǎng)絡(luò)透明化的思想，從戰(zhàn)略性的角度來處理局部性失敗的問題。

第2級(jí)：分布式算法 + 異步消息傳遞 + 語言級(jí)支持

OK，你已經(jīng)學(xué)習(xí)了分布式計(jì)算中的悖論是什么。你決定吞下這顆子彈，然后對(duì)消息傳遞機(jī)制建模，以此顯式地控制出現(xiàn)失敗的情況。你將應(yīng)用分為兩個(gè)層次，底層負(fù)責(zé)網(wǎng)絡(luò)和消息傳遞，而上層處理消息的到達(dá)，以及需要處理的各種請(qǐng)求。

這個(gè)上層實(shí)現(xiàn)了一種分布式狀態(tài)機(jī)，如果你去問設(shè)計(jì)者這個(gè)狀態(tài)機(jī)是用來做什么的，他們可能會(huì)這樣回答你：這是建立在TCP之上的一個(gè)Multi-Paxos算法實(shí)現(xiàn)。

明智的開發(fā)，這里用到的策略可以歸結(jié)為：程序員首先在本地主要采用線程來模擬不同的進(jìn)程來開發(fā)這個(gè)應(yīng)用。每個(gè)線程運(yùn)行分布式狀態(tài)機(jī)的一個(gè)部分，基本上就是負(fù)責(zé)運(yùn)行一段消息處理的循環(huán)。一旦這個(gè)應(yīng)用是本地完整的且運(yùn)行正確，就可以在遠(yuǎn)端的計(jì)算機(jī)上用真正的進(jìn)程來取代線程。到這個(gè)階段，除去網(wǎng)絡(luò)中可能出現(xiàn)的問題外，這個(gè)分布式應(yīng)用已經(jīng)可以正常工作了。到容錯(cuò)階段時(shí)，可以通過配置每個(gè)分布式實(shí)體來正確反映故障的方式來達(dá)成，這種方式很直接。（我引述自“A Fault Tolerant Abstraction for Transparent Distributed Programming”）

因?yàn)榉植际綘顟B(tài)機(jī)的存在，局部性故障可以通過設(shè)計(jì)來解決。對(duì)于線程，其實(shí)也有很多種選擇，但協(xié)程（coroutines）更適合（在各種不同的編程語言中，協(xié)程也被稱為纖程fiber，輕量級(jí)線程，微線程或者就叫線程），因?yàn)閰f(xié)程允許我們對(duì)并發(fā)行為有更細(xì)粒度的控制。

結(jié)合“C代碼并不會(huì)使網(wǎng)絡(luò)變得更快”的論點(diǎn)，你可以轉(zhuǎn)移到在語言級(jí)支持這種細(xì)粒度并發(fā)控制的編程語言中去。流行的選擇如下（排名不分先后）注意，這些編程語言往往都是函數(shù)式的：

1.  Mozart

2.  Erlang

3. OCaml

4. Haskell

5. Stackless

6.  Clojure

舉個(gè)例子，下面讓我們看看在Erlang中這種并發(fā)控制的代碼看起來是怎樣的（取自Erlang concurrent programming）

-module(tut15)  
-export([start/0, ping/2, pong/0]).  
ping(0, Pong_PID) ->  
    Pong_PID ! finished,  
    io:format(“ping finished~n”, []);  
   
ping(N, Pong_PID)->  
    Pong_PID ! {ping, self()},  
    receive  
        pong ->  
        io:format(“Ping received pong~n”, [])  
    end,  
    ping(N – 1, Pong_PID).  
   
pong() ->  
    receive  
    finished ->  
        io:format(“Pong finished~n”, []);  
    {ping, Ping_PID} ->  
        io:format(“Pong received ping~n”, []),  
        Ping_PID ! pong,  
        pong()  
    end.  
   
start() ->  
    Pong_PID = spawn(tut15, pong, []),  
    spawn(tut15, ping, [3, Pong_PID]). 

這看起來絕對(duì)是對(duì)舊有的RPC機(jī)制的一個(gè)重大提升。現(xiàn)在你可以推想一下，如果有消息沒有到達(dá)時(shí)會(huì)發(fā)生什么事情了。Erlang還有附加的超時(shí)消息以及一個(gè)語言內(nèi)建的“超時(shí)”組件，可以使你以一種優(yōu)雅的方式來處理超時(shí)。

現(xiàn)在，你選擇了你要采用的策略，選擇了恰當(dāng)?shù)姆植际剿惴ㄒ约昂线m的編程語言，然后就可以開干了。你很自信能駕馭分布式編程這頭野獸了，因?yàn)槟阍僖膊皇堑谝患?jí)的水平了。

哎呀，可惜的是這一路上并非風(fēng)平浪靜。過了一段時(shí)間，當(dāng)?shù)谝粋€(gè)版本發(fā)布后，你將陷入泥潭之中。人們會(huì)告訴你，你的分布式應(yīng)用有些問題。問題報(bào)告中的主題全都是和變化有關(guān)的。開始時(shí)會(huì)出現(xiàn)“有時(shí)”或者“一次”這樣的表示頻率的詞，之后的描述變成了：系統(tǒng)處于不期望的狀態(tài)，卡住不動(dòng)了。如果夠幸運(yùn)，你有足夠的log信息，可以開始著手檢查這些日志。稍后，你發(fā)現(xiàn)是一系列不幸的事件序列造成了報(bào)告中所描述的情況。確實(shí)，這是個(gè)新的問題。你從來沒有考慮過這些，而且在你做大量的測(cè)試和模擬時(shí)問題從未出現(xiàn)過。所以，你修改代碼以將這種情況也納入考慮范圍。

因?yàn)槟阍囍翱紤]，你決定構(gòu)建一個(gè)“猴子”組件，它以偽隨機(jī)的方式讓你的分布式系統(tǒng)做些愚蠢的事情。“猴子”在籠子里使勁撲騰著，很快你會(huì)發(fā)現(xiàn)在很多場(chǎng)景下都會(huì)導(dǎo)致出現(xiàn)不期望的情況，比如系統(tǒng)卡住了，或者甚至更糟糕的情況：系統(tǒng)出現(xiàn)不一致的狀態(tài)，而這在分布式系統(tǒng)中是永遠(yuǎn)也不應(yīng)該發(fā)生的事情。

構(gòu)建一個(gè)“猴子”是很棒的主意，而且它確實(shí)能減少遇到那些你從未在這個(gè)領(lǐng)域內(nèi)碰到過的怪事的幾率。因?yàn)槟阆嘈牛薷囊粋€(gè)bug必須和發(fā)現(xiàn)這個(gè)bug的測(cè)試用例聯(lián)系起來，現(xiàn)在需要回歸測(cè)試這個(gè)用例，以證明bug的消除。你現(xiàn)在只需要再構(gòu)建一次這個(gè)測(cè)試用例就可以了?？墒乾F(xiàn)在的問題在于，如果說并非不可能的話，要重現(xiàn)這個(gè)錯(cuò)誤的場(chǎng)景起碼是很困難的。你向上帝祈禱，得到的啟示是：當(dāng)心存疑慮時(shí)，就使用暴力法吧。因此，你構(gòu)建一個(gè)測(cè)試用例，然后讓它跑上無數(shù)次，以此來彌補(bǔ)這極小的失敗概率。這會(huì)使你解決bug的過程變得緩慢，而且你的測(cè)試套件會(huì)變得笨重。通過對(duì)你的測(cè)試集做分而治之的處理，你不得不再次做一些補(bǔ)償。無論如何，經(jīng)過在時(shí)間和精力上的大量投入之后，你終于設(shè)法得到了一個(gè)較為穩(wěn)定的系統(tǒng)。

你在第2級(jí)已經(jīng)到頂了，如果沒有新的啟示，你將永遠(yuǎn)卡在這一級(jí)。

第3級(jí)：分布式算法 + 異步消息傳遞 + 純函數(shù)式

我們需要花點(diǎn)時(shí)間才能意識(shí)到：長(zhǎng)時(shí)間運(yùn)行“猴子”以此發(fā)現(xiàn)系統(tǒng)中的缺陷然后再結(jié)合暴力法來重現(xiàn)它們，這種做法并不可取。使用暴力法重現(xiàn)只會(huì)顯示出你的無知。你需要的關(guān)鍵性的啟示之一是，如果你可以只將等式中的不確定性拿掉的話，你就可以完美的對(duì)每一種場(chǎng)景做重現(xiàn)了。第2級(jí)分布式編程的一個(gè)重大的缺點(diǎn)是：你的并發(fā)模型往往會(huì)成為你代碼庫中的病毒。你希望有細(xì)粒度的并發(fā)控制，好吧，你得到了，代碼里到處都是。因此是并發(fā)導(dǎo)致了不確定性，而不確定性造成了麻煩。因此必須得把并發(fā)給踢出去。可是你又不能拋棄并發(fā)，你需要它。那么，你一定要禁止把并發(fā)和你的分布式狀態(tài)機(jī)結(jié)合在一起。換句話說，你的分布式狀態(tài)機(jī)必須成為純函數(shù)式的。沒有IO操作，沒有并發(fā)，什么都沒有。你的狀態(tài)機(jī)特征看起來應(yīng)該是這樣的：

module type SM = sig  
    type state  
    type action  
    type msg  
    val step: msg -> state -> action * state  
end 

你傳入一個(gè)消息和一個(gè)狀態(tài)，你得到一個(gè)操作和一個(gè)結(jié)果狀態(tài)。操作基本上就是任何試著改變外部世界的東西，需要一定的時(shí)間來完成，嘗試的過程中可能會(huì)失敗。典型的操作有：

發(fā)送一個(gè)消息

安排一次超時(shí)

將數(shù)據(jù)存儲(chǔ)在持久性的存儲(chǔ)介質(zhì)內(nèi)

…

這里要意識(shí)到的重要部分是：你只能通過一個(gè)新的消息來得到新的狀態(tài)，再無其他。在這種嚴(yán)格的規(guī)定下所得到的好處是很多的。完美的控制，完美的重現(xiàn)能力以及完美的可追蹤性。為此而得到的開銷也同樣存在，你將被迫使所有的操作都變得具體化。而這些基本上就是為了減少程序復(fù)雜性而附加的一層間接。你還需要將每一個(gè)你關(guān)心的外部世界變化都建模為一個(gè)消息。

相比第2級(jí)的分布式編程，另一個(gè)改變?cè)谟诳刂屏?。在?級(jí)中，客戶端會(huì)嘗試強(qiáng)制更新并動(dòng)態(tài)設(shè)置狀態(tài)。而在這里，分布式狀態(tài)機(jī)假定有完全的控制力，并且只有當(dāng)它準(zhǔn)備就緒，可以做些有用的事情時(shí)才會(huì)考慮客戶端的請(qǐng)求。因此這些必須分離開來。

如果你把這些道理解釋給一個(gè)2級(jí)的分布式系統(tǒng)架構(gòu)師聽，他可能或多或少的會(huì)把這個(gè)當(dāng)成一種替代方案。然而，你需要經(jīng)歷足夠多的痛苦之后才會(huì)意識(shí)到這是唯一可行的選擇，我們姑且把這些痛苦稱為經(jīng)驗(yàn)吧。

第4級(jí) 對(duì)分布式系統(tǒng)領(lǐng)域的深刻理解：快樂，好心態(tài)，好好睡一覺

老實(shí)說，我現(xiàn)在只是第3級(jí)水平，我也不知道在這一級(jí)里有什么新鮮玩意。我深信，函數(shù)式編程和異步消息傳遞是分布式系統(tǒng)謎題的一部分，但這些還不夠。

請(qǐng)?jiān)试S我重申我所反對(duì)的東西。首先，我希望我的分布式算法實(shí)現(xiàn)能夠涵蓋到所有的可能情況。這對(duì)我而言是個(gè)大問題，我已經(jīng)在系統(tǒng)部署的問題上犧牲掉了很多睡眠時(shí)間。大部分問題都是PEBKAC類的（Problem Exists Between Keyboard And Chair意指用戶引起的錯(cuò)誤），但有一些確是真正的問題，這給我造成了一些挫敗感。知道自己實(shí)現(xiàn)的健壯性程度是很好的。我應(yīng)該試試證明一下那些定理嗎？我應(yīng)該做更詳盡的測(cè)試嗎？我不知道。

附帶提一下，GitHub上有一個(gè)稱為baardskeerder的僅用于插入操作的B-樹庫，我們知道可以通過詳盡的生成插入/刪除排列并斷言它們的正確性之后，我們就可以涵蓋到所有的情況。但這里，并沒有那么簡(jiǎn)單，而且我對(duì)于要對(duì)整個(gè)代碼庫做Coqify處理（Coq是一個(gè)正式的證明管理系統(tǒng)，它在一種半交互式的環(huán)境下提供了一個(gè)正式的語言用來編寫數(shù)學(xué)定義、可執(zhí)行的算法和定理，用計(jì)算機(jī)來做檢查證明，這里作者生造出了Coqify這個(gè)詞）還有些猶豫。

第二，為了保持清晰和簡(jiǎn)單，我決定不去碰其它一些正交性的需求。比如，服務(wù)發(fā)現(xiàn)、認(rèn)證、授權(quán)、私密性以及性能。

說到性能，我們也許是幸運(yùn)的，至少異步消息傳遞似乎與性能方面并不產(chǎn)生矛盾。安全性則完全是一個(gè)XX（作者真的爆粗口了…），因?yàn)樗鼛缀跚袛嗔怂心闼龅氖虑?。有些人把安全性看成是一種調(diào)味醬汁，你只要把它倒在你的應(yīng)用程序上就可以保證安全了。哎，在這方面我從未取得過成功，而且現(xiàn)在我也認(rèn)為這個(gè)問題需要在設(shè)計(jì)的最初階段從宏觀的角度策略性的去分析解決。

結(jié)  語

開發(fā)出健壯的分布式系統(tǒng)是個(gè)頗為棘手的問題，實(shí)際上根本沒有完美的解決方案，或者說至少?zèng)]有讓我覺得完全滿意的解決方案。我敢肯定分布式系統(tǒng)的重要性將隨著處理器和其它一切事物之間的延遲增加而顯著提高。這一結(jié)果使得這種類型的應(yīng)用程序開發(fā)變得愈發(fā)繁榮。

至于分布式編程的第4級(jí)，也許我該去問問Peter Van Roy。這么些年來，我閱讀了很多他寫的論文，這些論文對(duì)于我自己的一些錯(cuò)誤認(rèn)識(shí)給了很多啟示。關(guān)于這些啟示的缺點(diǎn)嘛，你常常在大部分時(shí)間里看到別人在重復(fù)自己的錯(cuò)誤，但我無法說服他們應(yīng)該換種方式去做。

也許，這是因?yàn)槲覠o法提供他們想要的那種靈丹妙藥。他們就想要RPC，而且他們希望這樣能搞定問題。這是固執(zhí)的…就像宗教信仰一樣。

英文原文：rslootma

本文來自：http://blog.jobbole.com/20304/