miért kell használni a fordított Proxy Ha csomópont.a JS készen áll a gyártásra?

az év 2012 volt. PHP és Ruby on Rails uralkodott, mint a Legfelsőbb szerver oldali technológiák renderelés webes alkalmazások. De, egy merész új versenyző viharral vette át a közösséget — amelynek sikerült kezelnie az 1M egyidejű kapcsolatokat. Ez a technológia nem más, mint a Node.js és folyamatosan nőtt a népszerűsége azóta.

ellentétben a legtöbb versengő technológiák az idő, csomópont.a js beépített webszerverrel érkezett. A szerver megléte azt jelentette, hogy a fejlesztők számtalan konfigurációs fájlt megkerülhettek, például a php.ini és a
.htaccess fájlok hierarchikus gyűjteményét. A beépített webkiszolgáló más kényelmet is biztosított, mint például a fájlok feltöltése közben történő feldolgozásának képessége, valamint a Websocketek egyszerű megvalósítása.

minden nap csomópont.a js-alapú webes alkalmazások boldogan kezelik a kérelmek milliárdjait. A világ legnagyobb vállalatainak többségét valamilyen módon csomópont hajtja.js. Azt mondani, hogy csomópont.js a termelés-kész minden bizonnyal egy
kifejezés. Van azonban egy tanács,amely a Node óta igaz.js kezdete: nem szabad közvetlenül kitenni egy csomópontot.a JS feldolgozza az internetet, ehelyett el kell rejtenie egy fordított proxy mögött. De mielőtt megnéznénk az okokat, miért szeretnénk fordított proxyt használni, először nézzük meg, mi az.

a fordított proxy alapvetően egy speciális típusú webszerver, amely fogadja a kéréseket, továbbítja azokat egy másik HTTP szerverre valahol máshol, megkapja a választ, és továbbítja a választ az eredeti kérőnek.

a fordított proxy általában nem küldi el a pontos kérést. Általában valamilyen módon módosítja a kérést. Például, ha a fordított proxy a www.example.org:80 címen él, és továbbítja a kérést a
ex.example.org:8080 címre, akkor valószínűleg átírja az eredeti Host fejlécet, hogy megfeleljen a cél fejlécének. A kérést más módon is módosíthatja, például egy hibás kérés megtisztítása vagy a protokollok közötti fordítás.

Ha a fordított proxy választ kap, akkor ezt a választ valamilyen módon lefordíthatja. Ismét általános megközelítés a Host fejléc módosítása, hogy megfeleljen az eredeti kérésnek. A kérések törzsét is meg lehet változtatni. Gyakori módosítás a gzip tömörítés végrehajtása a válaszon. Egy másik gyakori változás a HTTPS támogatás engedélyezése, Ha az alapul szolgáló szolgáltatás csak HTTP-t beszél.

a fordított proxyk bejövő kéréseket is küldhetnek több háttérpéldányra. Ha egy szolgáltatás ki van téve a api.example.org, a fordított proxy továbbíthatja a kéréseket a api1.internal.example.orgapi2 stb.

sok különböző fordított proxy van odakint. A két legnépszerűbb az Nginx és a HAProxy. Mindkét eszköz képes elvégezni a gzip tömörítést és HTTPS támogatást adni, és más területekre is specializálódtak. Nginx a legnépszerűbb a két választás, és van néhány más
hasznos képességek, mint például a képesség, hogy szolgálja a statikus fájlokat egy fájlrendszer, így fogjuk használni, mint egy példa az egész ezt a cikket.

most, hogy tudjuk, mi az a fordított proxy, most megvizsgálhatjuk, miért szeretnénk használni egyet csomóponttal.js.

miért használjak fordított proxyt?

az SSL megszüntetése az egyik legnépszerűbb ok, amiért fordított proxyt használunk. A ones alkalmazás protokolljának megváltoztatása http – ről https kicsit több munkát igényel, mint egy shozzáfűzése. Csomópont.maga a js képes végrehajtani a szükséges titkosítást és dekódolást a https számára, és konfigurálható a szükséges tanúsítványfájlok olvasására.

az alkalmazásunkkal való kommunikációhoz használt protokoll konfigurálása és az állandóan lejáró SSL tanúsítványok kezelése azonban nem igazán olyan dolog, amit az alkalmazásunknak aggódnia kell. A tanúsítványok kódbázisba történő ellenőrzése nemcsak unalmas, hanem biztonsági kockázatot is jelent. A tanúsítványok központi helyről történő megszerzése az alkalmazás indításakor szintén kockázattal jár.

ezért jobb, ha az SSL-felmondást az alkalmazáson kívül végezzük, általában fordított proxyn belül. Az olyan technológiáknak köszönhetően, mint a certbot A Let ‘ s Encrypt, a tanúsítványok fenntartása az Nginx-szel ugyanolyan egyszerű, mint egy cron feladat beállítása. Egy ilyen feladat automatikusan új tanúsítványokat telepít és dinamikusan újrakonfigurálja az Nginx folyamatot. Ez sokkal kevésbé zavaró folyamat, mint mondjuk az egyes csomópontok újraindítása.js alkalmazás példány.

