我最喜歡講故事了，讓我來給你慢慢講...

高富帥家是開餐飲店的，高富帥每天要打醬油，買菜，炒菜，一個人要幹很多活，相當的忙碌，覺得實在是幹不下去了！（整合服務要崩潰了），整合系統圖示:

所幸高富帥有三個孩子大牛，二牛，三牛（三臺不同的伺服器），高富帥分配（任務集中排程）大牛去打醬油，二牛買菜，三牛炒菜，三人各有分工，各司其職！（提供不同的服務）這樣就組成了一個分散式服務架構圖示:

負載均衡和均衡方式:再看大牛，這個人本身事情也多，不願意天天去打醬油，遂安排他的七個兒子(從大娃到七娃）每天分別去打醬油（1，輪詢方式:負載均衡的其中策略之一，當然負載均衡有其他的策略方式:2，分配:三娃跑得快，經常安排他去，就是按照響應時間的分配方式，3，隨機方式，看到誰叫誰去！4，hash方式:看日子，誰更適合出去打醬油），這樣七個娃做的事情一樣，都是打醬油（提供相同的服務），有天輪到七娃打醬油了，但是七娃病了（宕機），然後大牛又重新找了五娃去，（重新選擇健康服務），大牛家就組成了一個叢集，對外提供打醬油服務！

整個系統當中，爺爺高富帥是一個負載均衡，負責集中管理分配服務（類似eureka服務註冊中心），爸爸大牛也是一個負載均衡，負責分配服務到不同的兒子身上（類似nginx的分發）！

整個架構是一個分散式系統架構（每個人都負責不同的事情，並且是不同的伺服器，有打醬油，買菜，炒菜服務），大牛和兒子組成一個叢集（對外提供打醬油！）！

如果還不懂分散式，叢集，負載均衡，你關注私聊我，我再慢慢跟你講！

1、負載均衡

銀行辦理業務共有5個視窗。設定了一個規則，當一個視窗排隊超過2人時，馬上增加一新視窗辦理，分流排隊；當5個視窗全部啟用運作後（10個客戶），後續新增加的客戶，5個視窗逐個安排輪轉，保持每兩個視窗之間的客戶數量差小於等於1。這種方法，就是負載均衡，將客流均衡的分佈引流到各個視窗，避免一個視窗擁堵，其他視窗閒置，以提高效率。

同樣的銀行業務辦理視窗，發現每天超負荷運轉，依然無法滿足需求；同時發現很多客戶從其他行政區大老遠趕來排隊，效率低、使用者體驗很差。於是，提出建立業務分點的方案，透過調研統計分析，在客戶數量較多的另外幾個區，都建立起了支行，客戶可就近辦理業務，效率提升、使用者滿意度提升。這就是分散式，各分部網點（支行）辦理業務的模式和總行相同，且各網點業務分佈辦理（分佈計算），資料實時或定時同步。

同時的銀行業務辦理視窗，一個工作人員辦理一個客戶的業務，要耗費很長時間，原因是一個人只能逐個處理諸如錄單、列印、影印、掃描、存取等業務支流活動。透過分析發現，可以把這些業務分隔細分，並行處理，例如錄單的同時，可以影印掃描。於是，除了5個視窗的5名工作人員，又配備了1名專職影印掃描的人員和1名傳遞運送的人員。當業務量逐漸增多後，配備的人員數量也增加，這樣，業務並行處理，每個處理環節，根據業務量大小變化，增減人員配備數量，效率因此大幅提升。這就是叢集，按需增減，保證效率和資源之間的平衡。