分散式系統架構是建立在網路之上的軟體系統。

內聚性是指每一個數據庫分佈節點高度自治，有本地的資料庫管理系統。

透明性是指每一個數據庫分佈節點對使用者的應用來說都是透明的，看不出是本地還是遠端。

在分散式資料庫系統中，使用者感覺不到資料是分佈的，即使用者不須知道關係是否分割、有無副本、資料存於哪個站點以及事務在哪個站點上執行等。

簡單來講：在一個分散式系統中，一組獨立的計算機展現給使用者的是一個統一的整體，就好像是一個系統似的。

分散式系統作為一個整體對使用者提供服務，而整個系統的內部的協作使用者來說是透明的，使用者就像是在使用一個MySQL一樣。

如分散式MySQL中介軟體-Mycat，來處理大併發大資料量的構架。

分散式架構的應用

有 分散式檔案系統，分散式快取系統，分散式資料庫，分散式WebService，分散式計算

我們來舉例說明：

分散式檔案系統： 出名的有 Hadoop 的HDFS ,還有 google的 GFS , 淘寶的 TFS 等

分散式快取系統：memcache , hbase , mongdb 等

分散式資料庫 ： MySQL , Mariadb, PostgreSQL 等

以分散式MySQL資料庫中介軟體MyCat 為例子，

MySQL 在現在電商以及網際網路公司的應用非常多，一個是因為他的免費開源，另外一個原因是因為分散式系統

的水平可擴充套件性，隨著移動網際網路使用者的暴增，網際網路公司，像淘寶，天貓，唯品會等電商都採用分散式系統應對

使用者的高併發量以及大資料量的儲存。

而在Mycat的商業案例中，有對中國移動的賬單結算專案中，應用實時處理高峰期每天2億的資料量，

在對物聯網的專案中，實現處理高達26億的資料量，並提供實時查詢的介面。

透過對MyCat的學習，加深分散式系統架構的理解，

以及分散式相關的技術，分散式一致性ZooKeeper服務, 高可用HAProxy/keepalived等相關應用。

1> 叢集 與 分散式

2> 負載均衡

3> 分散式相關的高可用、容災等名詞解釋

4> Mycat 中介軟體學習

技術上可行，但是架構上不建議。

幾種部署方式，第一個不太建議，後兩種方案都還可以：

直接部署，不同的軟體、中介軟體佔用不同的埠：例如資料庫Mysql佔用3306埠，多套不同的程式使用Tomcat部署，佔用不同的埠，或者使用Spring Boot的話，啟動時候指定不同的埠；相同的應用前面掛一個負載均衡，或者直接安裝註冊中心到這臺機器上。其餘用到的軟體，也一窩蜂的安裝在同一臺機器上。

虛擬化：使用虛擬化技術，將一臺物理機，虛擬成多臺虛擬機器，然後分別在每個虛擬機器中，安裝不同的軟體、中介軟體，最終完成部署，彼此相互隔離。

容器技術：比如Docker；和虛擬化類似（詳情參考我的另一個回答：《docker容器與虛擬機器有什麼區別？》），容器技術更輕量級、更容易部署和移植、並且可以彈性伸縮；相同配置的伺服器，部署容器的數量會比虛擬機器多很多。

主要出於兩方面的考慮：

首先是資源方面的考慮，如果所有專案都部署在一臺機器上，那麼單機的資源配置可能會是瓶頸。

第二，單機意味著單點，單點很危險，如果這臺物理機器出現了故障，那麼所有專案就都掛了；所以很多公司都會採用多機器、多機房、甚至多地多中心。

可以，但是不推薦。

分散式的目的是分工合作，提高系統的整體可用性！

假設一個系統S，拆分為s1,s2,s3。如果s1掛了，那可能s1負責的功能無法使用，s2,s3負責的功能還是能使用的。比如2018年雙11，淘寶的地址服務掛了，買家無法修改收貨地址。但是並不影響下單。

假設s1,s2,s3部署在一臺機器上，會降低整體可用性！如果只是單純的s1,s2,s3掛了，只會影響部分功能，但是如果這臺機器掛了，那整個系統就都掛了。

如果s1,s2,s3部署在不同的機器上，那麼其中一臺機器掛了，也不會導致系統整體不可用。

在講原理之前，先分享一個發生在BAT的故事來回答這個問題吧。