azáltal, hogy engedélyezi a fordított proxy SSL-megszüntetését, ez azt jelenti, hogy csak a fordított proxy szerzői által írt kód fér hozzá a privát SSL-tanúsítványhoz. Azonban, ha a csomópont.a js alkalmazás kezeli az SSL-t, akkor az alkalmazás által használt minden harmadik fél modulja — akár potenciálisan rosszindulatú modulok is — hozzáférhet a privát SSL-tanúsítványhoz.

gzip tömörítés

a gzip tömörítés egy másik funkció, amelyet ki kell töltenie az alkalmazásból egy fordított proxyba. a gzip tömörítési házirendeket a legjobban szervezeti szinten lehet beállítani, ahelyett, hogy minden alkalmazáshoz meg kellene adni és konfigurálni.

a legjobb, ha valamilyen logikát használunk, amikor eldöntjük, hogy mit kell gzipelni. Például a nagyon kicsi, talán 1 KB-nál kisebb fájlokat valószínűleg nem érdemes tömöríteni, mivel a gzip tömörített verziója néha nagyobb lehet, vagy a CPU-költség, ha az ügyfél kibontja a fájlt, nem éri meg. Továbbá, ha bináris adatokkal foglalkozik, a formátumtól függően előfordulhat, hogy nem részesül a tömörítésből. a gzip olyan is, amelyet nem lehet egyszerűen engedélyezni vagy letiltani, meg kell vizsgálnia a bejövő Accept-Encoding fejlécet a kompatibilis tömörítési algoritmusokhoz.

fürtözés

a JavaScript egyszálú nyelv, ennek megfelelően csomópont.a js hagyományosan egyszálú kiszolgálóplatform volt (bár a jelenleg kísérleti worker thread támogatás elérhető a Node-ban.a js v10 célja ennek megváltoztatása). Ez azt jelenti, hogy egy csomópontból annyi áteresztőképességet kapunk.a JS alkalmazás a lehető legtöbb esetben nagyjából ugyanannyi példányt igényel, mint a CPU magok.

csomópont.a js beépített cluster modullal rendelkezik, amely éppen erre képes. A bejövő HTTP kéréseket egy fő folyamathoz kell benyújtani, majd elküldik a klaszter dolgozóinak.

a klasztermunkások dinamikus méretezése azonban némi erőfeszítést igényel. Van is általában hozzáadott fölött fut egy további csomópont.js folyamat, mint a diszpécser master folyamat. Ezenkívül a különböző gépek közötti skálázási folyamatok olyan dolgok, amelyeket a cluster nem tud megtenni.

Ezen okok miatt néha jobb, ha fordított proxyt használunk a kérések elküldésére a futó csomópontra.js folyamatok. Az ilyen fordított proxyk dinamikusan konfigurálhatók úgy, hogy érkezéskor új alkalmazási folyamatokra mutassanak. Valójában egy alkalmazásnak csak a saját munkájával kell foglalkoznia, nem szabad több másolat kezelésével és a kérelmek elküldésével foglalkoznia.

Enterprise Routing

