Node.js中使用反向代理的原因是什么

今天就跟大家聊聊有關Node.js 中使用反向代理的原因是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

成都創(chuàng)新互聯(lián)公司成立與2013年，先為瑪多等服務建站，瑪多等地企業(yè)，進行企業(yè)商務咨詢服務。為瑪多企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務解決您的所有建站問題。

反向代理是什么?

一個反向代理(reverse proxy)基本上就是一種用于接受請求并將它們轉(zhuǎn)發(fā)到某處的另一個 HTTP server 上的特殊 web  server，也會接受響應并轉(zhuǎn)發(fā)回給原始的請求者。

反向代理通常不會精確地發(fā)送原始請求，典型的做法是會在某些方面對請求作出修改。例如，如果反向代理位于 www.example.org:80 并轉(zhuǎn)發(fā)請求到  ex.example.org:8080 的話，大概就是它重寫了原始的 Host header  以匹配目標地址。反向代理也可能通過其他方式修改請求，比如清理一個有缺陷的請求或是在協(xié)議之間作出轉(zhuǎn)換。

一旦反向代理收到一個響應，可能也會對其進行某方面的轉(zhuǎn)換。常用的途徑同樣是修改 Host header 以匹配原始請求。

請求的 body 也能被修改。一種通常的修改是在響應時執(zhí)行 gzip 壓縮。另一種常見改變是當基礎服務只是 HTTP 時啟用 HTTPS 支持。

反向代理也可以將到來的請求分發(fā)給多個后端實例。如果一個服務暴露于 api.example.org，那么一個反向代理可以轉(zhuǎn)發(fā)請求到  api1.internal.example.org、api2.internal.example.org 等處。

有很多種不同的反向代理。兩種更流行的分別是 Nginx 和 HAProxy。這兩種工具都能夠執(zhí)行 gzip 壓縮和增加 HTTPS  支持，它們也能很好地適用于其它領域。Nginx  更流行一些，并且也有諸如從文件系統(tǒng)運行靜態(tài)文件服務器等一些其它有益的能力，所以我們將在本文中使用它作為例子。

現(xiàn)在我們知道 何為 反向代理了，下面來看看 為何 我們要將其用于 Node.js。

為何應該使用一個反向代理?

SSL 終端

SSL 終端是使用反向代理的最主要原因之一。將一個應用的協(xié)議從 http 變?yōu)?https 可不止添加一個 s 字母那么簡單。Node.js 本身 能夠  對 https 執(zhí)行必要的加密和解密，也能被配置為讀取必要的證書文件。

但是，配置一個用于和我們的應用通信的協(xié)議，并管理一個永不過期的 SSL  憑證，并非真的是我們的應用需要關注的事情。檢查一個代碼庫中的證書不只是麻煩，同時也是一種安全風險。在應用啟動時從特定位置獲取證書也有其風險。

有鑒于此，最好在應用之外執(zhí)行 SSL 終端，通常就由一個反向代理來承擔。受惠于像 certbot 這樣的技術(shù)，通過 Nginx  維護證書也像設置一個定時任務一樣簡單。這樣的一個任務可以自動安裝新證書并動態(tài)重配置 Nginx 進程。與重啟每個 Node.js  應用實例相比，這是一個破壞性小得多的過程。

同時，通過允許一個反向代理來執(zhí)行 SSL 終端，這也意味著 只有 被反向代理的作者編寫的代碼可以訪問你的私有 SSL 證書。反之，如果由你的  Node.js 應用處理 SSL，那么你的應用用到的每一個單獨的第三方模塊 -- 即便是潛在的惡意模塊，都能訪問你的私有 SSL 證書了。

gzip 壓縮

gzip 是另一個你應該由應用讓渡到反向代理的特性。gzip 壓縮策略最好在管理級別設置，而不是不得不為每個應用指定和配置。

