miksi minun pitäisi käyttää käänteistä välityspalvelinta, jos solmu.onko tuotanto valmis?

Thomas Hunter II

follow

div>

maalis 28, 2019 · 9 min read

vuosi oli 2012. PHP ja Ruby On Rails hallitsivat ylivertaisia palvelinpuolen teknologioita web-sovellusten renderöintiin. Mutta, rohkea uusi haastaja vei yhteisön myrskyn-yksi, joka onnistui käsittelemään 1m samanaikaisia yhteyksiä. Tämä teknologia ei ollut mikään muu kuin solmu.js ja on tasaisesti kasvattanut suosiotaan siitä lähtien.

toisin kuin useimmat aikansa kilpailevat teknologiat, Node.js tuli web-palvelin sisäänrakennettu. Tämän palvelimen ansiosta kehittäjät pystyivät ohittamaan lukemattomia asetustiedostoja kuten php.ini ja hierarkkisen kokoelman
.htaccess tiedostoja. Ottaa sisäänrakennettu web-palvelin tarjosi myös muita mukavuuksia, kuten kyky käsitellä tiedostoja, koska ne olivat Ladataan ja helppous toteuttaa WebSockets.

joka päivä solmu.js-käyttöiset verkkosovellukset käsittelevät mielellään miljardeja pyyntöjä. Suurin osa maailman suurimmista yrityksistä toimii jollain tavalla solmulla.js. Sanoa, että solmu.js on tuotantovalmis on varmasti
vähättelyä. On kuitenkin yksi neuvo, joka on pitänyt paikkansa solmun jälkeen.js: n aloitus: solmua ei saa suoraan paljastaajs prosessi web ja pitäisi sen sijaan piilottaa sen taakse käänteinen välityspalvelin. Mutta ennen kuin tarkastelemme syitä, miksi haluaisimme käyttää käänteistä valtakirjaa, Katsotaanpa ensin, mitä yksi on.

käänteinen välityspalvelin on pohjimmiltaan tietyntyyppinen WWW-palvelin, joka vastaanottaa pyyntöjä, välittää ne toiselle HTTP-palvelimelle jonnekin muualle, saa vastauksen ja välittää vastauksen alkuperäiseen pyynnön esittäjään.

käänteinen välityspalvelin ei kuitenkaan yleensä lähetä tarkkaa pyyntöä. Tyypillisesti se muuttaa pyyntöä jollakin tavalla. Esimerkiksi jos käänteinen välityspalvelin elää osoitteessa www.example.org:80 ja aikoo välittää pyynnön eteenpäin osoitteeseen
ex.example.org:8080, se todennäköisesti kirjoittaa alkuperäisen Host otsikon vastaamaan kohteen vastaavuutta. Se voi myös muuttaa pyyntöä muilla tavoin, kuten puhdistamalla epämuodostuneen pyynnön tai kääntämällä protokollien välillä.

kun käänteinen proxy saa vastauksen, se voi sitten kääntää vastauksen jollakin tavalla. Jälleen yleinen lähestymistapa on muokata Host otsikkoa vastaamaan alkuperäistä pyyntöä. Pyyntöjen runkoa voi myös muuttaa. Yleinen muutos on suorittaa gzip-Pakkaus vasteeseen. Toinen yleinen muutos on ottaa HTTPS-tuki käyttöön, kun taustalla oleva palvelu puhuu vain HTTP: ää.

Reverse-välityspalvelimet voivat myös lähettää saapuvia pyyntöjä useille taustaosastoille. Jos palvelu altistuu arvolla api.example.org, käänteinen välityspalvelin voi välittää pyynnöt osoitteeseen api1.internal.example.orgapi2 jne.

on olemassa monia erilaisia reverse proxies siellä. Kaksi suositumpaa ovat Nginx ja HAProxy. Molemmat näistä työkaluista pystyvät suorittamaan GZIP-puristuksen ja lisäämään HTTPS-tuen, ja ne ovat erikoistuneet myös muille alueille. Nginx on suositumpi kahdesta vaihtoehdosta, ja sillä on myös joitakin muita
hyödyllisiä ominaisuuksia, kuten kyky palvella staattisia tiedostoja tiedostojärjestelmästä, joten käytämme sitä esimerkkinä koko tässä artikkelissa.

