服務(wù)的路由和負(fù)載均衡

公共的業(yè)務(wù)被拆分出來，形成可共用的服務(wù)，最大程度的保證了代碼和邏輯的復(fù)用，避免重復(fù)建設(shè)，這種設(shè)計(jì)也被成為SOA(Service-Oriented Architecture)
SOA架構(gòu)中，服務(wù)消費(fèi)者通過服務(wù)名稱，在眾多服務(wù)中找到要調(diào)用的服務(wù)的地址列表，成為服務(wù)的路由：

而對(duì)于負(fù)載較高的服務(wù)來說，往往對(duì)應(yīng)著由多臺(tái)服務(wù)器組成的集群。在請(qǐng)求到來時(shí)，為了將請(qǐng)求均衡地分配到后端服務(wù)器，負(fù)載均衡程序?qū)姆?wù)對(duì)應(yīng)的地址列表中，通過相應(yīng)的負(fù)載均衡算法和規(guī)則，選取一臺(tái)服務(wù)器進(jìn)行訪問，這個(gè)過程稱為服務(wù)的負(fù)載均衡：

當(dāng)服務(wù)的規(guī)模較小時(shí)，可以采用硬編碼的方式將服務(wù)地址和配置寫在代碼中，通過編碼的方式來解決服務(wù)的路由和負(fù)載均衡問題，也可以通過傳統(tǒng)的硬件負(fù)載均衡設(shè)備如F5等，或者采用LVS或Nginx等軟件解決方案，通過相關(guān)配置，來解決服務(wù)的路由和負(fù)載均衡問題。由于服務(wù)的機(jī)器數(shù)量在可控范圍內(nèi)，因?yàn)榫S護(hù)成本能夠接受。

當(dāng)服務(wù)越來越多，規(guī)模越來越大時(shí)，對(duì)應(yīng)的機(jī)器數(shù)量也越來越龐大。單靠人工來管理和維護(hù)服務(wù)及地址的配置信息等，已經(jīng)越來與困難。并且，依賴單一的硬件負(fù)載均衡設(shè)備或者使用LVS、Nginx等軟件解決方案進(jìn)行路由和負(fù)載均衡調(diào)度，單點(diǎn)故障的問題也開始凸顯，一旦服務(wù)路由或者負(fù)載均衡服務(wù)器宕機(jī)，依賴它的所有服務(wù)均將失效。