最好使用某些邏輯來決定對什么采用 gzip。例如，很小的文件，或許比 1kb 還小的，或許就不值得壓縮，因為其 gzip  壓縮版本沒準會變得更大，亦或客戶端對其解壓的 CPU 開銷也更不劃算。同時，當處理二進制數(shù)據(jù)時，取決于其格式可能也無法從壓縮中獲益。有時 gzip  也無法被簡單地啟用或禁用，為了兼容壓縮算法需要檢查接收到的 Accept-Encoding header。

集群化

JavaScript 是一種單線程語言，相應的，Node.js 天然也是一種單線程的服務器平臺(盡管 Node.js v10 中開始出現(xiàn)的實驗性  worker 線程支持致力于改變這一點)。這意味著要從一個 Node.js 應用中獲取盡可能更大的吞吐量需要運行和 CPU 核數(shù)差不多相同的實例數(shù)量。

Node.js 自帶的 cluster 模塊可以實現(xiàn)集群化。收到的 HTTP 請求將會被交給一個 master 進程而后再被分發(fā)給 cluster  workers。

但是，動態(tài)伸縮 cluster workers 會有點費勁。通常也會通過運行一個額外的 Node.js  進程作為分發(fā)主進程來增加吞吐量。但是，跨機器伸縮進程對于 cluster 來說還是有點強人所難了。

基于這些原因，有時使用一個反向代理來分發(fā)正在運行的 Node.js  進程會更好。反向代理能被動態(tài)配置以指向新出現(xiàn)的應用進程。說實在的，一個應用就應該只關注其自身的工作，而不是管理多個拷貝并分發(fā)請求。

企業(yè)路由

