dlaczego powinienem używać odwrotnego proxy, jeśli Node.js czy produkcja jest gotowa?

Thomas Hunter II

Postępuj zgodnie z

28 marca 2019 r. · 9 min. czytaj

był Rok 2012. PHP i Ruby on Rails królowały jako najlepsze technologie po stronie serwera do renderowania aplikacji internetowych. Ale śmiały nowy rywal wziął społeczność przez burzę — jeden, który zdołał obsłużyć 1m jednoczesnych połączeń. Ta technologia była niczym innym jak węzłem.js i od tego czasu stale rośnie popularność.

w przeciwieństwie do większości konkurencyjnych technologii tamtych czasów, Node.js przyszedł z wbudowanym serwerem WWW. Posiadanie tego serwera oznaczało, że programiści mogli ominąć niezliczoną ilość plików konfiguracyjnych ,takich jakphp.ini I hierarchiczny zbiór
.htaccess. Posiadanie wbudowanego serwera www zapewniało również inne udogodnienia, takie jak możliwość przetwarzania plików podczas ich przesyłania i łatwość wdrażania Websocketów.

każdego dnia.aplikacje internetowe oparte na js z radością obsługują miliardy żądań. Większość największych firm na świecie jest zasilana w jakiś sposób przez węzeł.js. Powiedzieć, że węzeł.JS jest gotowy do produkcji to na pewno
niedopowiedzenie. Jest jednak jedna rada, która jest prawdziwa od czasu Node.Incepcja js: nie należy bezpośrednio narażać węzła.js przetwarza do sieci i powinien zamiast tego ukryć go za odwrotnym proxy. Zanim jednak przyjrzymy się powodom, dla których chcielibyśmy użyć odwrotnego proxy, przyjrzyjmy się najpierw, czym jest.

odwrotne proxy to w zasadzie specjalny typ serwera WWW, który odbiera żądania, przekazuje je do innego serwera HTTP gdzie indziej, otrzymuje odpowiedź i przekazuje odpowiedź do pierwotnego żądania.

odwrotne proxy zwykle nie wysyłają dokładnego żądania. Zazwyczaj modyfikuje to żądanie w jakiś sposób. Na przykład, jeśli odwrotne proxy znajduje się w www.example.org:80 I przekaże żądanie do
ex.example.org:8080, prawdopodobnie przepisze oryginalny nagłówek Host, aby pasował do nagłówka celu. Może również modyfikować żądanie w inny sposób, np. usuwając zniekształcone żądanie lub tłumacząc między protokołami.

gdy odwrotne proxy otrzymają odpowiedź, może ona przetłumaczyć tę odpowiedź w jakiś sposób. Ponownie, powszechnym podejściem jest zmodyfikowanie nagłówkaHost, aby pasował do pierwotnego żądania. Treść wniosków może również zostać zmieniona. Powszechną modyfikacją jest wykonywanie kompresji gzip na odpowiedzi. Inną częstą zmianą jest włączenie obsługi HTTPS, gdy usługa bazowa mówi tylko HTTP.

odwrotne Serwery Proxy mogą również wysyłać przychodzące żądania do wielu instancji zaplecza. Jeśli usługa jest wystawiona na api.example.org, odwrotne proxy mogą przekazywać żądania do api1.internal.example.orgapi2 itd.

istnieje wiele różnych odwrotnych serwerów proxy. Dwa z bardziej popularnych to Nginx i HAProxy. Oba te narzędzia są w stanie wykonać kompresję gzip i dodać obsługę HTTPS, a także specjalizują się w innych obszarach. Nginx jest bardziej popularny z dwóch opcji, a także ma kilka innych korzystnych możliwości, takich jak możliwość serwowania plików statycznych z systemu plików, więc użyjemy go jako przykładu w tym artykule.

teraz, gdy wiemy, co to jest odwrotne proxy, możemy teraz przyjrzeć się, dlaczego chcielibyśmy użyć jednego z węzłem.js.

dlaczego powinienem używać odwrotnego Proxy?

zakończenie SSL jest jednym z najpopularniejszych powodów, dla których używa się odwrotnego proxy. Zmiana protokołu jednej aplikacji z http na https wymaga nieco więcej pracy niż dodanie s. Węzeł.sam js jest w stanie wykonać niezbędne szyfrowanie i deszyfrowanie dla https I może być skonfigurowany do odczytu niezbędnych plików certyfikatów.

jednak Konfigurowanie protokołu używanego do komunikacji z naszą aplikacją i zarządzanie wygasającymi certyfikatami SSL nie jest czymś, o co nasza aplikacja musi się martwić. Sprawdzanie certyfikatów w bazie kodowej byłoby nie tylko uciążliwe, ale również stanowiłoby zagrożenie bezpieczeństwa. Nabywanie certyfikatów z centralnej lokalizacji przy uruchamianiu aplikacji również wiąże się z ryzykiem.