amikor hatalmas webes alkalmazásokkal foglalkozik, például a többcsapatos vállalkozások által épített alkalmazásokkal, nagyon hasznos, ha fordított proxy van annak meghatározására, hogy hova továbbítsa a kéréseket. Például a example.org/search/* – hez intézett kérések átirányíthatók a belső kereső alkalmazásba, míg a example.org/profile/* – hez intézett egyéb kérések elküldhetők a belső profil alkalmazásba.

Az ilyen szerszámok más erőteljes funkciókat is lehetővé tesznek, mint például a ragadós munkamenetek, a kék/zöld telepítések, az A/B tesztelés stb. Személyesen dolgoztam egy kódbázisban, ahol ilyen logikát hajtottak végre az alkalmazáson belül, és ez a megközelítés meglehetősen megnehezítette az alkalmazás karbantartását.

teljesítmény előnyei

csomópont.js nagyon alakítható. Képes statikus eszközöket kiszolgálni egy fájlrendszerből, gzip tömörítést végrehajtani HTTP válaszokkal, beépített HTTPS támogatással és sok más funkcióval rendelkezik. Még arra is képes, hogy egy alkalmazás több példányát futtassa, és saját kérésküldést hajtson végre a cluster modul segítségével.

és mégis, végső soron az a legjobb érdekünk, hogy hagyjuk, hogy egy fordított proxy kezelje ezeket a műveleteket helyettünk, ahelyett, hogy a Csomópontunk lenne.js alkalmazás csinálni. A fent felsorolt okok mindegyikén kívül egy másik oka annak, hogy ezeket a műveleteket a csomóponton kívül szeretné elvégezni.a JS a hatékonyságnak köszönhető.

az SSL titkosítás és a gzip tömörítés két erősen CPU-kötésű művelet. A dedikált fordított proxy eszközök, mint például az Nginx és a HAProxy, általában gyorsabban hajtják végre ezeket a műveleteket, mint a Node.js. Ha egy olyan webszerver, mint az Nginx, statikus tartalmat olvas a lemezről, az gyorsabb lesz, mint a Node.js is. Még a klaszterezés is néha hatékonyabb lehet, mivel egy fordított proxy, mint az Nginx, kevesebb memóriát és CPU-t használ, mint egy további Csomóponté.js folyamat.

de ne vegye figyelembe a szavunkat. Futtassunk néhány referenciaértéket!

a következő terhelésvizsgálatot a siegehasználatával végeztük. A parancsot 10-es egyidejűségi értékkel futtattuk (10 egyidejű felhasználó kér), és a parancs 20 000 iterációig futott (200 000 teljes kérés esetén).

a memória ellenőrzéséhez a pmap <pid> | grep total parancsot futtatjuk néhányszor a benchmark élettartama alatt, majd átlagoljuk az eredményeket. Ha az Nginx-et egyetlen munkásszállal futtatja, akkor két példány fut, az egyik a mester, a másik pedig a munkás. Ezután összegezzük a két értéket. Csomópont futtatásakor.js klaszter 2 3 folyamat lesz, az egyik a mester, a másik kettő pedig munkás. A következő táblázat KB memória oszlopa az egyes Nginxek és csomópontok teljes összege.js folyamat az adott teszthez.

itt vannak a benchmark eredményei:

a node-cluster Benchmark-ban 2 munkavállalót használunk. Ez azt jelenti, hogy 3 csomópont van.js folyamatok futnak: 1 mester és 2 munkás. Anginx-cluster-node benchmarkban 2 csomópont van.js folyamatok futnak. Minden nginx tesztnek egyetlen nginx master és egyetlen nginx worker folyamata van. A referenciaértékek magukban foglalják a fájl lemezről történő olvasását, sem Nginxet, sem csomópontot.a js-t úgy konfigurálták, hogy gyorsítótárazza a fájlt a memóriában.

az NGINX használata a csomópont SSL-megszüntetésének végrehajtásához.a js az átviteli sebesség ~16% – os növekedését eredményezi (749rps-865rps). Az Nginx használata a gzip tömörítés végrehajtásához ~50% – os (5047 rps-7590 rps) átviteli sebességet eredményez. Az Nginx használata a folyamatok klaszterének kezelésére ~-1% – os teljesítménybüntetést eredményezett (8006 rps-7908 rps), valószínűleg annak köszönhető, hogy egy további kérést továbbítottak a visszacsatolási hálózati eszközön.

lényegében egyetlen csomópont memóriahasználata.a js folyamat ~600 MB, míg az Nginx folyamat memóriahasználata ~50 MB körül van. Ezek kissé ingadozhatnak attól függően, hogy milyen funkciókat használnak, például a csomópontot.a js további ~13 MB-ot használ az SSL-felmondás végrehajtásakor, az Nginx pedig további ~4 MB-ot használ, ha fordított proxy versként használják, amely statikus tartalmat szolgál a fájlrendszerből. Érdekes dolog megjegyezni, hogy az Nginx egész életében állandó mennyiségű memóriát használ. Azonban Csomópont.a JS folyamatosan ingadozik a JavaScript szemétgyűjtő jellege miatt.

itt találhatók a benchmark végrehajtása során használt szoftver verziói:

• Nginx: 1.14.2
• csomópont.js: 10.15.3
• ostrom: 3.0.8

a teszteket 16 GB memóriával rendelkező gépen, i7-7500U CPU 4x2.70GHz és Linux kernel 4.19.10. A fenti referenciaértékek újbóli létrehozásához szükséges összes fájl itt érhető el:
IntrinsicLabs/nodejs-reverse-proxy-benchmarks.

egyszerűsített Alkalmazási kód

a referenciaértékek szépek, de véleményem szerint a legnagyobb előnye a munka kirakodásának egy csomópontról.js alkalmazás fordított proxy, hogy a kód egyszerűség. Csökkentjük a potenciálisan hibás imperatív alkalmazáskód sorainak számát, és kicseréljük deklaratív konfigurációra. A fejlesztők körében gyakori érzés, hogy magabiztosabbak a külső mérnökök — például az Nginx — által írt kódokban, mint a saját maguk által írt kódokban.

ahelyett, hogy telepítené és kezelné a gzip tömörítő köztes szoftvert, és naprakészen tartaná a különböző csomópontokon.js projektek ehelyett egyetlen helyen konfigurálhatjuk. Az SSL tanúsítványok szállítása vagy letöltése, illetve azok újbóli megszerzése vagy az alkalmazásfolyamatok újraindítása helyett a meglévő Tanúsítványkezelő eszközöket használhatjuk. Ahelyett, hogy Feltételeket adna az alkalmazásunkhoz annak ellenőrzésére, hogy egy folyamat mester vagy munkás-e, ezt egy másik eszközre tölthetjük le.

a fordított proxy lehetővé teszi alkalmazásunk számára, hogy az üzleti logikára összpontosítson, és elfelejtse a protokollokat és a folyamatkezelést.