分散式系統的本質：拆分+連線

題主問的是 Java，不過這個問題其實不侷限於 Java，因此我試著以“分散式”本身來回答。

一、三個步驟完成華麗轉身——任意軟體變為“分散式”

分散式——一個高大上的名詞，是計算機軟體設計中人民群眾喜聞樂見的“逼格滿滿”、“不明覺厲”的幾個名詞之一。但很可惜，這玩意兒一點也不復雜，甚至有些“簡單”。不信？你只要遵循下述步驟即可將任何一個軟體拆分為“分散式”的：

1. 將你的整個軟體視為一個系統（不管它有多複雜）
   
2. 將整個系統分割為一系列的 Process（程式）， 每個 Process 完成一定的功能
   
3. 將這些 Process 分散到不同的機器上。分散後，選擇若干種（沒錯一種可能不夠）通訊協議把他們連線起來
   

蹬蹬蹬蹬～大功告成。哈哈別打我，這真的是很嚴肅的通用型三步驟大殺器，對付任何軟體，是任何軟體都可以的。接下來我當然要解釋清楚為什麼。

二、跳出誤區——分散式不等於平行計算

人們常常把分散式系統自然而然的和平行計算聯絡起來。然而這並不正確。實際上，分散式系統並不一定是並行的，舉個簡單的例子就能理解——

某軟體，功能如下：

1. 提示使用者輸入兩個數 A 和 B
2. 在內部，對 A 和 B 執行某數學運算，獲得 C
3. 輸出 C

很簡單吧？這三個步驟是無法並行的。它們需要被依次執行。但是這個軟體依然可以被改為分散式的，方法就是用前面提到的方法，把步驟 2 的計算過程獨立為一個 Process 移動到另外一臺計算機上完成。

如果我們從整個系統流程的觀點來看，並沒有什麼並行。整個過程都是順序執行的。只不過執行時出現了“跨裝置”的現象而已。可見，分散式本身就只如其字面意思所指，指的僅僅是從結構角度的分散而已。

當然啊，現實世界中，我們更多的時候鍾情於分散式，還是因為它與並行之間可以相互配合。例如實現既是分佈同時也是並行的系統。

好了，理解這一點之後就不難解釋為什麼我會說前文提到的三步驟是萬用大法了。接下來我們繼續討論分散式本身。

三、拆分+連線是分散式系統的本質

所謂分散式，無非就是”將一個系統拆分成多個子系統並散佈到不同裝置“的過程而已。

本質上而言，實現一個分散式系統，最核心的部分無非有兩點：

1. 如何拆分——可以有很多方式，核心依據一是業務需求，二是成本限制。這是實踐中構建分散式系統時最主要的設計依據。
2. 如何連線——光把系統拆開成 Process 還不夠，關鍵是拆開後的 Process 之間還要能通訊，因此涉及通訊協議設計的問題，需要考慮的因素很多，好訊息是這部分其實成熟方案很多

四、為什麼你要使用分散式？

分散式系統並非靈丹妙藥，解決問題的關鍵還是看你對問題本身的瞭解。通常我們需要使用分散式的常見理由是：

• 為了效能擴充套件——系統負載高，單臺機器無法承載，希望通過使用多臺機器來提高系統的負載能力
• 為了增強可靠性——軟體不是完美的，網路不是完美的，甚至機器本身也不可能是完美的，隨時可能會出錯，為了避免故障，需要將業務分散開保留一定的冗餘度

在以提供 Service 為主的服務端軟體開發過程中常常遇到這些問題。

五、一些分散式方案能解決你的問題，另一些卻不能，要學會的其實是選擇

籠統的討論分散式沒有太大的意義，就如我剛才所談的，實際上分散式很容易實現。真正難的地方在於如何選擇正確的分佈方案。

例如，當你想要建立一個分散式的資料管理系統的時候，你就必須得面對“一致性”問題。如果你對資料一致性要求很高，你就不得不容忍一些缺陷例如規模伸縮困難；而如果你放棄它，你可以輕鬆伸縮規模，但你必須解決好由此帶來的一系列資料不一致導致的問題。（CAP 問題）

於是你會意識到，有許多種分佈方案，為了正確解決你的問題，你需要對每一個方案都進行了解，並評估，選擇不同的方案有時候區別不大，有時候卻會深刻的影響整個系統中其他部分的工作方式，甚至影響使用者介面中使用者操作時的流程。這是我們學習分散式系統的重點所在。

六、分散式學習入門——基礎知識要點

如我前面所講，分散式入門不難。主要包含如下知識點：

• Process（程式）。在分散式系統中，程式是基本單元
• 通訊協議。Process 間需要相互配合才能完成工作，因此通訊協議是最基本要解決的問題。這部分其實挺複雜，牽涉面光，不過核心還是抓住兩方面，一是存在哪些需求，二是各個協議如何滿足這些需求
• 命名法。兩個 Process 要通訊，必須相互知道對方的名字，名字可以是數字，也可以是結構化的字串。例如眾所周知域名系統就是一種命名方案，但是方案還有很多，各有特點
• 協作。上面都在談 Process 之間的通訊，可是為什麼要通訊？因為要協作。協作是個複雜的主題，其中最基本最基本的一個問題就是同步問題。而聊同步問題必然要聊“鎖”……知識點就這麼展開了

上面幾點是最基礎的知識。瞭解了這些其實就算入門了。可是如何進階呢？那麼必然要開始學習下面的問題：

• 一致性。資料儲存時，最基本的問題。其實也是實際設計系統時常常需要反覆考慮的問題
• 容錯。冗餘是容錯的基礎，但並不是全部，分散式本身為實現容錯提供了一些便利，這也是實際設計系統時常常需要考慮的問題

好了，如果這些你都學的差不多了，那我們們“紙上談兵”也就告一段落了。接下來進入實戰演練。

七、實戰演練？其實你已經開發過分散式系統了

你有沒有開發過簡單的增刪改查軟體？這類軟體通常都需要搭配一個獨立的資料庫管理系統共同完成功能。實際上，只要你開發過這麼簡單的軟體，那麼你就已經開發過分散式系統了。

“什麼，基於資料庫管理系統開發出來的軟體就可以算分散式呀？我做了很多這類軟體，怎麼我從來沒聽過這種說法？

真的，我沒開玩笑。還記得我們前面提到的嗎，什麼是分散式？不就是一個大系統拆分成多個小系統分散到不同的裝置上嗎。回想一下，當你寫一個簡單的增刪改查軟體時，只要用到資料庫管理系統，是不是具有如下特點：

• 整個系統中，你寫的程式碼跑在 A 程式裡，而資料庫管理系統則跑在另外一個程式 B 裡
• A 程式與 B 程式通過某種通訊協議連線
• 既可以使 A 程式與 B 程式執行在同一臺機器上，也可以將它們分開執行於不同的機器上，並且系統依然可以照常執行

你看，這不就是分散式系統的特點嗎？

“啊，原來如此，可是我印象裡一說分散式的話，應該會講「叢集」啊啥的吧，這麼簡單的也算？”

關於「叢集」的問題我們之後會談到，它也是分散式系統的一個應用，但談叢集的時候，我們談的往往是更具體的東西。但我們們看問題，需要抓住本質。別看麻雀小，五臟卻俱全。

不過，你已經熟悉的東西，我們在這裡就不再展開了，我們不妨關注其他一些更有趣的話題。

八、實現一個簡單的 Remote Procedure Call (遠端過程呼叫)系統

（未完）