Przedmowa
Aktualizacja w 2016 roku. Wszystko ewoluuje, wszystkie serwery stają się coraz lepsze, wszystkie obsługują SSL, a sieć jest jeszcze bardziej niesamowita.
O ile nie zaznaczono inaczej, poniższe informacje są skierowane do profesjonalistów w biznesie i przedsiębiorstwach typu start-up, obsługujących tysiące do milionów użytkowników.
Te narzędzia i architektury wymagają dużej liczby użytkowników / sprzętu / pieniędzy. Możesz spróbować w laboratorium domowym lub na blogu, ale to nie ma większego sensu.
Zasadniczo pamiętaj, że chcesz zachować prostotę . Każde dołączone oprogramowanie pośrednie to kolejny kluczowy element oprogramowania pośredniego do utrzymania. Doskonałości nie osiąga się, gdy nie ma nic do dodania, ale gdy nie ma już nic do usunięcia.
Niektóre typowe i interesujące wdrożenia
HAProxy (równoważenie) + nginx (aplikacja php + buforowanie)
Serwer to nginx z uruchomionym php. Gdy nginx już tam jest, równie dobrze może obsługiwać buforowanie i przekierowania.
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (równoważenie) + lakier (buforowanie) + Tomcat (aplikacja Java)
HAProxy może przekierowywać do Varnish na podstawie identyfikatora URI żądania (* .jpg * .css * .js).
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (równoważenie) + nginx (SSL do hosta i buforowanie) + serwer WWW (aplikacja)
Serwery nie mówią SSL, chociaż KAŻDY MUSI MÓWIĆ SSL ( szczególnie ten link HAProxy-WebServer z prywatnymi informacjami użytkownika przechodzącymi przez EC2 ). Dodanie lokalnego nginx pozwala ustawić SSL na hoście. Gdy nginx już tam jest, równie dobrze może buforować i przepisywać adresy URL.
Uwaga : Przekierowanie portu 443: 8080 ma miejsce, ale nie jest częścią funkcji. Przekierowywanie portów nie ma sensu. Moduł równoważenia obciążenia może komunikować się bezpośrednio z serwerem WWW: 8080.
(nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
Middleware
HAProxy: moduł równoważenia obciążenia
Główne cechy :
- Równoważenie obciążenia (TCP, HTTP, HTTPS)
- Wiele algorytmów (round robin, source ip, headers)
- Trwałość sesji
- Zakończenie SSL
Podobne alternatywy : nginx (wielofunkcyjny serwer sieciowy konfigurowany jako moduł równoważenia obciążenia)
Różne alternatywy : chmura (Amazon ELB, moduł równoważenia obciążenia Google), sprzęt (F5, fortinet, netscaler crix), inne i na całym świecie (DNS, anycast, CloudFlare)
Co robi HAProxy i kiedy należy go używać?
Ilekroć potrzebujesz równoważenia obciążenia. HAProxy to rozwiązanie.
Z wyjątkiem sytuacji, gdy chcesz bardzo tanie LUB szybkie i brudne LUB nie masz dostępnych umiejętności, możesz użyć ELB: D
Z wyjątkiem sytuacji, gdy pracujesz w bankowości / administracji publicznej lub podobnej firmie i wymagasz korzystania z własnego centrum danych o wysokich wymaganiach (dedykowana infrastruktura, niezawodne przełączanie awaryjne, 2 warstwy zapory ogniowej, audyty, SLA, aby zapłacić x% za minutę przestoju, wszystko w jednym) możesz umieścić 2 F5 na szafie zawierającej 30 serwerów aplikacji.
Z wyjątkiem sytuacji, gdy chcesz przejść przez 100k HTTP (S) [i wiele witryn], MUSISZ mieć wiele HAProxy z warstwą [globalnego] równoważenia obciążenia przed nimi (cloudflare, DNS, anycast). Teoretycznie globalny moduł równoważący może rozmawiać bezpośrednio z serwerami sieciowymi, umożliwiając porzucenie HAProxy. Zwykle POWINNYŚCIE utrzymywać HAProxy jako publiczne punkty wejścia do centrum danych i dostroić zaawansowane opcje, aby zachować równowagę między hostami i zminimalizować wariancję.
Osobista opinia : mały, zamknięty projekt open source, w całości poświęcony JEDNEJ PRAWDZIWEMU CELU. Wśród najłatwiejszej konfiguracji (plik JEDEN), najbardziej przydatne i najbardziej niezawodne oprogramowanie open source, z jakim się spotkałem.
Nginx: Apache, który nie jest do bani
Główne cechy :
- WebServer HTTP lub HTTPS
- Uruchamiaj aplikacje w CGI / PHP / jakiś inny
- Przekierowanie / przepisanie adresu URL
- Kontrola dostępu
- Manipulowanie nagłówkami HTTP
- Buforowanie
- Odwrotny serwer proxy
Podobne alternatywy : Apache, Lighttpd, Tomcat, Gunicorn ...
Apache był de facto serwerem internetowym, znanym również jako gigantyczny ruch w klastrze składający się z dziesiątek modułów i tysięcy linii httpd.confna wierzchu uszkodzonej architektury przetwarzania żądań. nginx ponownie to wszystko, z mniejszą liczbą modułów, (nieco) prostszą konfiguracją i lepszą architekturą rdzenia.
Co robi nginx i kiedy musisz go używać?
Serwer WWW jest przeznaczony do uruchamiania aplikacji. Gdy twoja aplikacja jest rozwijana do działania na nginx, masz już nginx i równie dobrze możesz korzystać ze wszystkich jego funkcji.
Z wyjątkiem sytuacji, gdy twoja aplikacja nie jest przeznaczona do uruchamiania na nginx, a nginx nie ma nigdzie na twoim stosie (ktoś robi zakupy w Java?), To nie ma sensu w nginx. Funkcje obecnego serwera prawdopodobnie będą istnieć na twoim obecnym serwerze, a inne zadania są lepiej obsługiwane przez odpowiednie dedykowane narzędzie (HAProxy / Varnish / CDN).
Z wyjątkiem sytuacji, gdy twój serwer / aplikacja nie ma funkcji, jest trudna do skonfigurowania i / lub wolisz umrzeć niż patrzeć na nią (Gunicorn czy ktoś?), Możesz umieścić nginx z przodu (tj. Lokalnie na każdym węźle), aby wykonać adres URL przepisywanie, wysyłanie przekierowań 301, wymuszanie kontroli dostępu, szyfrowanie SSL i edytowanie nagłówków HTTP w locie. [Są to funkcje oczekiwane od serwera]
Lakier: serwer buforowania
Główne cechy :
- Buforowanie
- Zaawansowane buforowanie
- Buforowanie drobnoziarniste
- Buforowanie
Podobne alternatywy : nginx (wielofunkcyjny serwer WWW konfigurowalny jako serwer buforujący)
Różne alternatywy : CDN (Akamai, Amazon CloudFront, CloudFlare), Sprzęt (F5, Fortinet, Citrix Netscaler)
Co robi Varnish i kiedy należy go używać?
Robi buforowanie, tylko buforowanie. Zwykle nie jest to warte wysiłku i jest stratą czasu. Zamiast tego wypróbuj CDN. Pamiętaj, że buforowanie jest ostatnią rzeczą, na którą powinieneś zwrócić uwagę podczas prowadzenia strony internetowej.
Z wyjątkiem sytuacji, gdy prowadzisz witrynę internetową poświęconą wyłącznie zdjęciom lub filmom, powinieneś dokładnie przyjrzeć się CDN i poważnie pomyśleć o buforowaniu.
Z wyjątkiem sytuacji, gdy jesteś zmuszony używać własnego sprzętu we własnym centrum danych (CDN nie jest opcją), a twoje serwery WWW są straszne w dostarczaniu plików statycznych (dodanie większej liczby serwerów nie pomaga), wtedy Varnish jest ostatecznością.
Z wyjątkiem sytuacji, gdy masz witrynę z przeważnie statyczną, ale złożoną, dynamicznie generowaną treścią (zobacz poniższe akapity), Varnish może zaoszczędzić dużo mocy obliczeniowej na twoich serwerach.
Buforowanie statyczne jest przereklamowane w 2016 r
Buforowanie jest prawie bez konfiguracji, bez pieniędzy i czasu. Po prostu subskrybuj CloudFlare, CloudFront lub Akamai lub MaxCDN. Czas, który zajmuje mi napisanie tego wiersza, jest dłuższy niż czas potrzebny na ustawienie buforowania ORAZ piwo, które trzymam w dłoni, jest droższe niż mediana subskrypcji CloudFlare.
Wszystkie te usługi działają od razu dla statycznych * .css * .js * .png i innych. W rzeczywistości w większości honorują Cache-Controldyrektywę w nagłówku HTTP. Pierwszym krokiem buforowania jest skonfigurowanie serwerów WWW do wysyłania odpowiednich dyrektyw pamięci podręcznej. Nie ma znaczenia, co CDN, jaki lakier, jaka przeglądarka jest w środku.
Uwagi dotyczące wydajności
Lakier powstał w czasie, gdy przeciętne serwery internetowe dusiły się, aby udostępnić zdjęcie kota na blogu. Obecnie jeden przykład przeciętnego nowoczesnego, wielowątkowego serwera asynchronicznego opartego na modnym haśle może niezawodnie dostarczać kocięta do całego kraju. Dzięki uprzejmości sendfile().
Przeprowadziłem szybkie testy wydajności dla ostatniego projektu, nad którym pracowałem. Pojedyncze wystąpienia tomcat mogłyby obsłużyć od 21 000 do 33 000 plików statycznych na sekundę przez HTTP (testowanie plików od 20B do 12kB przy różnej liczbie połączeń HTTP / klient). Stały ruch wychodzący przekracza 2,4 Gb / s. Produkcja będzie miała tylko interfejsy 1 Gb / s. Nie może być lepszy niż sprzęt, nie ma sensu nawet próbować lakieru.
Kompleks buforowania zmieniający zawartość dynamiczną
CDN i serwery buforujące zwykle ignorują adres URL za pomocą parametrów takich jak: ?article=1843ignorują każde żądanie z sesyjnymi plikami cookie lub uwierzytelnionymi użytkownikami i ignorują większość typów MIME, w tym application/jsonpochodzące z /api/article/1843/info. Dostępne są opcje konfiguracji, ale zazwyczaj nie są drobnoziarniste, a raczej „wszystko albo nic”.
Lakier może mieć niestandardowe złożone reguły (patrz VCL), aby zdefiniować, co można buforować, a co nie. Reguły te mogą buforować określoną zawartość według identyfikatora URI, nagłówków i bieżącego pliku cookie sesji użytkownika oraz typu MIME i zawartości WSZYSTKO RAZEM. To może zaoszczędzić dużo mocy obliczeniowej na serwerach WWW dla niektórych bardzo specyficznych wzorców obciążenia. Właśnie wtedy Lakier jest przydatny i NIESAMOWITY.
Wniosek
Zajęło mi trochę czasu, aby zrozumieć wszystkie te elementy, kiedy ich używać i jak pasują do siebie. Mam nadzieję, że to może ci pomóc.
To okazuje się dość długie (6 godzin na napisanie. OMG!: O). Może powinienem założyć blog lub książkę na ten temat. Ciekawostka: Wydaje się, że nie ma ograniczenia długości odpowiedzi.