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

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

　　其實無論是正向代理仍是反向代理，這兩個概念的定義都是以瀏覽器側爲基準進行的，正向代理是代理瀏覽器來訪問互聯網，反向代理是指代理再也不是代理瀏覽器側了，而是反過來代理瀏覽器須要訪問的應用服務器。那爲何咱們要使用正向代理服務器了？答案固然不是爲了FQ了，下面我來列舉些實例來講明這個問題了。

　　例如公司裏使用代理服務器主要是爲了安全的考慮，不少公司內部都有本身的局域網，通常咱們稱之爲內網，內網裏有公司的各類資源，若是公司員工的電腦隨意鏈接到互聯網，假如碰到那些別有用心的黑客，經過攻擊員工的工做電腦截取了公司重要的文件資料，那樣就會形成公司的重大損失，正向代理除了能防範外部的黑客攻擊外還能監控和控制公司內部員工將公司重要文件經過互聯網傳遞給不恰當的人，所以公司讓員工使用代理上網基本都是出於安全的角度來考慮的。

　　正向代理的合理使用還能幫助一些企業提高本身產品的核心競爭力，例如在移動端有一款很是流行的瀏覽器，它之因此很是受用戶的歡迎，是由於使用該瀏覽器上網速度比其餘瀏覽器明顯的快多了，那麼這款瀏覽器是如何作到這點的呢？奧祕就是這家公司爲本身的瀏覽器對應創建一個十分強大的代理服務器集羣，用戶使用該瀏覽器訪問網站時候用戶首先訪問的是該公司的代理服務器，而這些代理服務器使用緩存技術緩存了海量的網站信息，再加上使用一些web加速的技術例如CDN技術，這就讓該瀏覽器訪問網站的效率明顯快於其餘瀏覽器。

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

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

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

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

　　使用目的四：反向代理能夠緩存靜態數據，通常用做反向代理的服務器都是使用像apache或者是ngnix這樣的靜態資源服務器，所以咱們能夠把web應用裏的靜態資源緩存在反向代理服務器上，從而達到提高請求處理的速度問題。反向代理的這個功能就和本系列的主題網站靜態化處理切合了。

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

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

　

　　咱們看到反向代理服務器和應用服務器之間會造成一個cache層，反向代理訪問cache層的效率會比直接訪問應用服務器要高的多，這等因而給應用服務器作了一個加速操做，同時經過緩存咱們能夠減小應用服務器的運算壓力，從而達到提高應用服務器性能的目的。之前有朋友問我這麼作會不會增長應用服務器的壓力，由於一臺服務器上部署了兩臺能夠處理web請求的服務器，那麼它們之間必定會有發生衝突的時候，不過我想產生衝突確定是咱們沒有很好的處理兩者關係所致，因此咱們要理清在同一臺服務器上部署反向代理和應用服務器後，它們之間的關係究竟是怎樣的？

     其實反向代理和應用服務器從物理形態角度上它們是兩個不一樣的東西，可是兩者在邏輯上實際上是一個總體，它們共同完成一個邏輯性的應用服務器的功能，只不過兩者由於應用場景不一樣而造成了一種分工合做的關係，反向代理服務器主要完成對靜態資源請求的處理，而應用服務器則是負責業務邏輯的處理，它們最終造成一個強大的協力使得總體的邏輯性應用服務器的性能獲得顯著的提高。

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

     方法很簡單就是把反向代理的部署地點從應用服務器所在的物理服務器上遷移出來，放到一臺獨立的物理服務器上，可是這個作法會有性能上的損失，同時還會增長整個技術架構的複雜性。爲何性能會損失呢？由於原來的反向代理服務器和應用服務器部署在同一個物理服務器上，那麼它們之間的通信都是之內存共享的方式進行的，這樣的通信效率是很是高，如今換成了經過網絡通信進行溝通，而網絡通信是IO設備裏效率最差，可靠性最差的，所以單獨部署反向代理服務器或多或少都會形成必定性能的損失。

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

     我如此批評單獨部署反向代理的問題，可是我並非說這種作法徹底不可取，而是想告訴你們這種作法實際上是一種高級的作法，可是也是一個複雜的作法，要作好這個集羣是很麻煩的一件事情的，我以爲只有當咱們的網站業務量和請求量很大的時候，同時原有方案出現了瓶頸時候能夠認真考慮反向代理集羣方案的實現，不過將反向代理造成集羣會給網站的安全性帶來莫大的好處，反向代理能夠隱藏後臺的應用服務器，這種隱藏就是客戶端只須要訪問代理服務器便可，應用服務器對外都是以反向代理來展現的，可是若是反向代理和應用服務器一一對應，那麼惡意黑客找準了某臺反向代理服務器後，對這個反向代理服務器進行反覆的攻擊，那麼這個攻擊也就等於攻擊與之對應的應用服務器，這就致使反向代理隱藏真實應用服務器的做用就沒有獲得有效的發揮，而集羣這塊就能夠很好的處理這個問題，不過咱們若是以爲使用集羣代價過高，咱們也有變通的方法，那就是在全部邏輯應用服務器前面再放置一個反向代理服務器，這個反向代理服務器再也不承擔緩存的功能，而只是用來作負載均衡和安全處理，這樣一一對應的策略安全性也能夠獲得保證，不過若是公司技術能力好能夠考慮使用LVS這種軟件化的負載均衡技術方案，假如公司還頗有錢還能夠考慮使用更加高級的硬件負載均衡設備例如F5設備。

     若是咱們網站除了使用網站靜態化技術還使用了先後端分離技術，固然這個先後端分離技術應該是使用nodejs的先後端分離技術，那麼nodejs應該放置在生產部署的什麼位置上了？上篇文章裏我曾列舉了一個nodejs的應用實踐場景，在這個實踐場景裏我曾經提到若是在原有的網站生產架構下引入nodejs會增長一個請求處理環節，而nodejs使用主要是爲了知足先後端分離而非增長網站性能，所以增長的環節可能會讓請求處理的性能降低，所以我最後提出一種變通手法，就是nodejs項目發佈時候編譯源代碼，而後將編譯出的javascript和html文件乾脆推移到瀏覽器端處理，這樣就變相造成了前端MVC框架，這個作法老是有點不三不四的意味，假如咱們真的想把nodejs引入到應用生產的網絡架構裏，咱們不但願無故的增長請求處理環節，那麼最好是讓nodejs服務器替換某個部分。按照這個思路思考，那麼我以爲nodejs在生產的引入最好是和反向代理相關，最簡單的方式就是讓nodejs和反向代理一一對應，這樣就能夠很好的下降引入nodejs帶來的問題，固然複雜點的就是反向代理集羣對應的應用服務器應該是nodejs的應用服務器，而不是用來作業務處理的業務級別的應用服務器。

    無論怎麼說，我認爲在網站靜態化方案裏咱們必定要考慮反向代理的運用，若是靜態化技術方案裏沒有反向代理的身影，那麼這個網站靜態化處理可能很難達到咱們預期的效果。

    好了，今天就寫到這裏，最後祝你們晚安。

 

原文連接：http://www.cnblogs.com/sharpxiajun/p/4309976.html