z tego powodu lepiej jest wykonać zakończenie SSL poza aplikacją, zwykle w odwrotnym serwerze proxy. Dzięki technologiom takim jakcertbot by Let ’ s Encrypt, utrzymywanie certyfikatów w Nginx jest tak proste, jak skonfigurowanie Zadania cron. Takie zadanie może automatycznie instalować nowe certyfikaty i dynamicznie rekonfigurować proces Nginx. Jest to znacznie mniej uciążliwy proces niż, powiedzmy, ponowne uruchamianie każdego węzła.instancja aplikacji js.

ponadto, zezwalając odwrotnemu proxy na zakończenie SSL, oznacza to, że tylko kod napisany przez autorów odwrotnego proxy ma dostęp do prywatnego certyfikatu SSL. Jednak, jeśli węzeł.aplikacja js obsługuje protokół SSL, wtedy każdy moduł strony trzeciej używany przez aplikację-nawet potencjalnie złośliwe Moduły – będzie miał dostęp do prywatnego certyfikatu SSL.

Kompresja gzip

kompresja gzip to kolejna funkcja, którą należy przenieść z aplikacji do odwrotnego serwera proxy. Zasady kompresji gzip to coś, co najlepiej ustawić na poziomie organizacji, zamiast określać i konfigurować dla każdej aplikacji.

przy podejmowaniu decyzji co do gzip ’ a najlepiej użyć logiki. Na przykład, pliki, które są bardzo małe, być może mniejsze niż 1KB, prawdopodobnie nie są warte kompresji, ponieważ skompresowana wersja gzip może być czasami większa lub obciążenie procesora związane z dekompresją pliku przez Klienta może nie być tego warte. Ponadto, w przypadku danych binarnych, w zależności od formatu może nie korzystać z kompresji. gzip jest również czymś, czego nie można po prostu włączyć lub wyłączyć, wymaga sprawdzenia przychodzącego nagłówkaAccept-Encoding pod kątem kompatybilnych algorytmów kompresji.

klastrowanie

JavaScript jest językiem jednowątkowym, a co za tym idzie, węzłem.js tradycyjnie był jednowątkową platformą serwerową (choć obecnie eksperymentalna obsługa wątków roboczych dostępna w węźle.js v10 ma to zmienić). Oznacza to uzyskanie jak największej przepustowości z węzła.aplikacja js, jak to możliwe, wymaga uruchomienia mniej więcej takiej samej liczby instancji, jak rdzeni procesora.

węzeł.js jest wyposażony we wbudowany Modułcluster, który może to zrobić. Przychodzące żądania HTTP będą wysyłane do głównego procesu, a następnie wysyłane do pracowników klastra.

jednak dynamiczne skalowanie pracowników klastra wymagałoby pewnego wysiłku. Zwykle dodaje się również narzut w uruchamianiu dodatkowego węzła.proces js jako główny proces dyspozytorski. Ponadto, skalowanie procesów na różnych maszynach jest czymś, czego cluster nie może zrobić.

z tych powodów czasami lepiej jest użyć odwrotnego proxy do wysyłania żądań do działającego węzła.procesy js. Takie odwrotne proxy mogą być dynamicznie konfigurowane tak, aby wskazywały na nowe procesy aplikacji w momencie ich pojawienia się. Tak naprawdę, aplikacja powinna po prostu zajmować się wykonywaniem własnej pracy, nie powinna zajmować się zarządzaniem wieloma kopiami i wysyłaniem żądań.

Enterprise Routing

