在“高并發(fā)，海量數(shù)據(jù)，分布式，NoSql，云計算……”概念滿天飛的年代，相信不少朋友都聽說過甚至常與人提起“集群，負載均衡”等，

但不是所有人都有機會真正接觸到這些技術，也不是所有人都真正理解了這些“聽起來很牛的”技術名詞。下面簡單解釋一下吧。

要了解這些概念首先要了解一下項目架構的演進，我這里應用一張Dubbo的文檔圖片如圖

ORM與MVC：

早期的架構都集中在一臺服務器上，這樣對于小型的業(yè)務訪問量是完全可以的，但是隨著業(yè)務的增多，我們引進的MVC的架構，這種架構是將整個業(yè)務分成不同的層（表現(xiàn)層，業(yè)務層，數(shù)據(jù)訪問層）維護也更加方面了，開發(fā)更加方便。

PRC架構：

但是業(yè)務如果繼續(xù)增大，項目會出現(xiàn)臃腫，一臺服務器已經(jīng)完全沒辦法支持了，所以出現(xiàn)了RPC分布式的架構，RPC架構就是將服務進行合理拆分，分別放入多臺服務器執(zhí)行，服務器與服務器之間通過遠程調用的方式進行通信。

服務提供者：運行在服務器端，提供服務接口與服務實現(xiàn)類
服務中心：運行在服務器端，負責將本地服務發(fā)布成遠程服務，管理遠程服務，提供服務給消費者使用。
服務消費者：運行在客戶端，通過遠程代理對象調用遠程服務

目前Java中常用的RPC框架：

• Dubbo:

• Spring Cloud:

• Thrift:

SOA架構：

但是業(yè)務繼續(xù)增加，對RPC架構來說，各個服務與服務之間的通信越來越多，依賴越來越多，越來越混亂，給開發(fā)帶來了困難，于是SOA架構應運而生，SOA架構將服務與服務集中起來進行管理，加上一個服務治理中心。誰發(fā)布了服務來中心進行注冊，誰需要依賴什么服務來中心進行請求。

而最近很火的微服務，則是將業(yè)務拆分更加精細，每一個可以成為一個完整的服務。演變肯定會演變，但是過程得多久誰也不好說。

2、名詞解釋

接下來進入正題，解釋讓外行看起來高大上的名詞

集群(Cluster)

所謂集群是指一組獨立的計算機系統(tǒng)構成的一個松耦合的多處理器系統(tǒng)，它們之間通過網(wǎng)絡實現(xiàn)進程間的通信。應用程序可以通過網(wǎng)絡共享內存進行消息傳送，實現(xiàn)分布式計算機。通俗一點來說，就是讓若干臺計算機聯(lián)合起來工作(服務)，可以是并行的，也可以是做備份。

大規(guī)模集群，通常具備以下一些特點：

• 可靠性(HA)：利用集群管理軟件，當主服務器故障時，備份服務器能夠自動接管主服務器的工作，并及時切換過去，以實現(xiàn)對用戶的不間斷服務。

• 高性能計算(HP)：即充分利用集群中的每一臺計算機的資源，實現(xiàn)復雜運算的并行處理，通常用于科學計算領域，比如基因分析、化學分析等。

• 負載平衡(LB)：即把負載壓力根據(jù)某種算法合理分配到集群中的每一臺計算機上，以減輕主服務器的壓力，降低對主服務器的硬件和軟件要求。

常用的集群又分以下幾種：

load balance cluster(負載均衡集群)

一共有四兄弟開裁縫鋪，生意特別多，一個人做不下來，老是延誤工期，于是四個兄弟商量：老大接訂單, 三個兄弟來干活。客戶多起來之后，老大根據(jù)一定的原則(policy) 根據(jù)三兄弟手上的工作量來分派新任務。

High availability cluster(高可用集群)

兩兄弟開早餐鋪，生意不大，但是每天早上7點到9點之間客戶很多并且不能中斷。為了保證2個小時內這個早餐鋪能夠保證持續(xù)提供服務，兩兄弟商量幾個方法:

方法一：平時老大做生意，老二這個時間段在家等候，一旦老大無法做生意了，老二就出來頂上，這個叫做Active/Standby.(雙機熱備)

方法二：平時老大做生意，老二這個時候就在旁邊幫工，一旦老大無法做生意，老二就馬上頂上，這個叫做Active/Passive.(雙機雙工)