當著手于大型 web 應用，特別是被有多個團隊的企業(yè)創(chuàng)建的應用時，使用一個反向代理來決定如何轉(zhuǎn)發(fā)請求是非常有用的。例如，指向  example.org/search/* 的請求可被路由到內(nèi)部搜索應用，而其它指向 example.org/profile/*  的請求可以被分發(fā)到內(nèi)部資料應用上。

這樣的加工處理提供了其它強大的特性，如粘滯會話、藍/綠部署、A/B測試等等。我個人就曾在這樣一個由應用執(zhí)行這些邏輯的代碼庫中工作，這種實現(xiàn)方式讓應用極難維護。

性能收益

Node.js 是高可塑性的。它可以從文件系統(tǒng)架設靜態(tài)資源服務、對 HTTP 響應執(zhí)行 gzip 壓縮、內(nèi)建支持  HTTPS，另有很多其它特性。它甚至有能力通過 cluster 模塊，運行一個應用的多個實例并分發(fā)其自身的請求。

然而，基本上讓一個反向代理來處理這些操作，而不是靠 Node.js 應用去做，才是符合我們利益的。除了以上列出的原因之外，另一個想要在 Node.js  之外做這些操作的原因是由于效率。

SSL 加密和 gzip 壓縮是兩個高計算密集型的操作。專用型反向代理工具，如 Nginx 和 HAProxy，對這些操作術(shù)業(yè)有專攻，執(zhí)行速度要快于  Node.js。用 Nginx 這樣的 web server 從磁盤上讀取靜態(tài)內(nèi)容也比 Node.js 來得快。有時甚至比起用額外的 Node.js  進程來執(zhí)行集群化，用 Nginx 反向代理實現(xiàn)的效率都更高，內(nèi)存和 CPU 的占用都更少。

但是，耳聽為虛。讓我們運行一些基準測試!

以下負載測試是使用 siege (譯注：一個 http/https 回歸測試和基準測試工具)執(zhí)行的。我們用并發(fā)值 10  運行命令(模擬用戶的請求)，并且該命令會迭代運行 2 萬次(總體會有 20 萬次請求)。

為檢驗內(nèi)存使用量我們在基準測試期間運行命令 pmap| grep total 若干次并取 平均值 作為結(jié)果(譯注：Linux 中的 pmap  命令用于查看進程用了多少內(nèi)存)。當使用單個 worker 線程運行 Nginx 時，最終會運行兩個實例，一個是主線程，另一個是 worker  線程;然后將兩個值相加。當運行一個包含 2 個節(jié)點的 Node.js 集群時，將有 3 個進程，一個是主進程，另兩個是 worker 進程。下表中的  approx memory 列是給定測試中每個 Nginx 和 Node.js 進程的總和。

基準測試的結(jié)果

在 node-cluster 基準測試中我們使用了 2 個 worker，這意味著共有 3 個 Node.js 進程在運行：1 個 master 和 2  個 worker。在 nginx-cluster-node 基準測試中我們有 2 個 Node.js 進程在運行。每個 Nginx 測試都有一個單獨的  Nginx 主進程和一個單獨的 Nginx worker 進程?；鶞蕼y試包括從磁盤讀取一個文件，且無論是 Nginx 還是 Node.js  都被配置為將文件緩存在內(nèi)存中。

使用 Nginx 為 Node.js 執(zhí)行 SSL 終端帶來了約 16% (746rps 到 865rps) 的吞吐量增長。使用 Nginx 執(zhí)行  gzip 壓縮則讓吞吐量增加了約 50% (5,047rps 到 7,590rps)。使用 Nginx 管理一個進程集群造成了約 1% (8,006rps 到  7,908rps) 的性能損失，大概是歸因于在回環(huán)網(wǎng)絡設備間傳遞額外請求的開銷吧。

一個基本的 Node.js 單進程單內(nèi)存使用量是約 600MB，而 Nginx 進程的約  50MB。這些使用量會根據(jù)使用了那些特性而小幅波動，例如，Node.js 使用了額外的約 13MB 來執(zhí)行 SSL 終端，以及 Nginx 使用了額外的  4MB(譯注：652 - 601 - 46.1)來作為 Node.js 的反向代理并架設從文件系統(tǒng)讀取靜態(tài)內(nèi)容的服務?？梢宰⒁獾揭粋€有趣的事情是 Nginx  在其生命周期中保持了穩(wěn)定的內(nèi)存吞吐量;然而 Node.js 的內(nèi)存吞吐量由于 JavaScript 天然的垃圾回收機制而時常起伏。

以下是執(zhí)行此次基準測試的軟件版本：

• Nginx: 1.14.2

• Node.js: 10.15.3

• Siege: 3.0.8

測試執(zhí)行在一臺有 16GB 內(nèi)存的機器上，有一塊 i7-7500U CPU 4x2.70GHz，Linux 內(nèi)核為  4.19.10。項目地址位于：github.com/IntrinsicLa… 。

簡化應用代碼

基準測試全面又出彩，但從我的觀點來說，將部分工作從 Node.js 應用讓渡給反向代理帶來的最大收益是代碼的簡化。我們得以減少了大量可能造成潛在 bug  的必須應用代碼并將其換成了聲明式的配置。開發(fā)者中的一個普遍觀點是他們對于讓 Nginx 等外部團隊編寫這部分代碼，而不是由他們自己編寫更有信心。

不同于要安裝和管理 gzip 壓縮中間件并在多個 Node.js 項目中保持其最新，我們可以在一處統(tǒng)一配置它。和加載 SSL  證書后再重啟應用進程不同，我們可以使用已有的證書管理工具。與其在應用中添加條件語句檢查進程是 master 還是  worker，不如將其交給其它工具判斷。

反向代理允許我們的應用聚焦于業(yè)務邏輯并忽略協(xié)議和進程管理。

盡管 Node.js 擁有運行在生產(chǎn)環(huán)境的完美能力，但將反向代理和生產(chǎn)環(huán)境的 HTTP Node.js 應用結(jié)合使用帶來了種種收益。像 SSL 和  gzip 這樣的操作變得更快。管理 SSL 證書也會更簡單。大量所需應用代碼也被減少了。

看完上述內(nèi)容，你們對Node.js 中使用反向代理的原因是什么有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

分享標題：Node.js中使用反向代理的原因是什么
分享路徑：http://muchs.cn/article40/ppjieo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、Google、自適應網(wǎng)站、營銷型網(wǎng)站建設、動態(tài)網(wǎng)站、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)