最近公司一直想搞重構，把原來單機的程序，搞成分佈式的，但是對於一些大家平時喊的比較響亮的術語，感覺自己理解的不夠深刻，同時也感覺有些人雖然在說一些術語，但是他們本身理解的也並不是特別正確，然後自己也上網找了一些術語的介紹，然後想自己寫一篇總結，希望與各位同道中人共同探討。
集羣是個物理形態，分佈式是個工作方式。
- 分佈式：一個業務分拆多個子業務，部署在不同的服務器上
- 集羣：同一個業務，部署在多個服務器上
- 負載均衡，是集羣中的調度方式
1：分佈式是指將不同的業務分佈在不同的地方。而集羣指的是將幾臺服務器集中在一起，實現同一業務。負載均衡是指在集羣中如何均等的分配任務，不至於一個服務器上承載過多的任務。
分佈式中的每一個節點，都可以做集羣。而集羣並不一定就是分佈式的。
舉例：就比如新浪網，訪問的人多了，他可以做一個羣集，前面放一個響應服務器，後面幾臺服務器完成同一業務，如果有業務訪問的時候，響應服務器看哪臺服務器的負載不是很重，就將給哪一臺去完成。這裏的響應服務器，負責負載均衡的調度。
再說一個具體的例子，就是我進行我的一個應用程序，要進行三個業務，呼叫，短信，GPS三個業務，然後我爲了分散壓力做成集羣模式，就是把應用程序部署在三臺服務器上，然後前面有個響應服務器，Nginx,負責負載均衡調度。
可以用下圖來表示集羣以及負載均衡。
而分佈式，從窄意上理解，也跟集羣差不多，但是它的組織比較鬆散，不像集羣，有一個組織性，一臺服務器垮了，其它的服務器可以頂上來。
分佈式的每一個節點，都完成不同的業務，一個節點垮了，那這個業務就不可訪問了。
分佈式可以用下圖來表示
2：簡單說，分佈式是以縮短單個任務的執行時間來提升效率的，而集羣則是通過提高單位時間內執行的任務數來提升效率。
例如：如果一個任務由 10 個子任務組成，每個子任務單獨執行需 1 小時，則在一臺服務器上執行該任務需 10 小時。
採用分佈式方案，提供 10 臺服務器，每臺服務器只負責處理一個子任務，不考慮子任務間的依賴關係，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是 Hadoop 的 Map/Reduce 分佈式計算模型）
而採用集羣方案，同樣提供 10 臺服務器，每臺服務器都能獨立處理這個任務。假設有 10 個任務同時到達，10 個服務器將同時工作，1 小時後，10 個任務同時完成，這樣，整身來看，還是 1 小時內完成一個任務！
好的設計應該是分佈式和集羣的結合，先分佈式再集羣，具體實現就是業務拆分成很多子業務，然後針對每個子業務進行集羣部署，這樣每個子業務如果出了問題，整個系統完全不會受影響。
具體的表示如下圖所示：
服務化：
服務化和集羣，分佈式不是一個級別或者是類型的概念，服務是類似於一個設計模式，就是類似於我們軟件裏常說的抽象層，也可以說是依賴於接口編程，舉個例子，就是不同的業務網元都和數據庫打交到，每個模塊都去調用數據庫進行增刪改查，這樣就比較亂，我們單獨寫個模塊進行對數據庫底層的操作進行封裝，這就是一個服務，服務化與本地調用rpc調用等沒有什麼關係。
另外，還有一個概念和分佈式比較相似，那就是微服務。
微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表着一個小的業務能力。那麼分佈式是否屬於微服務呢？
答案是肯定的。微服務的意思也就是將模塊拆分成一個獨立的服務單元通過接口來實現數據的交互。
那麼微服務一定屬於分佈式嗎？
不一定，微服務的設計是爲了不因爲某個模塊的升級和BUG影響現有的系統業務。微服務與分佈式的細微差別是，微服務的應用不一定是分散在多個服務器上，他也可以是同一個服務器。
分佈式和微服的架構很相似，只是部署的方式可能不一樣而已
在文章的最後，我想記錄下我之前看過的一篇文章關於集羣，分佈式，負載均衡的一個很幽默的例子，這個可能更有助於大家的理解。
轉載自：https://blog.csdn.net/afsya/article/details/84584515
一個項目的成功與否，往往是由用戶的多少來計算，隨着訪問量的上升，如何提高效率、保障系統的可用性就成了必須要解決的問題。
不論是面試，還是公衆號裏的文章，集羣、負載均衡、分佈式，這三個詞的出現頻率總是很高。
栗子
從集羣、負載均衡、分佈式的定義來看，乍聽上去都是爲了解決高併發的，無法很直觀的發現它們的區別與聯繫。下面我們通過一個栗子，看看它們到底是做什麼的。
二蛋是個心懷天下的喫貨，爲了讓更多的人喫上好喫的，於是開了個飯館兒，處於對自己的充分信任，一個員工都沒有，慘狀如下圖：
終於有一天，二蛋受不了了，決定僱兩個像自己一樣厲害的同志，立志做個甩手掌櫃的，囂張狀如下圖：
二蛋的兩個手下所形成的，就是集羣，部署兩套完全一樣的，執行相同任務的項目，就像多個 tomcat 下都部署同一個項目。那麼二蛋就完全沒有事了嗎？不是的，分配工作的任務由他負責，負載均衡就是在這裏。
在上邊的結構裏，二蛋輕鬆了不少，可兩個手下很快就提出了抗議，從頭忙到尾不說，還要幹些不擅長的工作，於是二蛋狠了狠心，又招來幾批人，痛心狀如下圖：
根據業務分組，每組人馬就只負責自己擅長的，就是分佈式。而且今天記賬的同志請假了，並不影響整個飯館兒的運營，最多隻是賬晚點再計嘛。每種業務只招一個人的風險還是很大，因爲如果廚子病倒了，飯館兒照樣不能營業。所以分佈式中往往附帶着集羣，那麼有了集羣，怎麼分發請求呢，還是會用到負載均衡。
這個圖原作者沒有給出，大致就是在採購 做飯 搞衛生，後面加個負載均衡服務器，然後後面變成集羣模式，多個人幹活。
總結
集羣：運行多個做同樣工作的程序，相當於把現有的項目部署到多個服務器上。
負載均衡：分發請求給集羣中的某一臺服務器。
分佈式：根據業務拆分出獨立的服務，可以擁有自己的數據庫，服務之間互不影響。
關係：爲了使服務更加靈活，我們希望每種業務都有自己獨立的服務，可供任何項目調用，所以用到了分佈式；想要使服務高可用，就需要再以集羣的方式部署，那麼管理請求時，自然會用到負載均衡。
負載均衡
常用的負載均衡工具有 nginx，zookeeper，eureka 等，我們需要配置集羣中的各臺服務器信息，還可以指定分發請求的方式。