此時(shí)，需要一個(gè)能夠動(dòng)態(tài)注冊(cè)和獲取服務(wù)信息的地方，來統(tǒng)一管理服務(wù)名稱和其對(duì)應(yīng)的服務(wù)器列表信息，稱之為服務(wù)配置中心。服務(wù)提供者在啟動(dòng)時(shí)，將其提供的服務(wù)名稱、服務(wù)地址注冊(cè)到服務(wù)配置中心，服務(wù)消費(fèi)者通過服務(wù)配置中心來獲得需要調(diào)用的服務(wù)的機(jī)器列表，通過相應(yīng)的負(fù)載均衡算法，選取其中一臺(tái)服務(wù)器進(jìn)行調(diào)用。當(dāng)服務(wù)器宕機(jī)或者下線時(shí)，相應(yīng)的機(jī)器需要能夠動(dòng)態(tài)的從服務(wù)配置中心里面移除，并通知相應(yīng)的服務(wù)消費(fèi)者，否則服務(wù)消費(fèi)者就有可能因?yàn)檎{(diào)用到已經(jīng)失效的服務(wù)而發(fā)生錯(cuò)誤。在這個(gè)過程中，服務(wù)消費(fèi)者只有在第一次調(diào)用服務(wù)時(shí)需要查詢服務(wù)配置中心，然后將查詢到的信息緩存到本地，后面的調(diào)用直接使用本地緩存的服務(wù)地址列表信息，而不需要重新發(fā)起請(qǐng)求到服務(wù)配置中心去獲取相應(yīng)的服務(wù)地址列表，直到服務(wù)的地址列表有變更（機(jī)器上線或者下線）。這種無中心化的結(jié)構(gòu)解決了之前負(fù)載均衡設(shè)備所導(dǎo)致的單點(diǎn)故障問題并且大大減輕了服務(wù)配置中心的壓力。
基于Zookeper的持久和非持久節(jié)點(diǎn)，我們能夠近乎實(shí)時(shí)的感知到后端服務(wù)器的狀態(tài)（上線、下線、宕機(jī)）。通過集群間zab協(xié)議，使得服務(wù)配置信息能夠保持一致。而Zookeeper本身容錯(cuò)特性和leader選舉機(jī)制，能保障我們方便的進(jìn)行擴(kuò)容。通過Zookeeper來實(shí)現(xiàn)服務(wù)動(dòng)態(tài)注冊(cè)、機(jī)器上線與下線的動(dòng)態(tài)感知、擴(kuò)容方便、容錯(cuò)性好，且無中心化結(jié)構(gòu)能夠解決之前使用負(fù)載均衡設(shè)備所帶來的單點(diǎn)故障問題，只有當(dāng)配置信息更新時(shí)才會(huì)去Zookeeper上獲取最新的服務(wù)地址列表，其他時(shí)候使用本地緩存即可。

負(fù)載均衡算法

服務(wù)消費(fèi)者從服務(wù)配置中心獲取到服務(wù)的地址列表后,需要選擇其中一臺(tái)來發(fā)起RPC調(diào)用。如何選擇，則取決于具體的負(fù)載均衡算法，對(duì)應(yīng)于不同的場(chǎng)景，選擇負(fù)載均衡算法也不盡相同。

• 輪詢法(Round Robin)
  將請(qǐng)求按順序輪流的分配到后端服務(wù)器上，它均衡的對(duì)待后端每一臺(tái)服務(wù)器，而不關(guān)心服務(wù)器實(shí)際的連接數(shù)和當(dāng)前的系統(tǒng)負(fù)載
• 隨機(jī)法
  通過系統(tǒng)隨機(jī)函數(shù)，根據(jù)后端服務(wù)器列表大小值來隨機(jī)選取其中一臺(tái)進(jìn)行訪問。
• 源地址哈希（Hash）法
  獲取客戶端訪問的IP地址值，通過哈希函數(shù)計(jì)算得到一個(gè)數(shù)值，用該數(shù)值對(duì)服務(wù)器列表的大小進(jìn)行取摩運(yùn)算，得到的結(jié)果便是要訪問的服務(wù)器的序號(hào)。采用哈希發(fā)進(jìn)行負(fù)載均衡，同一IP地址的客戶端，當(dāng)后端服務(wù)器列表不變時(shí)，它每次都會(huì)被映射到同一臺(tái)后端服務(wù)器進(jìn)行訪問。
• 加權(quán)輪詢法（Weight Round Robin）
  不同的后端服務(wù)器可能機(jī)器的配置和當(dāng)前系統(tǒng)的負(fù)載并不相同，因?yàn)樗麄兊目箟耗芰σ膊槐M相同。給配置高、負(fù)載低的機(jī)器配置更高的權(quán)重，讓其處理更多的請(qǐng)求，而低配置、負(fù)載高的機(jī)器，則給其分配較低的權(quán)重，降低其系統(tǒng)負(fù)載。加權(quán)輪詢能吹該問題并將請(qǐng)求順序且按照權(quán)重分配到后端。
  注意：目前的代碼實(shí)現(xiàn)是如果某機(jī)器A權(quán)重配的比較高，則serverlist中該機(jī)器A會(huì)按照權(quán)重被加入多次，即serverlist中有多個(gè)A，則按照輪詢法則會(huì)處理更多請(qǐng)求.
• 加權(quán)隨機(jī)法(Weight Random) 與加權(quán)輪詢法類似，加權(quán)隨機(jī)法也根據(jù)后端服務(wù)器不同的配置和負(fù)載情況，配置不同的權(quán)重、不同的是，它是按照權(quán)重來隨機(jī)選取服務(wù)器的，而非順序。
• 最小連接數(shù)法（Least Connections） 根據(jù)后端服務(wù)器當(dāng)前的連接情況，動(dòng)態(tài)的選取其中當(dāng)前積壓連接數(shù)最少的一臺(tái)服務(wù)器來處理當(dāng)前請(qǐng)求，盡可能的提高后端服務(wù)器的利用效率，將負(fù)載合理的分流到每一臺(tái)機(jī)器。