nyt kun tiedämme, mikä on käänteinen proxy, voimme nyt tutkia, miksi haluaisimme käyttää sellaista solmua.js.

miksi minun pitäisi käyttää käänteistä välityspalvelinta?

SSL-päättyminen on yksi suosituimmista syistä käyttää käänteistä välityspalvelinta. Ones-sovelluksen protokollan muuttaminen httphttps vaatii hieman enemmän työtä kuin s. Solmu.js pystyy itse suorittamaan tarvittavan salauksen ja salauksen https, ja se voidaan konfiguroida lukemaan tarvittavat varmennetiedostot.

kuitenkin sovelluksemme kanssa kommunikointiin käytettävän protokollan määrittäminen ja alati vanhentuvien SSL-varmenteiden hallinta ei ole oikeastaan jotain, josta sovelluksemme tarvitsee olla huolissaan. Varmenteiden tarkistaminen koodibaasiin olisi paitsi työlästä, myös turvallisuusriski. Varmenteiden hankkimisessa keskitetystä paikasta sovelluksen käynnistyessä on myös riskinsä.

tästä syystä on parempi suorittaa SSL-päättäminen sovelluksen ulkopuolella, yleensä käänteisen välityspalvelimen sisällä. Let ’ s Encryptin kaltaisten teknologioiden, kuten certbot, ansiosta varmenteiden ylläpitäminen Nginx: llä on yhtä helppoa kuin cron-työn perustaminen. Tällainen työ voi asentaa automaattisesti uusia varmenteita ja dynaamisesti määrittää uudelleen nginx-prosessin. Tämä on paljon vähemmän häiritsevä prosessi sitten, sanoa, käynnistää uudelleen jokaisen solmun.js application instance.

myös sallimalla käänteisen välityspalvelimen suorittaa SSL-päättämisen tämä tarkoittaa sitä, että vain käänteisen välityspalvelimen laatijoiden kirjoittamalla koodilla on pääsy yksityiseen SSL-varmenteeseesi. Kuitenkin, jos solmu.js-sovellus käsittelee SSL: ää, sitten jokaisella sovelluksen käyttämällä kolmannen osapuolen moduulilla — jopa mahdollisesti haitallisilla moduuleilla — on pääsy yksityiseen SSL-varmenteeseesi.

gzip-Pakkaus

gzip-pakkaus on toinen ominaisuus, joka sinun pitäisi purkaa sovelluksesta käänteiseen välityspalvelimeen. gzip-pakkauskäytännöt ovat jotain, joka on parasta asettaa organisaatiotasolla sen sijaan, että kunkin sovelluksen pitäisi määrittää ja määrittää.

on parasta käyttää jonkinlaista logiikkaa päätettäessä, mitä gzip. Esimerkiksi tiedostot, jotka ovat hyvin pieniä, ehkä pienempiä kuin 1KB, eivät luultavasti kannata pakata, koska gzip-pakattu versio voi joskus olla suurempi, tai CPU yläpuolella ottaa asiakkaan purkaa tiedosto ei ehkä ole sen arvoista. Myös binääridataa käsiteltäessä formaatista riippuen se ei välttämättä hyödy pakkauksesta. gzip on myös jotain, jota ei voi yksinkertaisesti ottaa käyttöön tai poistaa käytöstä, se vaatii tulevan Accept-Encoding – otsikon tutkimista yhteensopiville pakkausalgoritmeille.

ryhmittely

JavaScript on yksikierteinen kieli ja siten solmu.js on perinteisesti ollut yksikierteinen palvelinalusta (tosin nykyisin kokeellinen worker thread-tuki, joka on saatavilla solmussa.js v10 pyrkii muuttamaan tätä). Tämä tarkoittaa saada niin paljon läpimenoa solmu.JS application as possible vaatii käynnissä suurin piirtein saman määrän instansseja kuin on CPU-ytimiä.

solmu.js: ssä on sisäänrakennettu cluster moduuli, joka pystyy juuri siihen. Saapuvat HTTP-pyynnöt tehdään master-prosessiin ja lähetetään klusterityöntekijöille.

