目錄
1.概述
2.單機服務器
單機版的服務器的性能，設計上的瓶頸？
3.集群
解決瓶頸1：
沒有解決瓶頸2：
沒有解決瓶頸3：
集群的優點？
集群的缺點？
4.分布式
分布式的優點？
分布式面臨的問題
?編輯1、大系統的軟件模塊該怎么劃分？
2、各模塊之間該怎么訪問？
1.概述
集群：每一臺服務器獨立運行一個工程的所有模塊。
分布式：一個工程拆分了很多模塊，每一個模塊獨立部署運行在一個服務器主機上，所有服務器協同工 作共同提供服務，每一臺服務器稱作分布式的一個節點，根據節點的并發要求，對一個節點可以再做節 點模塊集群部署。
以服務聊天器為例，來講解單機，集群，分布式
2.單機服務器
我們把這個單機聊天服務器取名為server。
把用戶管理，好友管理，群組管理，消息管理，后臺管理等模塊構成我們的聊天服務器。每個模塊都包含了很多特定的業務。特定的業務：用戶管理模塊有用戶登錄，用戶注冊，用戶注銷，用戶退出等功能業務。好友管理有添加好友，刪除好友等功能業務。群組管理有添加群，創建群，解散群，群里踢人等功能業務。消息管理有離線消息，一對一的消息，群組消息等和功能業務。后臺管理有廣播消息，公告消息，活動消息等功能業務。這些功能業務都對應了一個或多個完成這些業務的相關的函數。
單機版的服務器的性能，設計上的瓶頸？
1、受限于硬件資源。因為我們只有一臺服務器，聊天服務器所能承受的用戶的并發量是有限的。假設我們使用32位linux操作系統做一個聊天服務器，給一個進程把資源開滿，最多支持2萬多人的在線。用戶量上不去了。硬件資源不夠，socket資源不夠，客戶端無法與服務器建立連接，不可能給更多的客戶端提供服務。
2、任意模塊的修改都會導致整個項目代碼重新編譯，部署。假設這個服務聊天器有5個模塊，每個模塊有幾十上百個功能業務，這一套項目編譯得花2個小時，部署得花3個小時。現在如果我們突然發現用戶管理模塊有個注銷的業務里面有bug，但是改起來特別簡單，就幾行代碼。但是這是一整套系統，得把整個項目的所有代碼全部重新編譯！這樣又得花2個小時編譯，運維部署3個小時！成本較大，耗時。理想狀態是，某個模塊的代碼出問題了，修改后只把這個模塊編譯一下就行。
3、系統中有些模塊是屬于CPU密集型（計算量大的），有些模塊是屬于I/O密集型的（這些模塊會接觸輸入輸出，網絡I/O），造成各模塊對硬件資源的需求是不一樣。 有些模塊是CPU密集型的，這些模塊應該部署在CPU資源非常好的機器上，有些模塊是I/O密集型的，應該部署在內存大，帶寬好的機器上，不需要太強的CPU資源。不同模塊屬于不同的密集型（CPU密集型、IO密集型等），對硬件的需求不一樣，把它們都打包在一套機器上，只能綜合所有模塊，提出平衡的供給需求，沒辦法針對性部署硬件資源。
3.集群
前端需要一個負載均衡器，直接擴充機器數量。每一臺服務器獨立運行一個工程的所有模塊。
解決瓶頸1：
我們擴充了硬件資源。在水平方向上直接擴充成3臺機器。每個機器獨立運行著一臺聊天服務器程序。
沒有解決瓶頸2：
但是每一臺機器都還是獨立運行著一套聊天服務器系統程序，現在對任意模塊的修改，得把整套代碼重新編譯，因為模塊根本沒有分開去部署，都是在一個項目中部署，運行在一個服務器進程中。
編譯一套代碼，做多次部署。因為我們擴充成3臺機器了！更加頭疼
沒有解決瓶頸3：
集群只是水平的去擴展了硬件的機器，每一臺機器還是運行著一臺獨立的聊天服務器程序。假如server2出問題，不影響聊天，因為server1和server3還可以獨立地提供聊天服務，因為是獨立的服務器。
集群的優點？
1、操作簡單，在一臺機器上部署和在多臺機器上部署的方式是一樣的，再加一個負載均衡器就行。
性能提升了，用戶的并發量提升了，因為水平擴充了硬件資源。
集群的缺點？
1、項目代碼還是需要整體重新編譯，而且需要進行多次部署。
2、并不是說機器多，并發量就上來，性能就高。像后臺管理模塊，這個模塊使用的用戶是不多的，能在聊天系統上發布公告，只有管理員，像學校的校長才能發布公告，而且后臺管理員根本不需要高并發，但是把這個模塊部署在3臺服務器上，就太浪費了！，像這些不常用的模塊只需要部署在一臺機器上就好啦。
4.分布式
分布式：把這些管理模塊抽出來，單獨部署在不同的機器上。
從集群上看的話，server2掛掉，還有完整的聊天服務器系統server1,server3。
但是在下圖的分布式上，對于紅色圈，3臺機器上分別運行著不同的模塊，少了這3臺機器的任意臺，聊天系統就缺失了相應的業務了！所有機器共同構成一個聊天服務器系統。這就是分布式。
一個工程拆分了很多模塊，每一個模塊獨立部署運行在一個服務器主機上，所有服務器協同工作共同提供服務，每一臺服務器稱作分布式的一個節點，根據節點的并發要求，對一個節點可以再做節點模塊集群部署。
集群：每一臺服務器都運行了一個獨立的系統。
分布式：所有的機器共同構成了一套系統，一套系統被分成了不同的模塊，不同的模塊根據具體的需求被部署在不同的機器上。
分布式的優點？
解決瓶頸1
用戶登錄成功，為了支持登錄的并發量，我們可以把分布式節點1集群，擴充機器來部署運維用戶管理，消息管理。
比如說后臺管理這個模塊不需要高并發，一臺機器足以！
甚至我覺得用戶管理模塊（登錄，退出）需要更多的并發量，沒有人整天加好友刪好友，建群，解散群。登錄，退出，聊天應該做的是最多的，我們可以在server2節點上再部署用戶管理，消息管理這2個業務功能。
在server2中，當好友管理和群組管理無法使用完server2的網絡I/O資源的時候，用戶管理和消息管理可以再享受多余的server2的網絡I/O資源提供給更多的客戶端進行登錄登出的聊天服務。
解決瓶頸2
2、因為分布式將模塊從總體的進程中，拆分出來了，每一個模塊編譯成了獨立部署，獨立運行的一個小的服務，假設后臺管理模塊出問題，只需要將后臺管理模塊重新編譯就行了，我只需要把server3這臺機器的后臺模塊重新更新就可以了，其他模塊不需要更新。
由此可知，模塊拆分出來了，解決瓶頸3
3、把CPU密集型的模塊部署在CPU資源好的機器上。把I/O密集型的模塊部署在CPU不是很好的機器上。
解決集群缺點2
有的模塊要求并發能力高，可以進行多機器集群部署。有的模塊并發能力小，部署在一臺機器就足以。
配置著高可用，容災的主備服務器，不用擔心就一套系統掛掉了怎么辦。
分布式面臨的問題
1、大系統的軟件模塊該怎么劃分？
各模塊可能實現大量重復的代碼！
模塊和模塊之間的界線不清晰（有的模塊里面的函數調動另一個模塊的函數代碼）。
處理不好，造成大量重復代碼。而且你改你的，我改我的，重復的公共代碼就出問題了，變成不可控制了。
2、各模塊之間該怎么訪問？
因為現在各模塊可能運行不在一個機器上，或者不在一個進程上。
如果用戶登錄成功了，想展示好友列表，但是用戶管理模塊只負責用戶的登錄，退出，注冊、修改密碼等業務功能，它并不知道好友列表，負責管理好友的是好友管理模塊。通過傳入用戶id，得出好友列表。在單機或者集群中，這些模塊是運行在一個服務器進程當中，相當于自己調用自己。但是在分布式中，用戶管理和好友管理部署在不同的進程中，用戶管理進程如何調用另一個模塊上的業務呢？
機器1上的模塊怎么調用機器2上的模塊的一個業務方法呢？（軟件設計師通過經驗來解決）
機器1上的一個模塊進程1怎么調用機器1上的模塊進程2里面的一個業務方法呢？
涉及網絡傳輸，攜帶區分函數的標識，包括函數的參數，函數命名等一些數據，全部通過網絡發送過來，另一臺機器便知道有別的機器想要調用我的方法，將傳遞過來的參數等數據代入執行，執行之后將返回值通過網絡返回。
通過網絡！ 處理網絡請求。網絡是否有問題？如何告訴調用者網絡的情況？
我們這個項目要做的就是把這些封裝成一個分布式的通信框架，然后把這套框架給到用戶，用戶如果想要進行一個模塊分布式的部署，在不同的分布式節點1，想要調用分布式節點2的代碼，對于用戶來說，他調用遠程的方法就跟調用自己本機的方法一樣簡單方便，不用去關注一些具體的細節
)
