關於大型網站技術演化的思考（十八）--網站靜態化處理—反向 Proxy（10）

標籤：

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

     我如此批評單獨部署反向 Proxy的問題，但是我並不是說這種做法完全不可取，而是想告訴大家這種做法其實是一種進階的做法，但是也是一個複雜的做法，要做好這個叢集是很麻煩的一件事情的，我覺得只有當我們的網站業務量和請求量很大的時候，同時原有方案出現了瓶頸時候可以認真考慮反向 Proxy叢集方案的實現，不過將反向 Proxy形成叢集會給網站的安全性帶來莫大的好處，反向 Proxy可以隱藏背景應用伺服器，這種隱藏就是用戶端只需要訪問Proxy 伺服器即可，應用伺服器對外都是以反向 Proxy來展示的，但是如果反向 Proxy和應用伺服器一一對應，那麼惡意駭客找准了某台反向 Proxy伺服器後，對這個反向 Proxy伺服器進行反覆的攻擊，那麼這個攻擊也就等於攻擊與之對應的應用伺服器，這就導致反向 Proxy隱藏真實應用伺服器的作用就沒有得到有效發揮，而叢集這塊就可以很好的處理這個問題，不過我們如果覺得使用叢集代價太高，我們也有變通的方法，那就是在所有邏輯應用程式伺服器前面再放置一個反向 Proxy伺服器，這個反向 Proxy伺服器不再承擔緩衝的功能，而只是用來做負載平衡和安全處理，這樣一一對應的策略安全性也可以得到保證，不過如果公司技術能力好可以考慮使用LVS這種軟體化的負載平衡技術方案，假如公司還很有錢還可以考慮使用更加進階的硬體負載平衡裝置例如F5裝置。

     如果我們網站除了使用網站靜態化技術還使用了前後端分離技術，當然這個前後端分離技術應該是使用nodejs的前後端分離技術，那麼nodejs應該放置在生產部署的什麼位置上了？上篇文章裡我曾列舉了一個nodejs的應用實踐情境，在這個實踐情境裡我曾經提到如果在原有的網站生產架構下引入nodejs會增加一個請求處理環節，而nodejs使用主要是為了滿足前後端分離而非增加網站效能，因此增加的環節可能會讓請求處理的效能下降，因此我最後提出一種變通手法，就是nodejs項目發布時候編譯原始碼，然後將編譯出的javascript和html檔案乾脆推移到瀏覽器端處理，這樣就變相形成了前端MVC架構，這個做法總是有點不倫不類的意味，假如我們真的想把nodejs引入到應用生產的網路架構裡，我們不希望無端的增加請求處理環節，那麼最好是讓nodejs伺服器替換某個部分。按照這個思路思考，那麼我覺得nodejs在生產的引入最好是和反向 Proxy相關，最簡單的方式就是讓nodejs和反向 Proxy一一對應，這樣就可以很好的降低引入nodejs帶來的問題，當然複雜點的就是反向 Proxy叢集對應的應用伺服器應該是nodejs的應用伺服器，而不是用來做業務處理的業務層級的應用伺服器。

    不管怎麼說，我認為在網站靜態化方案裡我們一定要考慮反向 Proxy的運用，如果靜態化技術方案裡沒有反向 Proxy的身影，那麼這個網站靜態化處理可能很難達到我們預期的效果。

    好了，今天就寫到這裡，最後祝大家晚安。

關於大型網站技術演化的思考（十八）--網站靜態化處理—反向 Proxy（10）