我曾經參與開發過一個公司級別的平臺，使用的是1臺Nginx，4臺Tomcat，主從MySQL以及1個Redis服務。

其中1臺Nginx，2臺Tomcat和1個Redis部署在了同一臺虛擬物理機上。

當雪崩沒有發生之前，大家都是歲月靜好的模樣，讓人誤以為這就是它原本溫柔的本性。

直到某一天，突然這臺物理機抽風了，具體表現為Redis無法請求，機器所在的域名地址無法訪問，secureCRT直接無法登陸，想要重啟都不行。

大家突然慌了。

這時候，還好我們有一臺常開的機器上的secureCRT常連線了這個虛擬物理機。

我們先是透過這個常開機器，重啟了Nginx與Redis，服務短暫的恢復了。

但是5min後，服務再次崩潰。

重複了3次“崩潰-重啟”之後，常開機器上的secureCRT直接斷開了與那臺虛擬物理機的連線。

整個過程持續了超過半小時，使用者群裡炸開了鍋，從他們的角度來看，我們的服務不是斷斷續續的工作，而是完全掛掉了，經理也直接介入，詢問原因，並且確認這是一次先說最高階事故。

這期間，我們火速聯絡了虛擬資源管理員，管理員在排查後表示是該資源所在的物理機器出了問題。

在上海的我們詢問在北京的管理員，可否重啟那臺物理機，管理員說可以，但是機器在山西陽泉，需要聯絡當地的運維人員。

欲哭無淚，大概就是我們當時的狀態，隨後就是，聽天由命。

這次線上事故最後緊急處理方法是請求了陽泉運維人員的干預，物理機狀態恢復後，我們的服務也恢復了。

雖然物理機恢復了，但是這次事故給我們所有同事都敲響了警鐘。

雖然從技術上是沒有問題的，但是雞蛋不能放在同一個籃子裡，沒有人能承擔雞蛋都摔碎的風險。

我們在case study中重新分析了當前架構，對每個重要節點都重新進行了分析，並推演了所有場景，保證不會由於單個節點掛掉而影響全域性服務。

分散式架構除了為了增加服務的吞吐量，保證服務可用性也是它的重點目標。

因此，基於我的個人經驗，強烈建議不要將分散式服務部署在一個節點上。

不僅不要部署在一個節點上，每個模組都要做好備份。

比如多個Tomcat要部署在不同機器上，Redis的master-slave也要分散在不同機器上，要每天對MySQL進行重點資料和表結構的備份等等。

畢竟在安全面前，再多的冗餘都不是多餘。

當然可以了，不然我的兩個mysql服務主從複製，讀寫分離，nginx+兩個SpringCloud微服務應用怎麼部署？

廢話不多說，先來看看我的mysql主從複製+讀寫分離怎麼搭建在一臺機器上的。。

1，windows下載boot2docker軟體，安裝註冊之後，使用boot2docker ssh開啟docker服務；

2，拉取mysql映象，分別以埠3006，3008埠進行兩個服務的啟動，指令碼類似這個：docker run --name mysql1 -p 3308:3306 -e MYSQL_ROOT_PASSWORD=root -d mysql，

3，使用下載boot2docker自帶的oracle VM VirtualBox將3008,3006埠暴露，這樣兩個mysql服務就可以提供使用了；

4，配置主從複製+讀寫分離（自行百度）！

可以看到，我的windows下面的docker映象有mysql，redis，nginx，zookeeper等等，我執行專案的時候，全部確實都可以執行在我的一臺機器上，所有的服務確實是“分佈”的；也就是說分散式架構的所有服務可以全部部署到一臺伺服器上；

我們可以這麼做分散式架構，但是計算機不允許。。執行那麼多的服務，基本每個服務都要卡成狗了！

分散式系統之所以需要就是因為單機系統成為了高效能，高穩定性，高持續性的瓶頸！

再來看下分散式的好處：

1，服務拆分 ：分散式系統可以將服務拆分為多個獨立模組，獨自進行開發和部署，而對外作為一個整體來輸出，單機服務的每次釋出都會影響線上環境！

2，容災： 一臺機器很容易受到環境干擾出現宕機等情況，如果資料沒有進行備份，那麼極有可能造成極為嚴重的事故，所以使用分散式資料叢集可以進行資料備份容災！

3，持續穩定： 多個服務組成的叢集可以在單點掛了之後還能持續對外提供服務，如果是單機系統則無法保證！

