反向代理的方法

反向代理也是一種可以幫助實現網站靜態化的重要技術，今天我就來講講反向代理這個主題。那麼首先我們要了解下什麼是反向代理。和反向代理相對應的是正向代理，正向代理也就是我們常說的代理服務，正向代理是非常常見的，例如在某些公司裡我們想使用互聯網，那麼我們就得在浏覽器裡設置一個代理服務器，通過代理服務器我們才能正常使用互聯網，而這個代理服務器就是一個正向代理服務器。正向代理更加讓人熟悉的使用場景估計還是在FQ技術裡的使用，我們使用一個放置在國外的代理服務器來訪問那些在國內無法正常訪問的網站，這其實也是在使用一個正向代理服務。

其實不管是正向代理還是反向代理，這兩個概念的定義都是以浏覽器側為基准進行的，正向代理是代理浏覽器來訪問互聯網，反向代理是指代理不再是代理浏覽器側了，而是反過來代理浏覽器需要訪問的應用服務器。那為什麼我們要使用正向代理服務器了?答案當然不是為了FQ了，下面我來列舉些實例來說明這個問題了。

例如公司裡使用代理服務器主要是為了安全的考慮，很多公司內部都有自己的局域網，一般我們稱之為內網，內網裡有公司的各種資源，如果公司員工的電腦隨意連接到互聯網，假如碰到那些別有用心的黑客，通過攻擊員工的工作電腦截取了公司重要的文件資料，那樣就會造成公司的重大損失，正向代理除了能防范外部的黑客攻擊外還能監控和控制公司內部員工將公司重要文件通過互聯網傳遞給不恰當的人，因此公司讓員工使用代理上網基本都是出於安全的角度來考慮的。

正向代理的合理使用還能幫助一些企業提升自己產品的核心競爭力，例如在移動端有一款非常流行的浏覽器，它之所以非常受用戶的歡迎，是因為使用該浏覽器上網速度比其他浏覽器明顯的快多了，那麼這款浏覽器是如何做到這點的呢?奧秘就是這家公司為自己的浏覽器對應建立一個十分強大的代理服務器集群，用戶使用該浏覽器訪問網站時候用戶首先訪問的是該公司的代理服務器，而這些代理服務器使用緩存技術緩存了海量的網站信息，再加上使用一些web加速的技術例如CDN技術，這就讓該浏覽器訪問網站的效率明顯快於其他浏覽器。

反向代理和正向代理從技術角度上基本上是一致的，區別主要是代理的內容不一樣了，反向代理代理的是應用服務器。反向代理技術也基本上是互聯網公司的一個標配技術，但是反向代理能否正確使用，能否更進一步的發揮它的實用價值，我覺得並不是所有公司都能做好的，下面我來總結一下反向代理的使用目的吧，具體如下：

使用目的一：反向代理可以隱藏真實的應用服務器。該目的屬於安全的范疇，反向代理隱藏真實的應用服務器，那麼就可以讓別有用心的黑客很難掌握正確的應用服務器，從而增加黑客的攻擊難度。

使用目的二：反向代理可以實現負載均衡的功能，例如在java的web開發裡有一種很簡單的實現集群的手段，這個手段就是使用apache加上tomcat的組合，用戶請求先到達前置的apache服務器，apache再使用負載均衡策略將請求分配給後台不同的tomcat服務器上。

使用目的三：反向代理可以起到動態調節應用服務器並發數的目的，一般用作反向代理的服務器都是靜態資源服務器，這樣的服務器在並發處理能力上要遠強於後台的web應用服務器，那麼可以通過控制web應用服務器前置的反向代理服務器，這樣就可以動態調節後台服務的負載的大小，這個做法的好處可能很多朋友都不太了解，這裡我列舉個例子，一個網站最需要穩定性的部分是哪個部分呢?很多朋友會說是數據庫，的確數據庫是最重要的，因為數據庫做分布式很難，很容易形成單點故障，要是數據庫掛了基本一切都沒法玩了，那麼除了數據庫之外還有別的嗎?當然有，那就是用於處理業務的應用服務器了，應用服務器如果做了集群，集群中其中一台服務器掛了其影響面會比數據庫掛掉低多了，但是一個網站的做業務處理的應用服務器掛掉，對公司的損失還是很大的，而web應用服務器前面的用作反向代理的靜態資源服務器掛掉問題就會小多了，至少不會產生公司業務無法正常完成的事情了，因此當網站負載過高，讓過載的請求被反向代理攔截或者阻止，這對應用服務器的穩定性提升有莫大的好處。當然反向代理調節應用服務器的負載水平的用途不僅僅這些，有興趣的朋友可以在網絡上找找相關的介紹。

使用目的四：反向代理可以緩存靜態數據，一般用作反向代理的服務器都是使用像apache或者是ngnix這樣的靜態資源服務器，因此我們可以把web應用裡的靜態資源緩存在反向代理服務器上，從而達到提升請求處理的速度問題。反向代理的這個功能就和本系列的主題網站靜態化處理切合了。

