當(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級，我現(xiàn)在處于第3級。你自己屬于哪一級呢？

第0級：完全一無所知

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

對話1：

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

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

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

我：“為什么？”

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

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

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

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

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

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

[[78428]]#p#

第1級：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ò)對象。過去人們常常為構(gòu)建復(fù)雜的軟件系統(tǒng)犯難，現(xiàn)在RMI打開了這道大 門。    ——   Peter van der Linden, Just Java(第4版, Sun Microsystems)

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

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

讓我們看看這段簡單的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ì)在對其他層的請求操作執(zhí)行前失敗，又或者請求成功了，但之后的返回值又不正確。引起這類局部性失敗的原因非常多。其實(shí)，這些故障模式正是分布式系統(tǒng)特性的明確定義：

“分布式系統(tǒng)就是某一臺你根本意識不到其存在的計(jì)算機(jī)，它的故障會(huì)造成你的計(jì)算機(jī)無法正常使用。”  ——  Leslie Lamport

如果這個(gè)方法只是去檢索天氣預(yù)報(bào)，出現(xiàn)問題時(shí)你可以簡單的進(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級的水平。（不好意思，我知道這是個(gè)小小的打擊）

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

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

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

這個(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ì)來解決。對于線程，其實(shí)也有很多種選擇，但協(xié)程（coroutines）更適合（在各種不同的編程語言中，協(xié)程也被稱為纖程fiber，輕量級線程，微線程或者就叫線程），因?yàn)閰f(xié)程允許我們對并發(fā)行為有更細(xì)粒度的控制。

結(jié)合“C代碼并不會(huì)使網(wǎng)絡(luò)變得更快”的論點(diǎn)，你可以轉(zhuǎn)移到在語言級支持這種細(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 ]). 

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

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

哎呀，可惜的是這一路上并非風(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è)新的問題。你從來沒有考慮過這 些，而且在你做大量的測試和模擬時(shí)問題從未出現(xiàn)過。所以，你修改代碼以將這種情況也納入考慮范圍。

因?yàn)槟阍囍翱紤]，你決定構(gòu)建一個(gè)“猴子”組件，它以偽隨機(jī)的方式讓你的分布式系統(tǒng)做些愚蠢的事情。“猴子”在籠子里使勁撲騰著，很快你會(huì)發(fā)現(xiàn)在很多場景下都會(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 的測試用例聯(lián)系起來，現(xiàn)在需要回歸測試這個(gè)用例，以證明bug的消除。你現(xiàn)在只需要再構(gòu)建一次這個(gè)測試用例就可以了?？墒乾F(xiàn)在的問題在于，如果說并非不可 能的話，要重現(xiàn)這個(gè)錯(cuò)誤的場景起碼是很困難的。你向上帝祈禱，得到的啟示是：當(dāng)心存疑慮時(shí)，就使用暴力法吧。因此，你構(gòu)建一個(gè)測試用例，然后讓它跑上無數(shù) 次，以此來彌補(bǔ)這極小的失敗概率。這會(huì)使你解決bug的過程變得緩慢，而且你的測試套件會(huì)變得笨重。通過對你的測試集做分而治之的處理，你不得不再次做一 些補(bǔ)償。無論如何，經(jīng)過在時(shí)間和精力上的大量投入之后，你終于設(shè)法得到了一個(gè)較為穩(wěn)定的系統(tǒng)。

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

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

我們需要花點(diǎn)時(shí)間才能意識到：長時(shí)間運(yùn)行“猴子”以此發(fā)現(xiàn)系統(tǒng)中的缺陷然后再結(jié)合暴力法來重現(xiàn)它們，這種做法并不可取。使用暴力法重現(xiàn)只會(huì)顯示出你 的無知。你需要的關(guān)鍵性的啟示之一是，如果你可以只將等式中的不確定性拿掉的話，你就可以完美的對每一種場景做重現(xiàn)了。第2級分布式編程的一個(gè)重大的缺點(diǎn) 是：你的并發(fā)模型往往會(huì)成為你代碼庫中的病毒。你希望有細(xì)粒度的并發(fā)控制，好吧，你得到了，代碼里到處都是。因此是并發(fā)導(dǎo)致了不確定性，而不確定性造成了 麻煩。因此必須得把并發(fā)給踢出去?？墒悄阌植荒軖仐壊l(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ì)失敗。典型的操作有：

1. 發(fā)送一個(gè)消息
2. 安排一次超時(shí)
3. 將數(shù)據(jù)存儲(chǔ)在持久性的存儲(chǔ)介質(zhì)內(nèi)
4. …

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

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

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

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

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

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

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

第二，為了保持清晰和簡單，我決定不去碰其它一些正交性的需求。比如，服務(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級，也許我該去問問Peter Van Roy。這么些年來，我閱讀了很多他寫的論文，這些論文對于我自己的一些錯(cuò)誤認(rèn)識給了很多啟示。關(guān)于這些啟示的缺點(diǎn)嘛，你常常在大部分時(shí)間里看到別人在重復(fù)自己的錯(cuò)誤，但我無法說服他們應(yīng)該換種方式去做。

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