路由和負(fù)載均衡的實(shí)現(xiàn)

服務(wù)配置中心節(jié)點(diǎn)樹分成三層結(jié)構(gòu)，最上面一層為根節(jié)點(diǎn)，用來聚集服務(wù)節(jié)點(diǎn)，通過它可以查詢到所有的服務(wù)，而服務(wù)名稱節(jié)點(diǎn)掛載的是服務(wù)提供者的服務(wù)器地址，服務(wù)消費(fèi)者通過負(fù)載均衡算法選擇其中一個(gè)地址發(fā)起遠(yuǎn)程調(diào)用。根節(jié)點(diǎn)和服務(wù)名稱采用的是ZoooKeeper的持久節(jié)點(diǎn)，也就是persistent節(jié)點(diǎn)，而服務(wù)提供者的地址節(jié)點(diǎn)則采用非持久節(jié)點(diǎn)，即ephemeral節(jié)點(diǎn)，一旦服務(wù)器宕機(jī)或者下線，節(jié)點(diǎn)也就隨之消失。

Http網(wǎng)關(guān)

gateway接收外部各種app的http請(qǐng)求，完成相應(yīng)的權(quán)限與安全校驗(yàn)。當(dāng)校驗(yàn)通過后，根據(jù)傳入的服務(wù)名稱，到服務(wù)配置中心找到相應(yīng)的服務(wù)名稱節(jié)點(diǎn)，并加載對(duì)應(yīng)服務(wù)提供者的地址列表，通過前面提到的負(fù)載均衡算法，選取機(jī)器發(fā)起遠(yuǎn)程調(diào)用，將客戶端參數(shù)傳遞到后端服務(wù)端。服務(wù)提供方根據(jù)所傳入的參數(shù)，給出正確的響應(yīng)，當(dāng)gateway接收到響應(yīng)后，再將響應(yīng)輸出給客戶端APP.
對(duì)于外部的APP來說，它依賴gateway進(jìn)行服務(wù)的路由以及請(qǐng)求的轉(zhuǎn)發(fā)，gateway是整個(gè)網(wǎng)絡(luò)的核心節(jié)點(diǎn)，一旦gateway失效，所有依賴它的外部app都將無法使用且流量之大。所以考慮到系統(tǒng)流量的監(jiān)控和容量規(guī)劃以及gateway集群的可擴(kuò)展性，以便在流量達(dá)到極限之前，能夠快速的方便的進(jìn)行系統(tǒng)擴(kuò)容。

一組對(duì)等的服務(wù)器組成網(wǎng)關(guān)集群，接收外部APP的http請(qǐng)求，當(dāng)流量水位達(dá)到警戒值時(shí)，能夠較為方便的增加機(jī)器進(jìn)行擴(kuò)容。網(wǎng)關(guān)的前面有兩臺(tái)負(fù)載均衡設(shè)備，負(fù)載對(duì)網(wǎng)關(guān)集群進(jìn)行負(fù)載均衡，負(fù)載均衡設(shè)備之間進(jìn)行心跳檢測(cè)，一旦其中一臺(tái)進(jìn)行宕機(jī)，另一臺(tái)則變更自己的地址，接管宕機(jī)的這臺(tái)設(shè)備的流量。平時(shí)兩臺(tái)機(jī)器均對(duì)外提供服務(wù)。

分布式系統(tǒng)基礎(chǔ)措施

• 分布式協(xié)作及配置管理系統(tǒng)ZooKeeper
• 分布式緩存系統(tǒng)
• 持久化存儲(chǔ)
• 分布式消息系統(tǒng)
• 搜索引擎
• CDN系統(tǒng)
• 負(fù)載均衡系統(tǒng)
• 運(yùn)維自動(dòng)化系統(tǒng)
• 實(shí)時(shí)計(jì)算系統(tǒng)
• 離線計(jì)算系統(tǒng)
• 分布式文件系統(tǒng)
• 日志收集系統(tǒng)
• 監(jiān)控系統(tǒng)
• 數(shù)據(jù)倉(cāng)庫(kù)