莫說網際網路實戰開發，現在就連面試應屆生的時候，分散式方面的問題都基本是必出的了。

分散式架構簡介

以最簡單的架構來說，分散式可以透過部署多個功能相近的伺服器節點來實現。在實際應用中，只暴露出一個域名給使用者，該域名地址通常對應的是一個Nginx，用於負載均衡。Nginx在收到請求後，會根據當前情況，將請求分配給不同的伺服器節點來響應。這套系統的架構圖中，多個伺服器節點的地位是相同。

分散式架構的優點

從當前來看，分散式的架構主要有高併發，高穩定的特點。

高併發是指當單節點伺服器的效能已經達到了瓶頸之後，可以透過引入Nginx，部署多個伺服器節點的方式來擴容，增加系統的吞吐量。這就是 1*N =N的意義。

高穩定是指如果由於不可預測的原因，發生了單個或部分節點宕機，不會影響系統整體的功能服務，即M-N>0(其中M>N)，對於使用者來說，系統可用永遠是最重要的。

以上兩點對評估系統性能，以及服務口碑方面有著非常重要的意義。

綜上，根據我個人的經驗，目前不論是市場級產品還是公司級產品，只要是對服務質量有追求的專案組，都會殊途同歸發展到分散式架構。

此外，對於功能不是非常複雜龐大的專案組來說，只要在最開始開發設計階段，就及時引入memcache或者Redis作為資料快取，而不是使用server的記憶體，那麼後期切換為分散式系統的過程也會十分快捷。

這是一個很好的問題，也是一個很現實的問題。

其實不僅僅是網際網路系統，現在很多傳統行業的系統，也紛紛提出要做分散式系統、要做微服務；

我就遇到過這樣的業務，“這個產品一上線，流量會很大，估計每天會有XXXX的訪問，你們系統能不能扛得住啊？”開始的時候，我們還很擔心的，生怕上線後系統被搞垮，結果發現很多人都過於樂觀了，什麼一天幾百萬的客戶下單，【幾百萬】去掉一個字還差不多。

你以為去掉的是【百】？其實去掉的是【萬】。

個人認為，一個系統的建設是要根據系統的當前情況和對未來發展的預估，選擇合適的架構，而不是“緊跟潮流”地選擇什麼分散式、微服務。

當然，很多創業公司都會使用分散式框架，我分析可能會有這些原因：

業務增長速度可能會非常快，特別是創業公司，不少創業公司發展成獨角獸公司都只用了短短几年，如果系統在建設初期考慮不全面的話，系統可能來不及升級換代；所以不如在建設初期就採用分散式、微服務的架構，便於擴充套件；

網際網路系統，更容易受到惡意攻擊，所以很多網際網路公司在做好網路防範的同時，也會採用前後端分離、分散式的架構，透過限流、服務降級等手段，把損失降到最低（受到惡意攻擊時，只有死掉部分功能，而不會讓系統全部垮掉）；

網際網路系統通常是需要7*24小時服務的，透過分散式架構的設計、叢集部署的方式、灰度釋出的手段，在系統升級的時候，可以做到服務不停；

便於快速迭代，大家知道網際網路系統的迭代是非常快的，一天上一個系統功能都是有可能的，所以採用分散式、微服務的架構，便於程式設計師的快速開發和上線。

分散式架構一般應用在大型網際網路架構設計中，為了解決大型網站面臨的高併發訪問、海量資料處理、高可靠執行等一系列問題與挑戰。

目的

大型網際網路公司在實踐中透過分散式架構，實現網站高效能、高可用、易伸縮、可擴充套件、強安全等各種技術架構目標。

分散式意味著可以使用更多的伺服器資源完成同樣的功能，伺服器資源越多，能夠處理的併發訪問和資料量就越大，進而能夠為更多的使用者提供服務。

問題

但分散式在解決網站高併發問題的同時也帶來了其他問題：

1.網路IO開銷帶來的效能問題。2.分散式環境的資料一致性問題，這也算分散式架構經典問題，後期我們也會為此特意用一篇去講。3.分散式還導致網站依賴錯綜複雜，開發管理維護問題。總結

因此創業公司進行系統設計階段，要根據實際的業務階段和應用場景具體考慮，切莫為了分散式而分散式。

其實，分散式架構只是給實際的業務架構上披了一件高大上的外衣，讓人感覺是有多麼牛的技術，更多的是給專案貼金。

那麼，網際網路系統是否需要使用分散式架構呢，答案是肯定的，但不是所有業務都需要，不是所有系統都需要。

先說何為分散式

分散式，一個絕大部分技術人員仰望的詞彙，同時也是絕大部分技術人員希望熟練的技能。

從狹義的語意（也是最常用的場景）上來講，擁有多條路徑能夠到達目的地，就是分佈，也就是說，如果其中一條路不同路，也能達到目的地。

對應到網際網路專案，就是不要有單點，需要高可用，各服務節點獨立，增減節點對使用者無感知。

當然了，包括但不僅僅是這些，還有一系列的理論在支援，就不細聊了。通常說的分散式大部分指這種狹義的定義，特別是創業公司，目的就是保證服務的可用性，就怕使用者罵娘。

實際的業務中很有必要的

試想一個這樣的場景，公司置換了各種資源（或乾脆投的廣告）招來一批使用者，付出了高昂的成本，使用者在使用的產品的時候，某個功能崩潰了或者導致系統崩潰了，使用者紛紛離去，想想作為公司的負責人是不是要抓狂，說不定就得拿技術祭天。。。

你肯定會想，這個是使用者量太大導致的嘛，怪不得人，然而，事實並非如此，豈不說老闆是否相信這個介面，真正的跟蹤下崩潰的原因，捫心自問，又要多少是由量引起的。通常情況都是程式在對訪問處理的時候，不在意細節的處理，沒有考慮上量的問題，稍微的多點訪問量，導致整個鏈路堵塞，負載成指數增加，直至系統崩潰。真正由量引起的，在架構層面導致系統崩潰的，是好事，說明業務有明顯增長，是時候最佳化架構了，大多數創業公司走不到這一步。

所以，分散式不僅僅存在於系統的架構量，程式碼和業務的層面，也是相當有必要的，特別是對創業公司。

分散式使用

在今天的互聯網裡，分散式漸漸失去神秘感，離普通開發者很近，比如 你用個MC，或者redis，它們就屬於分散式快取，常見的叢集，也屬於這個範疇，docker，k8s 更是典型的代表。更多的由業務場景來選擇。