方法三：平時老大賣包子，老二也在旁邊賣豆?jié){，老大有問題，老二就又賣包子，又賣豆?jié){，老二不行了，老大就又賣包子，又賣豆?jié){.這個叫做Active/Active (dual Active)(雙機互備)

high computing clustering(高性能計算集群)

10個兄弟一起做手工家具生意，一個客戶來找他們的老爹要求做一套非常復雜的仿古家具，一個人做也可以做，不過要做很久很久，為了1個星期就交出這一套家具，10個兄弟決定一起做。

老爹把這套家具的不同部分分開交給兒子們作，然后每個兒子都在做木制家具的加工，最后拼在一起叫貨。
老爹是scheduler任務調度器，兒子們是compute node. 他們做的工作叫做作業(yè)。

負載均衡

HTTP重定向負載均衡

當用戶發(fā)來請求的時候，Web服務器通過修改HTTP響應頭中的Location標記來返回一個新的url，然后瀏覽器再繼續(xù)請求這個新url，實際上就是頁面重定向。通過重定向，來達到“負載均衡”的目標。例如，我們在下載JAVA源碼包的時候，點擊下載鏈接時，為了解決不同國家和地域下載速度的問題，它會返回一個離我們近的下載地址。重定向的HTTP返回碼是302。

優(yōu)點：比較簡單。

缺點：瀏覽器需要兩次請求服務器才能完成一次訪問，性能較差。重定向服務自身的處理能力有可能成為瓶頸，整個集群的伸縮性國模有限；使用HTTP302響應碼重定向，有可能使搜索引擎判斷為SEO作弊，降低搜索排名。

DNS域名解析負載均衡

DNS（Domain Name System）負責域名解析的服務，域名url實際上是服務器的別名，實際映射是一個IP地址，解析過程，就是DNS完成域名到IP的映射。而一個域名是可以配置成對應多個IP的。因此，DNS也就可以作為負載均衡服務。

事實上，大型網(wǎng)站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到的一組服務器并不是實際提供Web服務的物理服務器，而是同樣提供負載均衡服務的內部服務器，這組內部負載均衡服務器再進行負載均衡，將請求分發(fā)到真是的Web服務器上。

優(yōu)點：將負載均衡的工作轉交給DNS，省掉了網(wǎng)站管理維護負載均衡服務器的麻煩，同時許多DNS還支持基于地理位置的域名解析，即會將域名解析成舉例用戶地理最近的一個服務器地址，這樣可以加快用戶訪問速度，改善性能。

缺點：不能自由定義規(guī)則，而且變更被映射的IP或者機器故障時很麻煩，還存在DNS生效延遲的問題。而且DNS負載均衡的控制權在域名服務商那里，網(wǎng)站無法對其做更多改善和更強大的管理。

反向代理負載均衡

反向代理服務可以緩存資源以改善網(wǎng)站性能。實際上，在部署位置上，反向代理服務器處于Web服務器前面（這樣才可能緩存Web相應，加速訪問），這個位置也正好是負載均衡服務器的位置，所以大多數(shù)反向代理服務器同時提供負載均衡的功能，管理一組Web服務器，將請求根據(jù)負載均衡算法轉發(fā)到不同的Web服務器上。Web服務器處理完成的響應也需要通過反向代理服務器返回給用戶。由于web服務器不直接對外提供訪問，因此Web服務器不需要使用外部ip地址，而反向代理服務器則需要配置雙網(wǎng)卡和內部外部兩套IP地址。

優(yōu)點：和反向代理服務器功能集成在一起，部署簡單。

缺點：反向代理服務器是所有請求和響應的中轉站，其性能可能會成為瓶頸。

負載均衡策略

• 輪詢

• 加權輪詢

• 最少連接數(shù)

• 最快響應

• Hash法

緩存

緩存就是將數(shù)據(jù)存放在距離計算最近的位置以加快處理速度。緩存是改善軟件性能的第一手段，現(xiàn)在CPU越來越快的一個重要因素就是使用了更多的緩存，在復雜的軟件設計中，緩存幾乎無處不在。大型網(wǎng)站架構設計在很多方面都使用了緩存設計。

CDN緩存

內容分發(fā)網(wǎng)絡，部署在距離終端用戶最近的網(wǎng)絡服務商，用戶的網(wǎng)絡請求總是先到達他的網(wǎng)絡服務商哪里，在這里緩存網(wǎng)站的一些靜態(tài)資源（較少變化的數(shù)據(jù)），可以就近以最快速度返回給用戶，如視頻網(wǎng)站和門戶網(wǎng)站會將用戶訪問量大的熱點內容緩存在CDN中。

反向代理緩存

反向代理屬于網(wǎng)站前端架構的一部分，部署在網(wǎng)站的前端，當用戶請求到達網(wǎng)站的數(shù)據(jù)中心時，最先訪問到的就是反向代理服務器，這里緩存網(wǎng)站的靜態(tài)資源，無需將請求繼續(xù)轉發(fā)給應用服務器就能返回給用戶。

本地緩存

在應用服務器本地緩存著熱點數(shù)據(jù)，應用程序可以在本機內存中直接訪問數(shù)據(jù)，而無需訪問數(shù)據(jù)庫。

分布式緩存

大型網(wǎng)站的數(shù)據(jù)量非常龐大，即使只緩存一小部分，需要的內存空間也不是單機能承受的，所以除了本地緩存，還需要分布式緩存，將數(shù)據(jù)緩存在一個專門的分布式緩存集群中，應用程序通過網(wǎng)絡通信訪問緩存數(shù)據(jù)。

3、流控（流量控制）

流量丟棄

通過單機內存隊列來進行有限的等待，直接丟棄用戶請求的處理方式顯得簡單而粗暴，并且如果是I/O密集型應用（包括網(wǎng)絡I/O和磁盤I/O），瓶頸一般不再CPU和內存。因此，適當?shù)牡却饶軌蛱嫔碛脩趔w驗，又能夠提高資源利用率。

通過分布式消息隊列來將用戶的請求異步化。

作者：阿蒼老師
來源：www.cnblogs.com/nullering/p/9311151.html

本公眾號全部博文已整理成一個目錄，請在公眾號后臺回復「m」獲取！