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