4，提高運算（吞吐）能力：現在的大資料通常都是使用分散式系統，將運算部署在多達幾千臺的機器上，進行並行運算，大大的提高了整體的運算效能！

綜上，如果你的單機能保證超高的穩定性，永不宕機，運算能力比別人家幾千臺還厲害，那麼就使用單機，否則還是接入分散式吧！

經常使用docker環境在本地模擬分散式環境，還是蠻好玩的，我也經常分享JAVA相關的技術，有需要的朋友，敬請關注。。

從這個問題本身來講，將分散式架構部署在同一臺機器上是可以的，具體怎麼部署和原理大家已經說了很多。

但是，部署在一臺機器上的分散式架構業界稱它為偽（假的，模擬的）分散式。它在測試階段有比較大的應用（比如手工停掉某些服務，看整體對外服務是否依然符合預期），因為單機結構依賴資源少，便於操作，可快速找出分散式架構中80%的問題，剩餘20%就需要透過真正的分散式環境甚至是生產環境來找出了（二八理論）。

真正的分散式架構不只包括軟體層面（軟體分佈，業務分佈），更包括了硬體層面（機器分佈，機器資源分佈，地區分佈…）。軟硬體結合的分散式才是真正的分散式架構。這也是現代網際網路企業開啟的方式：業務分佈、元件分佈分佈、機器分佈、機架分佈、機房分佈、區域分佈（城市、省、國家）。

光談軟體架構本身的分佈只是分散式架構的一部分（可類比為它是理論，實際落地沒有硬體的支援只能成為空中樓閣）。

什麼是分散式架構？

從字面語義來講，它是指採用分而治之思想構建的一種架子結構（架構一詞起源於建築）。建築本身是不能脫離環境存在的。建築抽象為軟體，環境指的就是硬體了。

從解決問題的角度來說，分散式架構是指透過在軟體層面和硬體層面進行分散式設計和部署的一種結構構建方式。它的提出是為解決例如如下的一些核心問題：

2、容災：基於任何一個事物無法永遠一直保持一種狀態的認知（固定是臨時的，變化是永恆的）。任何事物都有兩面性，當事物處於對我們有利的一面時未正常態，當它處於對我們不利的一面為異常態（注意，事物無好壞，但人是有立場的，觀察認知是有角度的）。因此，如何儘量確保從我們的角度儘量保持對外服務的穩定性、一致性，這是分散式架構需要面對的核心問題。分散式架構是降低災難發生的一種有效的方式（區域性問題可能是隨時隨地發生的，但整體崩潰性災難的發生比率可以被大大降低）。當然，因為資源的有限性這個前提，所以任何方式都不能確保100%不會發生對我們不利的影響。只是時間、空間的侷限不同而已。所以，雲企業也只敢聲稱它們可做到多少個9的穩定度，努力去讓穩定度趨近於100%。若有人拍著胸脯告訴你他能百分百保證，那他一定是忽悠，還請儘快遠離吧哈哈

3、服務能力：包括效能提升、容量動態擴充套件…等等。對於使用者來講：他能獲得越來越好、越來越多的服務；對於服務者來說：有越來越多的能力，獲得越來越大的競爭力；從而在某種程度上達到雙贏或多贏等效果。

…

還有很多分散式架構需要解決的問題，就不一一列舉了。

回頭來看，若將分散式架構部署在單臺機器上，那麼它很難面對這些問題。單點面臨的問題，透過分佈的方式去解決是一種自然、符合慣性的想法；實踐中分散式架構思維也已經過了無數檢驗，已證明是解決單點問題的極其有效的方式。

從數學上的機率論，我們可知當節點越多，分佈越合理，災難就越不容易同時發生：比如同時宕機、同時斷掉、同時斷網等情況的可能性就被大大降低，從而可以大大提高對外服務的可用性、穩定性和高效等。對於服務來講，這些是核心評估指標。

分佈是單點的一種反義詞表述（單—多、分佈），它是多的一種實現。分散式架構是建立在將多進行有機（有效）整合的一種結構和方法。它是結果導向思維下形成的、已經被證明行之有效的方法論。從歷史與現狀來看，它已經起到了巨大作用。

因此，將分散式架構部署到一臺機器上可以，只是這就像將一個有巨大能力的人用層層繩索把它捆綁在一個狹窄的地方，它也就喪失了絕大部分能力了。

一家之言，與大家分享