關(guān)于代理

說(shuō)到代理，首先我們要明確一個(gè)概念赁严，所謂代理就是一個(gè)代表扰柠、一個(gè)渠道；此時(shí)就涉及到兩個(gè)角色疼约，一個(gè)是被代理角色卤档，一個(gè)是目標(biāo)角色。

被代理角色通過(guò)這個(gè)代理訪問(wèn)目標(biāo)角色完成一些任務(wù)的過(guò)程稱(chēng)為代理操作過(guò)程程剥；如同生活中的專(zhuān)賣(mài)店劝枣，客人到 adidas 專(zhuān)賣(mài)店買(mǎi)了一雙鞋，這個(gè)專(zhuān)賣(mài)店就是代理织鲸，被代理角色就是 adidas 廠家舔腾，目標(biāo)角色就是用戶。

正向代理

說(shuō)反向代理之前搂擦，我們先看看正向代理稳诚，正向代理也是大家最常接觸到的代理模式，我們會(huì)從兩個(gè)方面來(lái)說(shuō)關(guān)于正向代理的處理模式瀑踢，分別從軟件方面和生活方面來(lái)解釋一下什么叫正向代理扳还。

在如今的網(wǎng)絡(luò)環(huán)境下，我們?nèi)绻捎诩夹g(shù)需要要去訪問(wèn)國(guó)外的某些網(wǎng)站橱夭，此時(shí)你會(huì)發(fā)現(xiàn)位于國(guó)外的某網(wǎng)站我們通過(guò)瀏覽器是沒(méi)有辦法訪問(wèn)的氨距。

此時(shí)大家可能都會(huì)用一個(gè)操作 FQ 進(jìn)行訪問(wèn)，F(xiàn)Q 的方式主要是找到一個(gè)可以訪問(wèn)國(guó)外網(wǎng)站的代理服務(wù)器棘劣，我們將請(qǐng)求發(fā)送給代理服務(wù)器俏让，代理服務(wù)器去訪問(wèn)國(guó)外的網(wǎng)站，然后將訪問(wèn)到的數(shù)據(jù)傳遞給我們！

上述這樣的代理模式稱(chēng)為正向代理舆驶，正向代理最大的特點(diǎn)是客戶端非常明確要訪問(wèn)的服務(wù)器地址橱健；服務(wù)器只清楚請(qǐng)求來(lái)自哪個(gè)代理服務(wù)器，而不清楚來(lái)自哪個(gè)具體的客戶端沙廉；正向代理模式屏蔽或者隱藏了真實(shí)客戶端信息拘荡。

來(lái)看個(gè)示意圖（我把客戶端和正向代理框在一塊，同屬于一個(gè)環(huán)境撬陵，后面我有介紹）：

正向代理.png

客戶端必須設(shè)置正向代理服務(wù)器珊皿，當(dāng)然前提是要知道正向代理服務(wù)器的 IP 地址，還有代理程序的端口巨税。

如下圖：

設(shè)置端口.png

總結(jié)來(lái)說(shuō)：正向代理蟋定，"它代理的是客戶端"，是一個(gè)位于客戶端和原始服務(wù)器（Origin Server）之間的服務(wù)器草添，為了從原始服務(wù)器取得內(nèi)容驶兜，客戶端向代理發(fā)送一個(gè)請(qǐng)求并指定目標(biāo)（原始服務(wù)器）。
然后代理向原始服務(wù)器轉(zhuǎn)交請(qǐng)求并將獲得的內(nèi)容返回給客戶端远寸〕纾客戶端必須要進(jìn)行一些特別的設(shè)置才能使用正向代理。

正向代理的用途：
訪問(wèn)原來(lái)無(wú)法訪問(wèn)的資源驰后，如 Google肆资。可以做緩存灶芝，加速訪問(wèn)資源郑原。對(duì)客戶端訪問(wèn)授權(quán)，上網(wǎng)進(jìn)行認(rèn)證夜涕。代理可以記錄用戶訪問(wèn)記錄（上網(wǎng)行為管理）犯犁，對(duì)外隱藏用戶信息。

反向代理

明白了什么是正向代理女器，我們繼續(xù)看關(guān)于反向代理的處理方式栖秕，舉例如我國(guó)的某寶網(wǎng)站，每天同時(shí)連接到網(wǎng)站的訪問(wèn)人數(shù)已經(jīng)爆表晓避，單個(gè)服務(wù)器遠(yuǎn)遠(yuǎn)不能滿足人民日益增長(zhǎng)的購(gòu)買(mǎi)欲望了。

