1. 程式人生 > >什麼是分散式系統(通俗易懂)

什麼是分散式系統(通俗易懂)

最近做了一些分散式的專案,但還沒有真正的理解和認識什麼是分散式,以及為什麼要這麼設計等等一系統問題,在看過大神的貼子了,如夢初醒,受益匪淺!

著作權歸作者所有。 商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。 作者:林建入 連結:http://www.zhihu.com/question/22764869/answer/56011081 來源:知乎

一.分散式的簡單介紹

 1.什麼是分散式?       在一個操作中,需要多個系統之間配合才能完成的整個業務邏輯,叫做分散式系統。(個人理解)

 2.分散式拆分三步驟

  1.將你的整個軟體視為一個系統(不管它有多複雜)。

  2.將整個系統分割為一系列的 Process(程序), 每個 Process 完成一定的功能。

  3.將這些 Process 分散到不同的機器上。分散後,選擇若干種(沒錯一種可能不夠)通訊協議把他們連線起來,當執行某項操作的時候按照拆分的系統有序的執行。

二、跳出誤區——分散式不等於平行計算  人們常常把分散式系統自然而然的和平行計算聯絡起來。然而這並不正確。實際上,分散式系統並不一定是並行的,舉個簡單的例子就能理解——  某軟體,功能如下:

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

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

  如果我們從整個系統流程的觀點來看,並沒有什麼並行。整個過程都是順序執行的。只不過執行時出現了“跨裝置”的現象而已。可見,分散式本身就只如其字面意思所指,指的僅僅是從結構角度的分散而已。   當然啊,現實世界中,我們更多的時候鍾情於分散式,還是因為它與並行之間可以相互配合。例如實現既是分佈同時也是並行的系統。   好了,理解這一點之後就不難解釋為什麼我會說前文提到的三步驟是萬用大法了。接下來我們繼續討論分散式本身。

三、拆分+連線是分散式系統的本質   所謂分散式,無非就是”將一個系統拆分成多個子系統並散佈到不同裝置“的過程而已。   本質上而言,實現一個分散式系統,最核心的部分無非有兩點:

   1.如何拆分——可以有很多方式,核心依據一是業務需求,二是成本限制。這是實踐中構建分散式系統時最主要的設計依據。

   2.如何連線——光把系統拆開成 Process 還不夠,關鍵是拆開後的 Process 之間還要能通訊,因此涉及通訊協議設計的問題,需要考慮的因素很多,好訊息是這部分其實成熟    方案很多

四、為什麼你要使用分散式?   分散式系統並非靈丹妙藥,解決問題的關鍵還是看你對問題本身的瞭解。通常我們需要使用分散式的常見理由是:

  1.為了效能擴充套件 ——系統負載高,單臺機器無法承載,希望通過使用多臺機器來提高系統的負載能力。

    例:對一個B2C(京東、淘寶)商城進行拆分,首頁部分我們要考慮到高併發、高可用、搜尋、快取等等一系列的情況,需要把這個功能單獨拆分出來來擴充套件效能

  2.為了增強可靠性 ——軟體不是完美的,網路不是完美的,甚至機器本身也不可能是完美的,隨時可能會出錯,為了避免故障,需要將業務分散開保留一定的冗餘度

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

五、一些分散式方案能解決你的問題,另一些卻不能,要學會的其實是選擇   籠統的討論分散式沒有太大的意義,就如我剛才所談的,實際上分散式很容易實現。真正難的地方在於如何選擇正確的分佈方案。   例如,當你想要建立一個分散式的資料管理系統的時候,你就必須得面對“一致性”問題。如果你對資料一致性要求很高,你就不得不容忍一些缺陷例如規模伸縮困難;而如果你放棄它,你可以輕鬆伸縮規模,但你必須解決好由此帶來的一系列資料不一致導致的問題。(CAP 問題)   於是你會意識到,有許多種分佈方案,為了正確解決你的問題,你需要對每一個方案都進行了解,並評估,選擇不同的方案有時候區別不大,有時候卻會深刻的影響整個系統中其他部分的工作方式,甚至影響使用者介面中使用者操作時的流程。這是我們學習分散式系統的重點所在。六、分散式學習入門——基礎知識要點   如我前面所講,分散式入門不難。主要包含如下知識點:

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

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

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

  好了,如果這些你都學的差不多了,那咱們“紙上談兵”也就告一段落了。接下來進入實戰演練。七、實戰演練?其實你已經開發過分散式系統了   你有沒有開發過簡單的增刪改查軟體?這類軟體通常都需要搭配一個獨立的資料庫管理系統共同完成功能。實際上,只要你開發過這麼簡單的軟體,那麼你就已經開發過分散式系統了。

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

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

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

  你看,這不就是分散式系統的特點嗎?

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

八.分散式的本質  

  我們需要透過分佈的本質來提高的是解決問題的能力,能解決這些問題的前提不但需要知識的深度,還需要知識的廣度,只有這樣才能設計好真正適合業務需求的分散式!

  畢竟,程式碼只是思想的一種體現而已!!!