dynaamisesti skaalautuva klusterityöntekijä vaatisi kuitenkin jonkin verran vaivaa. On myös yleensä lisätty yläpuolella käynnissä ylimääräinen solmu.js prosessi lähetys master prosessi. Myös prosessien skaalaaminen eri koneisiin on jotain, mitä cluster ei voi tehdä.

näistä syistä on joskus parempi käyttää käänteistä välityspalvelinta pyyntöjen lähettämiseen käynnissä olevaan solmuun.js prosessit. Tällaiset käänteiset välityspalvelimet voidaan dynaamisesti konfiguroida osoittamaan uusia sovellusprosesseja niiden saapuessa. Todella, sovelluksen pitäisi vain olla huolissaan oman työnsä tekemisestä, sen ei pitäisi olla huolissaan useiden kopioiden hallinnasta ja pyyntöjen lähettämisestä.

yritysten reititys

kun käsitellään massiivisia verkkosovelluksia, kuten monen tiimin yritysten rakentamia, on erittäin hyödyllistä käyttää käänteistä välityspalvelinta sen määrittämiseksi, minne pyynnöt lähetetään. Esimerkiksi example.org/search/* tehdyt pyynnöt voidaan reitittää sisäiseen hakusovellukseen, kun taas muut example.org/profile/* tehdyt pyynnöt voidaan lähettää sisäiseen profiilisovellukseen.

tällainen työkalut mahdollistaa muita tehokkaita ominaisuuksia, kuten sticky sessions, Blue/Green deployments, A / B testaus, jne. Olen itse työskennellyt codebase, jossa tällainen logiikka suoritettiin sovelluksen sisällä ja tämä lähestymistapa teki sovelluksen melko vaikea ylläpitää.

Suoritushyödyt

solmu.js on erittäin muokattava. Se pystyy palvelemaan staattisia resursseja tiedostojärjestelmästä, suorittamaan GZIP-pakkausta HTTP-vastauksilla, siinä on sisäänrakennettu tuki HTTPS: lle ja monia muita ominaisuuksia. Sillä on jopa kyky ajaa useita sovelluksen instansseja ja suorittaa oma pyyntönsä lähettäminen cluster – moduulin avulla.

ja silti on lopulta meidän etumme mukaista antaa käänteisen välityspalvelimen hoitaa nämä operaatiot puolestamme sen sijaan, että meillä olisi Solmumme.JS sovellus tee se. Muut kuin jokainen edellä luetelluista syistä, toinen syy, miksi nämä toiminnot halutaan tehdä solmun ulkopuolella.js johtuu tehokkuudesta.

SSL-salaus ja gzip-Pakkaus ovat kaksi erittäin suorittimeen sidottua operaatiota. Dedicated reverse proxy työkalut, kuten Nginx ja HAProxy, tyypillisesti suorittaa nämä toiminnot nopeammin kuin solmu.js. Ottaa web-palvelin, kuten nginx lukea staattista sisältöä levyltä tulee olemaan nopeampi kuin solmu.samoin js. Jopa klusterointi voi joskus olla tehokkaampaa, koska Nginxin kaltainen käänteinen välityspalvelin käyttää vähemmän muistia ja suoritinta kuin lisäsolmu.JS-prosessi.

mutta, älä usko meidän sanaamme. Otetaan vertailukohtia!

seuraavat kuormitustestit suoritettiin käyttäen siege. Suoritimme komennon, jonka yhteisarvo oli 10 (10 samanaikaista käyttäjää tekee pyynnön) ja komento kestäisi, kunnes tehtiin 20 000 iteraatiota (200 000 kokonaispyynnöstä).

muistin tarkistamiseksi suoritamme komennon pmap <pid> | grep total muutaman kerran koko vertailuarvon käyttöiän ajan ja sitten keskiarvotamme tulokset. Kun ajetaan Nginxiä yhdellä työntekijälangalla, päädytään kahteen instanssiin, joista toinen on päällikkö ja toinen työntekijä. Sitten summaamme nämä kaksi arvoa. Kun ajetaan solmua.JS klusterin 2 Siellä on 3 prosesseja, joista yksi on master ja kaksi muuta ovat työntekijöitä. Seuraavassa taulukossa oleva nginx-muistisarake on kunkin Nginxin ja solmun yhteenlaskettu summa.JS-prosessi annettua testiä varten.

tässä ovat vertailuarvon tulokset:

figcaption>benchmark results

node-clusterbenchmark käytämme 2 työntekijää. Tämä tarkoittaa, että on olemassa 3 solmua.js prosessit käynnissä: 1 master ja 2 työntekijää. nginx-cluster-node benchmark meillä on 2 solmua.JS prosessit käynnissä. Jokaisella nginx-testillä on yksi nginx-mestari ja yksi nginx-työprosessi. Vertailuarvoihin kuuluu tiedoston lukeminen levyltä, eikä Nginx eikä Node.js oli määritetty välimuistiin tiedoston muistiin.

Nginxin käyttäminen SSL-päättämisen suorittamiseen solmulle.js johtaa läpimenon kasvuun ~16% (749rps 865rps). Nginxin käyttäminen gzip-puristuksen suorittamiseen johtaa läpimenon kasvuun ~50% (5,047 rps-7,590 rps). Käyttämällä nginx hallita klusterin prosesseja johti suorituskykyä rangaistus ~-1% (8,006 rps 7,908 rps), luultavasti koska yläpuolella kulkee ylimääräinen pyyntö yli loopback verkkolaite.

oleellisesti yhden solmun muistinkäyttö.js-prosessi on ~600MB, kun taas nginx-prosessin muistin käyttö on noin ~50MB. Nämä voivat vaihdella hieman riippuen siitä, mitä ominaisuuksia käytetään, esimerkiksi solmu.js käyttää ylimääräistä ~13MB SSL-irtisanomista suorittaessaan, ja Nginx käyttää ylimääräistä ~4MB: tä, kun sitä käytetään käänteisenä välityspalvelimen jakeena, joka palvelee staattista sisältöä tiedostojärjestelmästä. Mielenkiintoista on huomata, että Nginx käyttää johdonmukaista määrää muistia koko elinaikansa. Kuitenkin Solmu.js vaihtelee jatkuvasti JavaScriptin roskankeräysluonteen vuoksi.

tässä on tämän vertailukohdan suorittamisessa käytettyjen ohjelmistojen versiot:

• Nginx: 1.14.2
• solmu.js: 10.15.3
• Siege: 3.0.8

testit suoritettiin koneella, jossa oli 16 Gt muistia, i7-7500U CPU 4x2.70GHz ja Linux-ydin 4.19.10. Kaikki edellä mainittujen vertailuarvojen uudelleenluomiseen tarvittavat tiedostot löytyvät täältä:
IntrinsicLabs / nodejs-reverse-proxy-benchmarks.

yksinkertaistettu sovelluskoodi

vertailuarvot ovat mukavia ja kaikki, mutta mielestäni suurimmat hyödyt purkutyöstä solmulta.JS sovellus käänteinen välityspalvelin on, että koodi yksinkertaisuus. Saamme vähentää rivien mahdollisesti buginen imperatiivinen sovellus koodi ja vaihtaa sen deklaratiivinen kokoonpano. Yleinen mielipide kehittäjien keskuudessa on, että he ovat luottavaisempia ulkoisen insinööriryhmän — kuten Nginxin-kirjoittamiin koodeihin kuin itse kirjoittamiin koodeihin.

sen sijaan, että asennettaisiin ja hallinnoitaisiin gzip-pakkausväliohjelmistoa ja pidettäisiin se ajan tasalla eri solmujen välillä.JS projektit voimme sen sijaan määrittää sen yhteen paikkaan. Sen sijaan, että lähetämme tai lataamme SSL-varmenteita ja joko hankimme ne uudelleen tai käynnistämme sovellusprosessit uudelleen, voimme sen sijaan käyttää olemassa olevia varmenteiden hallintatyökaluja. Sen sijaan, että lisäämme ehtoja hakemukseemme tarkistaaksemme, onko prosessi mestari tai työntekijä, voimme purkaa tämän toiseen työkaluun.

käänteisen välityspalvelimen avulla sovelluksemme voi keskittyä liiketoiminnan logiikkaan ja unohtaa protokollat ja prosessinhallinnan.