java 分佈式服務開發

1、三個步驟完成華麗轉身——任意軟件變爲「分佈式」

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

1. 將你的整個軟件視爲一個系統（無論它有多複雜）
2. 將整個系統分割爲一系列的 Process（進程）， 每一個 Process 完成必定的功能
3. 將這些 Process 分散到不一樣的機器上。分散後，選擇若干種（沒錯一種可能不夠）通訊協議把他們鏈接起來

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

2、跳出誤區——分佈式不等於並行計算

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

某軟件，功能以下：

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

很簡單吧？這三個步驟是沒法並行的。它們須要被依次執行。可是這個軟件依然能夠被改成分佈式的，方法就是用前面提到的方法，把步驟 2 的計算過程獨立爲一個 Process 移動到另一臺計算機上完成。

若是咱們從整個系統流程的觀點來看，並無什麼並行。整個過程都是順序執行的。只不過執行時出現了「跨設備」的現象而已。可見，分佈式自己就只如其字面意思所指，指的僅僅是從結構角度的分散而已。

固然啊，現實世界中，咱們更多的時候鍾情於分佈式，仍是由於它與並行之間能夠相互配合。例如實現既是分佈同時也是並行的系統。

好了，理解這一點以後就不難解釋爲何我會說前文提到的三步驟是萬用大法了。接下來咱們繼續討論分佈式自己。

3、拆分+鏈接是分佈式系統的本質

所謂分佈式，無非就是」將一個系統拆分紅多個子系統並散佈到不一樣設備「的過程而已。

所謂分佈式，無非就是」將一個系統拆分紅多個子系統並散佈到不一樣設備「的過程而已。

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

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

 

4、爲何你要使用分佈式？

分佈式系統並不是靈丹妙藥，解決問題的關鍵仍是看你對問題自己的瞭解。一般咱們須要使用分佈式的常見理由是：

• 爲了性能擴展——系統負載高，單臺機器沒法承載，但願經過使用多臺機器來提升系統的負載能力
• 爲了加強可靠性——軟件不是完美的，網絡不是完美的，甚至機器自己也不多是完美的，隨時可能會出錯，爲了不故障，須要將業務分散開保留必定的冗餘度

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

5、一些分佈式方案能解決你的問題，另外一些卻不能，要學會的實際上是選擇

籠統的討論分佈式沒有太大的意義，就如我剛纔所談的，實際上分佈式很容易實現。真正難的地方

在於如何選擇正確的分佈方案。

例如，當你想要創建一個分佈式的數據管理系統的時候，你就必須得面對「一致性」問題。若是你對數據一致性要求很高，你就不得不容忍一些缺陷例如規模伸縮困難；而若是你放棄它，你能夠輕鬆伸縮規模，但你必須解決好由此帶來的一系列數據不一致致使的問題。（CAP 問題）

因而你會意識到，有許多種分佈方案，爲了正確解決你的問題，你須要對每個方案都進行了解，並評估，選擇不一樣的方案有時候區別不大，有時候卻會深入的影響整個系統中其餘部分的工做方式，甚至影響用戶界面中用戶操做時的流程。這是咱們學習分佈式系統的重點所在。

6、分佈式學習入門——基礎知識要點

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

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

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

• 一致性。數據存儲時，最基本的問題。其實也是實際設計系統時經常須要反覆考慮的問題
• 容錯。冗餘是容錯的基礎，但並非所有，分佈式自己爲實現容錯提供了一些便利，這也是實際設計系統時經常須要考慮的問題

• 好了，若是這些你都學的差很少了，那我們「紙上談兵」也就告一段落了。接下來進入實戰演練。

  7、實戰演練？其實你已經開發過度布式系統了

  你有沒有開發過簡單的增刪改查軟件？這類軟件一般都須要搭配一個獨立的數據庫管理系統共同完成功能。實際上，只要你開發過這麼簡單的軟件，那麼你就已經開發過度布式系統了。

  「什麼，基於數據庫管理系統開發出來的軟件就能夠算分佈式呀？我作了不少這類軟件，怎麼我歷來沒聽過這種說法？

  真的，我沒開玩笑。還記得咱們前面提到的嗎，什麼是分佈式？不就是一個大系統拆分紅多個小系統分散到不一樣的設備上嗎。回想一下，當你寫一個簡單的增刪改查軟件時，只要用到數據庫管理系統，是否是具備以下特色：

• 整個系統中，你寫的代碼跑在 A 進程裏，而數據庫管理系統則跑在另一個進程 B 裏
• A 進程與 B 進程經過某種通訊協議鏈接
• 既可使 A 進程與 B 進程運行在同一臺機器上，也能夠將它們分開運行於不一樣的機器上，而且系統依然能夠照常運行

你看，這不就是分佈式系統的特色嗎？

「啊，原來如此，但是我印象裏一說分佈式的話，應該會講「集羣」啊啥的吧，這麼簡單的也算？」

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

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

8、實現一個簡單的 Remote Procedure Call (遠程過程調用)系統

（未完） 做者：林建入 連接：https://www.zhihu.com/question/22764869/answer/56011081 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。