分析完反向代理的使用目的後，我們現在將反向代理應用到項目裡，這裡應用的一個前置限定就是將反向代理應用到網站靜態化的處理之上，首先是第一個應用方式，如下圖所示：

第一種反向代理應用方式就是讓反向代理和應用服務器一一對應，也就是每台應用服務的部署服務器上都對應部署一台反向代理服務器，這麼做有怎樣的好處呢?首先我們來講第一個好處，如果我們將網頁做了動靜分離，那麼反向代理服務器就可以負責對請求中的靜態資源訪問進行處理，同時反向代理還可以承擔動靜資源整合的目的。這裡要特別說明下，前文裡我說道動靜資源會因為我們使用的動靜策略而發生轉化，那麼有些動態內容在一定條件被轉化為靜態資源後，我們可以將這些做了轉化的靜態資源在服務器上緩存起來，這個時候上圖展示的架構模型就會發生變化，如下圖所示：

我們看到反向代理服務器和應用服務器之間會形成一個cache層，反向代理訪問cache層的效率會比直接訪問應用服務器要高的多，這等於是給應用服務器做了一個加速操作，同時通過緩存我們可以減少應用服務器的運算壓力，從而達到提升應用服務器性能的目的。以前有朋友問我這麼做會不會增加應用服務器的壓力，因為一台服務器上部署了兩台可以處理web請求的服務器，那麼它們之間一定會有發生沖突的時候，不過我想產生沖突肯定是我們沒有很好的處理二者關系所致，所以我們要理清在同一台服務器上部署反向代理和應用服務器後，它們之間的關系到底是怎樣的?

其實反向代理和應用服務器從物理形態角度上它們是兩個不同的東西，但是二者在邏輯上其實是一個整體，它們共同完成一個邏輯性的應用服務器的功能，只不過二者因為應用場景不同而形成了一種分工合作的關系，反向代理服務器主要完成對靜態資源請求的處理，而應用服務器則是負責業務邏輯的處理，它們最終形成一個強大的合力使得整體的邏輯性應用服務器的性能得到顯著的提升。

除此之外，這個反向代理還可以發揮動態調節應用服務器的並發數的目的，但是上面的技術方案卻沒有發揮反向代理的負載均衡以及安全性這兩個方面的作用。為了讓反向代理四個使用目的得到充分的發揮，那麼我們該如何來做了?

方法很簡單就是把反向代理的部署地點從應用服務器所在的物理服務器上遷移出來，放到一台獨立的物理服務器上，但是這個做法會有性能上的損失，同時還會增加整個技術架構的復雜性。為什麼性能會損失呢?因為原來的反向代理服務器和應用服務器部署在同一個物理服務器上，那麼它們之間的通訊都是以內存共享的方式進行的，這樣的通訊效率是非常高，現在換成了通過網絡通訊進行溝通，而網絡通訊是IO設備裡效率最差，可靠性最差的，因此單獨部署反向代理服務器或多或少都會造成一定性能的損失。

為什麼說單獨部署反向代理會增加整個網站技術架構的復雜性了?我們把反向代理服務器單獨部署，那麼單獨部署時候我們還會是使用一一對應的策略嗎?先不談這麼做，從技術和業務角度的好處和壞處，但從成本這個考慮就是會讓很多公司望而卻步，因為這個做法就會導致用於部署應用服務器的成本翻倍的增加，而增加的服務器用於反向代理，這樣的做法怎麼體會都不是覺得物有所值，再說用於反向代理的靜態資源服務器本身處理請求的並發能力是普通應用服務器的數百倍，一一對應本身也沒有完全發揮反向代理服務器的潛力，因此最好的解決方法就是把反向代理服務器做成一個反向代理服務器集群，做成集群問題又來，集群裡每台反向代理緩存的數據是不是要保持一個同步了?這就好比處理應用服務器的session同步問題，如果真的這麼做會不會導致反向代理服務器上緩存大量使用率不高的數據從而導致緩存的利用率很差，同時同步操作本身也會影響到反向代理集群的性能，所以要設計一個好的反向代理集群是一件十分復雜的事情，其實合理的反向代理集群的做法就是在集群裡在進行分組，每個分組應該是和後端的SOA服務相匹配，這個時候反向代理集群的效率才能得到最大的發揮，同時資源利用率也會更加的合理。其實使用反向代理集群方式，也會給生產部署造成麻煩，如果網站進行了靜態化處理，那麼反向代理需要承擔對靜態資源的處理操作，這個時候反向代理和對應的應用服務器結合起來才能形成一個完整的應用服務器，但是現在我們將一個完整的邏輯應用服務器分開部署了，那麼當我們發布新應用的時候就得面臨更加復雜的情況，這就增加了部署和運維的風險和難度。

我如此批評單獨部署反向代理的問題，但是我並不是說這種做法完全不可取，而是想告訴大家這種做法其實是一種高級的做法，但是也是一個復雜的做法，要做好這個集群是很麻煩的一件事情的，我覺得只有當我