分布式系統(tǒng)編程，你到哪一級了？
介 紹
當(dāng)分布式系統(tǒng)編程成為你生活中的一部分時，你需要經(jīng)歷一段學(xué)習(xí)曲線。這篇文章描述了一下我當(dāng)前在這個領(lǐng)域大致屬于哪個層次，并希望能為你指出足夠多的錯誤，從別人的錯誤中學(xué)習(xí)，從而使你能以最優(yōu)的路徑通向成功。先聲明一下，我在1995年時達(dá)到第1級，我現(xiàn)在處于第3級。你自己屬于哪一級呢？
第0級：完全一無所知
每個程序員都從這一級開始。我不會在此浪費太多口舌，因為這實在沒什么太多可說的。相反，我會引用一些我曾經(jīng)經(jīng)歷過的對話，為從未接觸過分布式系統(tǒng)的開發(fā)者們提供一些建議。
對話1：
NN：“在分布式系統(tǒng)中，復(fù)制是個很容易的操作，你只需要讓所有的結(jié)點同時存儲你要復(fù)制的東東就行了”。
另一段對話（從我記憶深處挖出來的）：
NN: “為了我們的第一人稱射擊游戲，我們得寫一個自己的網(wǎng)絡(luò)處理引擎。”
我：“為什么？”
NN: “雖然已經(jīng)有一些優(yōu)秀的商業(yè)引擎了，但獲取license的費用非常高昂，我們不想為此買單。”
我：“你之前對于分布式系統(tǒng)有什么經(jīng)驗嗎？”
NN：“是的，我之前寫過一個套接字服務(wù)器。”
我：“你覺得你要花多久能完成這個網(wǎng)絡(luò)引擎？”
NN：“我想2周吧。保險起見，我計劃用4周時間。”
好吧，有時候還是保持沉默比較好。
第1級：RPC
RMI是一種非常強(qiáng)大的用來構(gòu)建大型系統(tǒng)的技術(shù)。事實上，這個技術(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的時候就是用的這本書（太久以前了，簡直不像在一個時空里似的）。一般情況下，我覺得作者說的挺好。他對RMI的態(tài)度就是典型的分布式系統(tǒng)設(shè)計的第1級水平。處于這個等級的人對統(tǒng)一的對象有共同的看法。事實上，Waldo在他們著名的論文“a note on distributed computing”（1994）上曾深入描述過，這里我做下總結(jié)：
我所倡導(dǎo)的寫分布式應(yīng)用的策略可分為3個階段。第1階段，寫這個應(yīng)用時不用擔(dān)心對象存儲的位置，以及它們之間的通訊如何實現(xiàn)。第2階段，通過具體化對象的位置以及通訊方法來調(diào)整程序性能。第3階段，真槍實彈的測試（網(wǎng)絡(luò)隔離、機(jī)器宕機(jī)等各種情況）。這里的思想就是，不管一個調(diào)用是本地的還是遠(yuǎn)程的，對程序的正確性都不會產(chǎn)生任何影響。
同樣還是這篇論文，隨后進(jìn)一步挖掘了這個主題并展示了其中的問題。這個觀點是錯誤的，而且已經(jīng)錯了快20年。不管如何，如果說Java RMI達(dá)成了一個目標(biāo)，那就是：就算你從等式中拿掉傳輸協(xié)議、命名、綁定以及序列化，它還是不成立。能記得起CORBA的老程序員們同樣也會記得它也是不好使的，但他們有一個借口：CORBA還在同各種底層的問題纏斗中。Java RMI將所有這些都拋開了，但使剩下的問題變得更為突出。其中有兩點，第一點純粹就是個麻煩：
網(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)。如果你想看看你究竟會遇到什么樣的異常錯誤，可以看看那20多個子類的定義。這樣你的代碼就會變得丑陋，好吧，這個我們就忍了。
局部性錯誤
RMI的真正問題在于這些調(diào)用可能會出現(xiàn)局部性失敗的情況。比如，調(diào)用可能會在對其他層的請求操作執(zhí)行前失敗，又或者請求成功了，但之后的返回值又不正確。引起這類局部性失敗的原因非常多。其實，這些故障模式正是分布式系統(tǒng)特性的明確定義：
| “分布式系統(tǒng)就是某一臺你根本意識不到其存在的計算機(jī)，它的故障會造成你的計算機(jī)無法正常使用。” —— Leslie Lamport |
如果這個方法只是去檢索天氣預(yù)報，出現(xiàn)問題時你可以簡單的進(jìn)行重試，但如果你想遞增一個計數(shù)器，重試可能會導(dǎo)致產(chǎn)生0到2次的更新，結(jié)果就不確定了。這個解決方案應(yīng)該來自冪等操作，但構(gòu)建這樣的操作并不總是可行的。此外，因為你決定改變方法調(diào)用的語義，那你基本上就承認(rèn)了RMI與本地調(diào)用是不同的。而這也就承認(rèn)了RMI實際上是個悖論。
不論什么情況下，這種范式都是失敗的。因為網(wǎng)絡(luò)的透明度和分布式系統(tǒng)的架構(gòu)抽象從來就是無法實現(xiàn)的。這也表明了某些軟件所采用的方法比其他軟件為此所受到的影響更多。Scrum的一些變種方法中傾向于做原型化。原型更集中于“好的方面”（happy path），而好的方面通常都不是問題所在之處。這基本上意味著你將永遠(yuǎn)停留在第1級的水平。（不好意思，我知道這是個小小的打擊）
那些脫離了第一級水平的人懂得對于需要解決的這個問題，我們要有足夠的尊重。他們摒棄了網(wǎng)絡(luò)透明化的思想，從戰(zhàn)略性的角度來處理局部性失敗的問題。
第2級：分布式算法 + 異步消息傳遞 + 語言級支持
OK，你已經(jīng)學(xué)習(xí)了分布式計算中的悖論是什么。你決定吞下這顆子彈，然后對消息傳遞機(jī)制建模，以此顯式地控制出現(xiàn)失敗的情況。你將應(yīng)用分為兩個層次，底層負(fù)責(zé)網(wǎng)絡(luò)和消息傳遞，而上層處理消息的到達(dá)，以及需要處理的各種請求。
這個上層實現(xiàn)了一種分布式狀態(tài)機(jī)，如果你去問設(shè)計者這個狀態(tài)機(jī)是用來做什么的，他們可能會這樣回答你：這是建立在TCP之上的一個Multi-Paxos算法實現(xiàn)。
明智的開發(fā)，這里用到的策略可以歸結(jié)為：程序員首先在本地主要采用線程來模擬不同的進(jìn)程來開發(fā)這個應(yīng)用。每個線程運行分布式狀態(tài)機(jī)的一個部分，基本上就是負(fù)責(zé)運行一段消息處理的循環(huán)。一旦這個應(yīng)用是本地完整的且運行正確，就可以在遠(yuǎn)端的計算機(jī)上用真正的進(jìn)程來取代線程。到這個階段，除去網(wǎng)絡(luò)中可能出現(xiàn)的問題外，這個分布式應(yīng)用已經(jīng)可以正常工作了。到容錯階段時，可以通過配置每個分布式實體來正確反映故障的方式來達(dá)成，這種方式很直接。（我引述自“A Fault Tolerant Abstraction for Transparent Distributed Programming”）
因為分布式狀態(tài)機(jī)的存在，局部性故障可以通過設(shè)計來解決。對于線程，其實也有很多種選擇，但協(xié)程（coroutines）更適合（在各種不同的編程語言中，協(xié)程也被稱為纖程fiber，輕量級線程，微線程或者就叫線程），因為協(xié)程允許我們對并發(fā)行為有更細(xì)粒度的控制。
結(jié)合“C代碼并不會使網(wǎng)絡(luò)變得更快”的論點，你可以轉(zhuǎn)移到在語言級支持這種細(xì)粒度并發(fā)控制的編程語言中去。流行的選擇如下（排名不分先后）注意，這些編程語言往往都是函數(shù)式的：
1. Mozart
2. Erlang
3. OCaml
4. Haskell
5. Stackless
6. Clojure
舉個例子，下面讓我們看看在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ī)制的一個重大提升。現(xiàn)在你可以推想一下，如果有消息沒有到達(dá)時會發(fā)生什么事情了。Erlang還有附加的超時消息以及一個語言內(nèi)建的“超時”組件，可以使你以一種優(yōu)雅的方式來處理超時。
現(xiàn)在，你選擇了你要采用的策略，選擇了恰當(dāng)?shù)姆植际剿惴ㄒ约昂线m的編程語言，然后就可以開干了。你很自信能駕馭分布式編程這頭野獸了，因為你再也不是第一級的水平了。
哎呀，可惜的是這一路上并非風(fēng)平浪靜。過了一段時間，當(dāng)?shù)谝粋€版本發(fā)布后，你將陷入泥潭之中。人們會告訴你，你的分布式應(yīng)用有些問題。問題報告中的主題全都是和變化有關(guān)的。開始時會出現(xiàn)“有時”或者“一次”這樣的表示頻率的詞，之后的描述變成了：系統(tǒng)處于不期望的狀態(tài)，卡住不動了。如果夠幸運，你有足夠的log信息，可以開始著手檢查這些日志。稍后，你發(fā)現(xiàn)是一系列不幸的事件序列造成了報告中所描述的情況。確實，這是個新的問題。你從來沒有考慮過這些，而且在你做大量的測試和模擬時問題從未出現(xiàn)過。所以，你修改代碼以將這種情況也納入考慮范圍。
因為你試著要超前考慮，你決定構(gòu)建一個“猴子”組件，它以偽隨機(jī)的方式讓你的分布式系統(tǒng)做些愚蠢的事情。“猴子”在籠子里使勁撲騰著，很快你會發(fā)現(xiàn)在很多場景下都會導(dǎo)致出現(xiàn)不期望的情況，比如系統(tǒng)卡住了，或者甚至更糟糕的情況：系統(tǒng)出現(xiàn)不一致的狀態(tài)，而這在分布式系統(tǒng)中是永遠(yuǎn)也不應(yīng)該發(fā)生的事情。
構(gòu)建一個“猴子”是很棒的主意，而且它確實能減少遇到那些你從未在這個領(lǐng)域內(nèi)碰到過的怪事的幾率。因為你相信，修改一個bug必須和發(fā)現(xiàn)這個bug的測試用例聯(lián)系起來，現(xiàn)在需要回歸測試這個用例，以證明bug的消除。你現(xiàn)在只需要再構(gòu)建一次這個測試用例就可以了。可是現(xiàn)在的問題在于，如果說并非不可能的話，要重現(xiàn)這個錯誤的場景起碼是很困難的。你向上帝祈禱，得到的啟示是：當(dāng)心存疑慮時，就使用暴力法吧。因此，你構(gòu)建一個測試用例，然后讓它跑上無數(shù)次，以此來彌補這極小的失敗概率。這會使你解決bug的過程變得緩慢，而且你的測試套件會變得笨重。通過對你的測試集做分而治之的處理，你不得不再次做一些補償。無論如何，經(jīng)過在時間和精力上的大量投入之后，你終于設(shè)法得到了一個較為穩(wěn)定的系統(tǒng)。
你在第2級已經(jīng)到頂了，如果沒有新的啟示，你將永遠(yuǎn)卡在這一級。
第3級：分布式算法 + 異步消息傳遞 + 純函數(shù)式
我們需要花點時間才能意識到：長時間運行“猴子”以此發(fā)現(xiàn)系統(tǒng)中的缺陷然后再結(jié)合暴力法來重現(xiàn)它們，這種做法并不可取。使用暴力法重現(xiàn)只會顯示出你的無知。你需要的關(guān)鍵性的啟示之一是，如果你可以只將等式中的不確定性拿掉的話，你就可以完美的對每一種場景做重現(xiàn)了。第2級分布式編程的一個重大的缺點是：你的并發(fā)模型往往會成為你代碼庫中的病毒。你希望有細(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
你傳入一個消息和一個狀態(tài)，你得到一個操作和一個結(jié)果狀態(tài)。操作基本上就是任何試著改變外部世界的東西，需要一定的時間來完成，嘗試的過程中可能會失敗。典型的操作有：
發(fā)送一個消息
安排一次超時
將數(shù)據(jù)存儲在持久性的存儲介質(zhì)內(nèi)
…
這里要意識到的重要部分是：你只能通過一個新的消息來得到新的狀態(tài)，再無其他。在這種嚴(yán)格的規(guī)定下所得到的好處是很多的。完美的控制，完美的重現(xiàn)能力以及完美的可追蹤性。為此而得到的開銷也同樣存在，你將被迫使所有的操作都變得具體化。而這些基本上就是為了減少程序復(fù)雜性而附加的一層間接。你還需要將每一個你關(guān)心的外部世界變化都建模為一個消息。
相比第2級的分布式編程，另一個改變在于控制流。在第2級中，客戶端會嘗試強(qiáng)制更新并動態(tài)設(shè)置狀態(tài)。而在這里，分布式狀態(tài)機(jī)假定有完全的控制力，并且只有當(dāng)它準(zhǔn)備就緒，可以做些有用的事情時才會考慮客戶端的請求。因此這些必須分離開來。
如果你把這些道理解釋給一個2級的分布式系統(tǒng)架構(gòu)師聽，他可能或多或少的會把這個當(dāng)成一種替代方案。然而，你需要經(jīng)歷足夠多的痛苦之后才會意識到這是唯一可行的選擇，我們姑且把這些痛苦稱為經(jīng)驗吧。
第4級 對分布式系統(tǒng)領(lǐng)域的深刻理解：快樂，好心態(tài)，好好睡一覺
老實說，我現(xiàn)在只是第3級水平，我也不知道在這一級里有什么新鮮玩意。我深信，函數(shù)式編程和異步消息傳遞是分布式系統(tǒng)謎題的一部分，但這些還不夠。
請允許我重申我所反對的東西。首先，我希望我的分布式算法實現(xiàn)能夠涵蓋到所有的可能情況。這對我而言是個大問題，我已經(jīng)在系統(tǒng)部署的問題上犧牲掉了很多睡眠時間。大部分問題都是PEBKAC類的（Problem Exists Between Keyboard And Chair意指用戶引起的錯誤），但有一些確是真正的問題，這給我造成了一些挫敗感。知道自己實現(xiàn)的健壯性程度是很好的。我應(yīng)該試試證明一下那些定理嗎？我應(yīng)該做更詳盡的測試嗎？我不知道。
附帶提一下，GitHub上有一個稱為baardskeerder的僅用于插入操作的B-樹庫，我們知道可以通過詳盡的生成插入/刪除排列并斷言它們的正確性之后，我們就可以涵蓋到所有的情況。但這里，并沒有那么簡單，而且我對于要對整個代碼庫做Coqify處理（Coq是一個正式的證明管理系統(tǒng)，它在一種半交互式的環(huán)境下提供了一個正式的語言用來編寫數(shù)學(xué)定義、可執(zhí)行的算法和定理，用計算機(jī)來做檢查證明，這里作者生造出了Coqify這個詞）還有些猶豫。
第二，為了保持清晰和簡單，我決定不去碰其它一些正交性的需求。比如，服務(wù)發(fā)現(xiàn)、認(rèn)證、授權(quán)、私密性以及性能。
說到性能，我們也許是幸運的，至少異步消息傳遞似乎與性能方面并不產(chǎn)生矛盾。安全性則完全是一個XX（作者真的爆粗口了…），因為它幾乎切斷了所有你所做的事情。有些人把安全性看成是一種調(diào)味醬汁，你只要把它倒在你的應(yīng)用程序上就可以保證安全了。哎，在這方面我從未取得過成功，而且現(xiàn)在我也認(rèn)為這個問題需要在設(shè)計的最初階段從宏觀的角度策略性的去分析解決。
結(jié) 語
開發(fā)出健壯的分布式系統(tǒng)是個頗為棘手的問題，實際上根本沒有完美的解決方案，或者說至少沒有讓我覺得完全滿意的解決方案。我敢肯定分布式系統(tǒng)的重要性將隨著處理器和其它一切事物之間的延遲增加而顯著提高。這一結(jié)果使得這種類型的應(yīng)用程序開發(fā)變得愈發(fā)繁榮。
至于分布式編程的第4級，也許我該去問問Peter Van Roy。這么些年來，我閱讀了很多他寫的論文，這些論文對于我自己的一些錯誤認(rèn)識給了很多啟示。關(guān)于這些啟示的缺點嘛，你常常在大部分時間里看到別人在重復(fù)自己的錯誤，但我無法說服他們應(yīng)該換種方式去做。
也許，這是因為我無法提供他們想要的那種靈丹妙藥。他們就想要RPC，而且他們希望這樣能搞定問題。這是固執(zhí)的…就像宗教信仰一樣。
英文原文：rslootma