w przypadku ogromnych aplikacji internetowych, takich jak te budowane przez przedsiębiorstwa wielozespołowe, bardzo przydatne jest posiadanie odwrotnego proxy do określania, do którego miejsca mają być przekazywane żądania. Na przykład żądania wysłane do example.org/search/* mogą być kierowane do aplikacji wewnętrznego wyszukiwania, podczas gdy inne żądania wysłane do example.org/profile/* mogą być wysyłane do aplikacji wewnętrznego profilu.

takie oprzyrządowanie pozwala na inne zaawansowane funkcje, takie jak sticky sessions, Blue/Green deployments, testowanie A/B itp. Osobiście pracowałem w kodzie, w którym taka logika była wykonywana w aplikacji i takie podejście sprawiło, że aplikacja była dość trudna do utrzymania.

korzyści z wydajności

.js jest bardzo plastyczny. Jest w stanie obsługiwać statyczne zasoby z systemu plików, wykonywać kompresję gzip za pomocą odpowiedzi HTTP, ma wbudowaną obsługę HTTPS i wiele innych funkcji. Ma nawet możliwość uruchamiania wielu instancji aplikacji i wykonywania własnych wysyłek żądań, poprzez moduł cluster.

a jednak ostatecznie w naszym najlepszym interesie jest, aby odwrotne proxy obsługiwały te operacje za nas, zamiast mieć nasz węzeł.aplikacja js zrób to. Inny niż każdy z powodów wymienionych powyżej, inny powód, dla którego chcemy wykonywać te operacje poza węzłem.js wynika z efektywności.

szyfrowanie SSL i kompresja gzip to dwie operacje silnie związane z procesorem. Dedykowane narzędzia reverse proxy, takie jak Nginx i HAProxy, zazwyczaj wykonują te operacje szybciej niż węzeł.js. Posiadanie serwera www takiego jak nginx odczytuje statyczną zawartość z dysku będzie szybsze niż węzeł.js też. Nawet klastrowanie może być czasami bardziej wydajne, ponieważ odwrotne proxy, takie jak Nginx, zużywają mniej pamięci i procesora niż dodatkowy węzeł.proces js.

ale nie wierz nam na słowo. Zróbmy kilka benchmarków!

następujące testy obciążenia zostały przeprowadzone przy użyciusiege. Uruchomiliśmy polecenie z wartością współbieżności 10 (10 jednoczesnych użytkowników składających żądanie) i polecenie działało do 20 000 iteracji (dla 200 000 całkowitych żądań).

aby sprawdzić pamięć uruchamiamy polecenie pmap <pid> | grep total kilka razy w ciągu całego życia benchmarku, a następnie uśredniamy wyniki. Podczas uruchamiania Nginx z pojedynczym wątkiem roboczym w końcu działają dwie instancje, jedna jest master, a druga worker. Następnie sumujemy dwie wartości. Podczas uruchamiania węzła.js klaster 2 będzie 3 procesy, jeden jest mistrzem, a pozostałe dwa są pracownicy. Kolumna pamięci approx w poniższej tabeli jest sumą całkowitą każdego Nginx i węzła.proces js dla danego testu.

oto wyniki testu porównawczego:

w benchmarku node-cluster używamy 2 pracowników. Oznacza to, że istnieją 3 węzły.uruchomione procesy js: 1 master i 2 workers. W benchmarku nginx-cluster-nodemamy 2 węzły.uruchomione procesy js. Każdy test Nginx ma jeden proces główny Nginx i jeden proces roboczy nginx. Benchmarki polegają na odczytaniu pliku z dysku, ani Nginx ani Node.js zostały skonfigurowane do buforowania pliku w pamięci.

używanie Nginx do zakończenia SSL dla węzła.js powoduje wzrost przepustowości o ~16% (749rps do 865rps). Użycie Nginx do kompresji gzip powoduje wzrost przepustowości o ~50% (5,047 rps do 7,590 rps). Korzystanie z Nginx do zarządzania klastrem procesów spowodowało karę wydajności w wysokości ~-1% (8,006 rps do 7,908 rps), prawdopodobnie ze względu na obciążenie związane z przekazaniem dodatkowego żądania przez urządzenie sieciowe typu loopback.

zasadniczo wykorzystanie pamięci pojedynczego węzła.proces js wynosi ~600MB, podczas gdy użycie pamięci procesu Nginx wynosi około ~ 50MB. Mogą się one nieco zmieniać w zależności od używanych funkcji, na przykład węzła.js używa dodatkowego ~13MB podczas wykonywania zakończenia SSL, A Nginx używa dodatkowego ~4MB, gdy jest używany jako odwrotny werset proxy obsługujący statyczną zawartość z systemu plików. Ciekawostką jest to, że Nginx wykorzystuje stałą ilość pamięci przez cały okres użytkowania. Jednak Węzeł.js stale się zmienia ze względu na zbieranie śmieci charakter JavaScript.

oto wersje oprogramowania używanego podczas wykonywania tego testu:

• nginx:1.14.2
• węzeł.js: 10.15.3
• Oblężenie: 3.0.8

testy przeprowadzono na maszynie z 16 GB pamięci, i7-7500U CPU 4x2.70GHz I jądrze Linuksa 4.19.10. Wszystkie pliki niezbędne do odtworzenia powyższych benchmarków są dostępne tutaj:
IntrinsicLabs/NodeJS-reverse-proxy-benchmarks.

uproszczony kod aplikacji

Benchmarki są fajne i w ogóle, ale moim zdaniem największe korzyści z odciążenia pracy z węzła.aplikacja js do odwrotnego proxy to prostota kodu. Możemy zmniejszyć liczbę linii potencjalnie błędnego imperatywnego kodu aplikacji i wymienić go na deklaratywną konfigurację. Powszechnym sentymentem wśród programistów jest to, że są bardziej pewni kodu napisanego przez zewnętrzny zespół inżynierów — takich jak Nginx — niż kodu napisanego przez nich samych.

zamiast instalować i zarządzać oprogramowaniem pośredniczącym do kompresji gzip i utrzymywać je na bieżąco w różnych węzłach.projekty js możemy zamiast tego skonfigurować je w jednym miejscu. Zamiast wysyłać lub pobierać certyfikaty SSL i ponownie je pozyskiwać lub ponownie uruchamiać procesy aplikacyjne, możemy zamiast tego użyć istniejących narzędzi do zarządzania certyfikatami. Zamiast dodawać conditionals do naszej aplikacji, aby sprawdzić, czy Proces jest master lub worker, możemy załadować go do innego narzędzia.

odwrotny serwer proxy pozwala naszej aplikacji skupić się na logice biznesowej i zapomnieć o protokołach i zarządzaniu procesami.