此時(shí)就出現(xiàn)了一個(gè)大家耳熟能詳?shù)拿~：分布式部署只壳；也就是通過(guò)部署多臺(tái)服務(wù)器來(lái)解決訪問(wèn)人數(shù)限制的問(wèn)題俏拱。

某寶網(wǎng)站中大部分功能也是直接使用 Nginx 進(jìn)行反向代理實(shí)現(xiàn)的，并且通過(guò)封裝 Nginx 和其他的組件之后起了個(gè)高大上的名字：Tengine吼句。有興趣的童鞋可以訪問(wèn) Tengine 的官網(wǎng)查看具體的信息

那么反向代理具體是通過(guò)什么樣的方式實(shí)現(xiàn)的分布式的集群操作呢锅必，我們先看一個(gè)示意圖（我把服務(wù)器和反向代理框在一塊，同屬于一個(gè)環(huán)境，后面我有介紹）：

反向代理.png

通過(guò)上述的圖解大家就可以看清楚了搞隐，多個(gè)客戶端給服務(wù)器發(fā)送的請(qǐng)求驹愚，Nginx 服務(wù)器接收到之后，按照一定的規(guī)則分發(fā)給了后端的業(yè)務(wù)處理服務(wù)器進(jìn)行處理了劣纲。

此時(shí)請(qǐng)求的來(lái)源也就是客戶端是明確的逢捺，但是請(qǐng)求具體由哪臺(tái)服務(wù)器處理的并不明確了，Nginx 扮演的就是一個(gè)反向代理角色癞季。

客戶端是無(wú)感知代理的存在的劫瞳，反向代理對(duì)外都是透明的，訪問(wèn)者并不知道自己訪問(wèn)的是一個(gè)代理绷柒。因?yàn)榭蛻舳瞬恍枰魏闻渲镁涂梢栽L問(wèn)志于。

反向代理，"它代理的是服務(wù)端"废睦，主要用于服務(wù)器集群分布式部署的情況下伺绽，反向代理隱藏了服務(wù)器的信息
反向代理的作用：
保證內(nèi)網(wǎng)的安全，通常將反向代理作為公網(wǎng)訪問(wèn)地址嗜湃，Web 服務(wù)器是內(nèi)網(wǎng)奈应。負(fù)載均衡，通過(guò)反向代理服務(wù)器來(lái)優(yōu)化網(wǎng)站的負(fù)載净蚤。

項(xiàng)目場(chǎng)景

通常情況下钥组，我們?cè)趯?shí)際項(xiàng)目操作時(shí)，正向代理和反向代理很有可能會(huì)存在同一個(gè)應(yīng)用場(chǎng)景中今瀑，正向代理代理客戶端的請(qǐng)求去訪問(wèn)目標(biāo)服務(wù)器程梦，目標(biāo)服務(wù)器是一個(gè)反向單利服務(wù)器，反向代理了多臺(tái)真實(shí)的業(yè)務(wù)處理服務(wù)器橘荠。

具體的拓?fù)鋱D如下：

image.png

截了一張圖來(lái)說(shuō)明正向代理和反向代理二者之間的區(qū)別屿附，如下圖：

正、反向代理拓?fù)鋱D.png

圖解：
在正向代理中哥童，Proxy 和 Client 同屬于一個(gè) LAN（圖中方框內(nèi)）挺份，隱藏了客戶端信息。在反向代理中贮懈，Proxy 和 Server 同屬于一個(gè) LAN（圖中方框內(nèi)）匀泊，隱藏了服務(wù)端信息。
實(shí)際上朵你，Proxy 在兩種代理中做的事情都是替服務(wù)器代為收發(fā)請(qǐng)求和響應(yīng)各聘，不過(guò)從結(jié)構(gòu)上看正好左右互換了一下，所以把后出現(xiàn)的那種代理方式稱(chēng)為反向代理了抡医。

負(fù)載均衡

我們已經(jīng)明確了所謂代理服務(wù)器的概念躲因，那么接下來(lái)，Nginx 扮演了反向代理服務(wù)器的角色，它是依據(jù)什么樣的規(guī)則進(jìn)行請(qǐng)求分發(fā)的呢大脉？不用的項(xiàng)目應(yīng)用場(chǎng)景搞监，分發(fā)的規(guī)則是否可以控制呢？

這里提到的客戶端發(fā)送的镰矿、Nginx 反向代理服務(wù)器接收到的請(qǐng)求數(shù)量琐驴，就是我們說(shuō)的負(fù)載量。請(qǐng)求數(shù)量按照一定的規(guī)則進(jìn)行分發(fā)衡怀，到不同的服務(wù)器處理的規(guī)則棍矛，就是一種均衡規(guī)則。

所以將服務(wù)器接收到的請(qǐng)求按照規(guī)則分發(fā)的過(guò)程抛杨，稱(chēng)為負(fù)載均衡够委。

負(fù)載均衡在實(shí)際項(xiàng)目操作過(guò)程中，有硬件負(fù)載均衡和軟件負(fù)載均衡兩種怖现，硬件負(fù)載均衡也稱(chēng)為硬負(fù)載茁帽，如 F5 負(fù)載均衡，相對(duì)造價(jià)昂貴成本較高屈嗤。

但是數(shù)據(jù)的穩(wěn)定性安全性等等有非常好的保障潘拨，如中國(guó)移動(dòng)中國(guó)聯(lián)通這樣的公司才會(huì)選擇硬負(fù)載進(jìn)行操作。

更多的公司考慮到成本原因饶号，會(huì)選擇使用軟件負(fù)載均衡铁追，軟件負(fù)載均衡是利用現(xiàn)有的技術(shù)結(jié)合主機(jī)硬件實(shí)現(xiàn)的一種消息隊(duì)列分發(fā)機(jī)制。

負(fù)載均衡.png

Nginx 支持的負(fù)載均衡調(diào)度算法方式如下：

①weight 輪詢（默認(rèn)）：接收到的請(qǐng)求按照順序逐一分配到不同的后端服務(wù)器茫船，即使在使用過(guò)程中琅束，某一臺(tái)后端服務(wù)器宕機(jī)，Nginx 會(huì)自動(dòng)將該服務(wù)器剔除出隊(duì)列算谈，請(qǐng)求受理情況不會(huì)受到任何影響涩禀。
這種方式下，可以給不同的后端服務(wù)器設(shè)置一個(gè)權(quán)重值（weight）然眼，用于調(diào)整不同的服務(wù)器上請(qǐng)求的分配率艾船。
權(quán)重?cái)?shù)據(jù)越大，被分配到請(qǐng)求的幾率越大高每；該權(quán)重值屿岂，主要是針對(duì)實(shí)際工作環(huán)境中不同的后端服務(wù)器硬件配置進(jìn)行調(diào)整的。

②ip_hash：每個(gè)請(qǐng)求按照發(fā)起客戶端的 ip 的 hash 結(jié)果進(jìn)行匹配鲸匿，這樣的算法下一個(gè)固定 ip 地址的客戶端總會(huì)訪問(wèn)到同一個(gè)后端服務(wù)器雁社，這也在一定程度上解決了集群部署環(huán)境下 Session 共享的問(wèn)題。

③fair：智能調(diào)整調(diào)度算法晒骇，動(dòng)態(tài)的根據(jù)后端服務(wù)器的請(qǐng)求處理到響應(yīng)的時(shí)間進(jìn)行均衡分配。
響應(yīng)時(shí)間短處理效率高的服務(wù)器分配到請(qǐng)求的概率高，響應(yīng)時(shí)間長(zhǎng)處理效率低的服務(wù)器分配到的請(qǐng)求少洪囤，它是結(jié)合了前兩者的優(yōu)點(diǎn)的一種調(diào)度算法徒坡。
但是需要注意的是 Nginx 默認(rèn)不支持 fair 算法，如果要使用這種調(diào)度算法瘤缩，請(qǐng)安裝 upstream_fair 模塊喇完。

④url_hash：按照訪問(wèn)的 URL 的 hash 結(jié)果分配請(qǐng)求，每個(gè)請(qǐng)求的 URL 會(huì)指向后端固定的某個(gè)服務(wù)器剥啤，可以在 Nginx 作為靜態(tài)服務(wù)器的情況下提高緩存效率锦溪。
同樣要注意 Nginx 默認(rèn)不支持這種調(diào)度算法，要使用的話需要安裝 Nginx 的 hash 軟件包府怯。

Web 服務(wù)器對(duì)比

幾種常用 Web 服務(wù)器對(duì)比如下圖：

web服務(wù)器對(duì)比.png

源自：https://baijiahao.baidu.com/s?id=1652608869911988442&wfr=spider&for=pc