Ich habe gesehen, wie Leute empfohlen haben, all diese Funktionen in einem Flow zu kombinieren, aber sie scheinen viele überlappende Funktionen zu haben. Daher möchte ich gerne herausfinden, warum Sie 3 verschiedene Programme durchlaufen möchten, bevor Sie auf Ihren eigentlichen Webserver zugreifen.

Nginx:

• SSL: Ja
• komprimieren: ja
• Cache: ja
• Backend-Pool: ja

Lack:

• SSL: Nein (Stunnel?)
• komprimieren:?
• Cache: ja (Hauptmerkmal)
• Backend-Pool: ja

Haproxy:

• SSL: Nein (Stunnel)
• komprimieren:?
• Cache: Nein
• Backend-Pool: ja (Hauptmerkmal)

Ist die Absicht, all diese Funktionen vor Ihren Hauptwebservern zu verketten, um nur einige ihrer Hauptvorteile zu erhalten?

Es scheint ziemlich zerbrechlich zu sein, dass so viele Dämonen zusammenkommen, um ähnliche Dinge zu tun.

Was ist Ihre Bereitstellungs- und Bestellpräferenz und warum?

Einfach gesagt..

HaProxy ist der beste Open Source Loadbalancer auf dem Markt.
Varnish ist der beste OpenSource-Cacher für statische Dateien auf dem Markt.
Nginx ist der beste Open Source Webserver auf dem Markt.

(Natürlich ist dies meine und die Meinung vieler anderer Leute.)

Im Allgemeinen durchlaufen jedoch nicht alle Abfragen den gesamten Stapel.

Alles geht durch Haproxy und Nginx / Multiple Nginx.
Der einzige Unterschied besteht darin, dass Sie den Lack für statische Anforderungen "anschrauben".

• Jede Anfrage wird im Hinblick auf Redundanz und Durchsatz ausgeglichen (gut, das ist skalierbare Redundanz).
• Jede Anfrage nach statischen Dateien trifft zuerst auf den Lack-Cache (gut, das ist schnell)
• Jede dynamische Anfrage geht direkt an das Backend (großartig, Lack wird nicht verwendet)

Insgesamt passt dieses Modell zu einer skalierbaren und wachsenden Architektur (nehmen Sie Haproxy heraus, wenn Sie nicht über mehrere Server verfügen).

Hoffe das hilft: D

Hinweis: Tatsächlich werde ich auch Pfund für SSL-Abfragen einführen: D
Sie können einen Server zum Entschlüsseln von SSL-Anforderungen und zum Weiterleiten von Standardanforderungen an den Back-End-Stapel einrichten: D (Der gesamte Stapel wird dadurch schneller und einfacher ausgeführt.)

Vorwort

Update im Jahr 2016. Die Dinge entwickeln sich, alle Server werden besser, alle unterstützen SSL und das Web ist erstaunlicher denn je.

Sofern nicht anders angegeben, richtet sich das Folgende an Fachleute in Unternehmen und Start-ups, die Tausende bis Millionen von Benutzern unterstützen.

Diese Tools und Architekturen erfordern eine Menge Benutzer / Hardware / Geld. Sie können dies in einem Heimlabor versuchen oder ein Blog betreiben, aber das macht nicht viel Sinn.

Denken Sie in der Regel daran, dass Sie es einfach halten möchten . Jede angehängte Middleware ist eine weitere wichtige zu wartende Middleware. Perfektion wird nicht erreicht, wenn nichts hinzuzufügen ist, sondern wenn nichts mehr zu entfernen ist.

Einige häufige und interessante Bereitstellungen

HAProxy (Balancing) + Nginx (PHP-Anwendung + Caching)

Der Webserver ist Nginx mit PHP. Wenn Nginx bereits vorhanden ist, kann es das Caching und die Umleitungen übernehmen.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

HAProxy (Balancing) + Lack (Caching) + Tomcat (Java-Anwendung)

HAProxy kann basierend auf der Anforderungs-URI (* .jpg * .css * .js) zu Varnish umleiten.

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

HAProxy (Balancing) + Nginx (SSL zum Host und Caching) + Webserver (Anwendung)

Die Webserver sprechen kein SSL, obwohl JEDER SSL SPRECHEN MUSS ( insbesondere dieser HAProxy-WebServer-Link mit privaten Benutzerinformationen, die EC2 durchlaufen ). Durch Hinzufügen eines lokalen Nginx kann SSL auf den Host gebracht werden. Sobald Nginx da ist, kann es auch etwas Zwischenspeichern und URL-Umschreiben durchführen.

Hinweis : Die Portumleitung 443: 8080 findet statt, ist jedoch nicht Teil der Funktionen. Es hat keinen Sinn, eine Portumleitung durchzuführen. Der Load Balancer kann direkt mit dem Webserver: 8080 sprechen.

          (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: DER Load Balancer

Hauptmerkmale :

• Lastausgleich (TCP, HTTP, HTTPS)
• Mehrere Algorithmen (Round Robin, Quell-IP, Header)
• Sitzungspersistenz
• SSL-Kündigung

Ähnliche Alternativen : nginx (als Load Balancer konfigurierbarer Mehrzweck-Webserver)
Verschiedene Alternativen : Cloud (Amazon ELB, Google Load Balancer), Hardware (F5, Fortinet, Citrix Netscaler), Sonstiges & Weltweit (DNS, Anycast, CloudFlare)

Was macht HAProxy und wann MÜSSEN Sie es benutzen?
Wann immer Sie einen Lastenausgleich benötigen. HAProxy ist die Lösung.

Außer wenn Sie sehr billig oder schnell und dreckig wollen oder nicht über die erforderlichen Fähigkeiten verfügen, können Sie eine ELB: D verwenden

Es sei denn, Sie sind in einem Bank- / Regierungs- oder ähnlichen Bereich und müssen Ihr eigenes Rechenzentrum mit hohen Anforderungen (dedizierte Infrastruktur, zuverlässiges Failover, zwei Firewall-Schichten, Prüfsachen, SLA, die x% pro Minute Ausfallzeit zahlen, alles in einem) verwenden Sie können 2 F5 auf das Rack legen, das Ihre 30 Anwendungsserver enthält.

Außer wenn Sie über 100k HTTP (S) [und Multi-Sites] hinausgehen möchten, MÜSSEN Sie ein Vielfaches von HAProxy mit einer Ebene des [globalen] Lastausgleichs vor sich haben (Cloudflare, DNS, Anycast). Theoretisch könnte der globale Balancer direkt mit den Webservern sprechen und so HAProxy aus dem Weg räumen. Normalerweise sollten Sie jedoch HAProxy (s) als öffentlichen Einstiegspunkt (e) für Ihr Rechenzentrum beibehalten und erweiterte Optionen optimieren, um einen fairen Hostausgleich zu erzielen und die Varianz zu minimieren.

Persönliche Meinung : Ein kleines, geschlossenes Open-Source-Projekt, das sich ausschließlich EINEM WAHREN ZWECK widmet. Zu den am einfachsten zu konfigurierenden (EINE Datei), nützlichsten und zuverlässigsten Open-Source-Programmen, die mir in meinem Leben begegnet sind.

Nginx: Apache, der nicht saugt

Hauptmerkmale :

• WebServer HTTP oder HTTPS
• Führen Sie Anwendungen in CGI / PHP / einigen anderen aus
• URL-Umleitung / Umschreiben
• Zugangskontrolle
• Manipulation von HTTP-Headern
• Caching
• Reverse Proxy

Ähnliche Alternativen : Apache, Lighttpd, Tomcat, Gunicorn ...

Apache war der De-facto-Webserver, der auch als gigantischer Clusterfick von Dutzenden Modulen und Tausenden Zeilen httpd.confauf einer kaputten Anforderungsverarbeitungsarchitektur bekannt war. nginx macht all das mit weniger Modulen, einer (etwas) einfacheren Konfiguration und einer besseren Kernarchitektur wieder rückgängig.

Was macht Nginx und wann MUSS es verwendet werden?
Ein Webserver soll Anwendungen ausführen. Wenn Ihre Anwendung für die Ausführung auf Nginx entwickelt wurde, haben Sie bereits Nginx und können auch alle seine Funktionen verwenden.

Außer wenn Ihre Anwendung nicht auf nginx ausgeführt werden soll und nginx nirgends in Ihrem Stack zu finden ist (Java-Shop jemand?), Hat nginx wenig Sinn. Die Funktionen des Webservers sind wahrscheinlich in Ihrem aktuellen Webserver vorhanden, und die anderen Aufgaben werden besser mit dem entsprechenden dedizierten Tool (HAProxy / Varnish / CDN) erledigt.

Außer wenn Ihrem Webserver / Ihrer Anwendung Funktionen fehlen, die schwer zu konfigurieren sind und / oder Sie lieber den Job verlieren, als sie sich anzusehen (Gunicorn, jemand?), Können Sie einen Nginx voranstellen (dh lokal auf jedem Knoten), um die URL auszuführen Umschreiben, 301-Umleitungen senden, Zugriffskontrolle erzwingen, SSL-Verschlüsselung bereitstellen und HTTP-Header direkt bearbeiten. [Dies sind die Funktionen, die von einem Webserver erwartet werden]

Lack: DER Caching-Server

Hauptmerkmale :

• Caching
• Erweitertes Caching
• Feinkörniges Caching
• Caching

Ähnliche Alternativen : nginx (als Caching-Server konfigurierbarer Mehrzweck-Webserver)
Verschiedene Alternativen : CDN (Akamai, Amazon CloudFront, CloudFlare), Hardware (F5, Fortinet, Citrix Netscaler)

Was macht Lack und wann MUSS er verwendet werden?
Es wird nur zwischengespeichert. Die Mühe lohnt sich normalerweise nicht und es ist Zeitverschwendung. Versuchen Sie stattdessen CDN. Beachten Sie, dass Caching das Letzte ist, worauf Sie beim Betrieb einer Website achten sollten.

Außer wenn Sie eine Website ausschließlich über Bilder oder Videos betreiben, sollten Sie CDN gründlich prüfen und ernsthaft über das Caching nachdenken.

Außer wenn Sie gezwungen sind, Ihre eigene Hardware in Ihrem eigenen Rechenzentrum zu verwenden (CDN ist keine Option) und Ihre Webserver schreckliche Schwierigkeiten haben, statische Dateien zu liefern (Hinzufügen weiterer Webserver hilft nicht), ist Lack der letzte Ausweg.

Außer wenn Sie eine Site mit überwiegend statischem, jedoch komplexem, dynamisch generiertem Inhalt haben (siehe die folgenden Absätze), kann Varnish viel Rechenleistung auf Ihren Webservern einsparen.

Das statische Caching wird 2016 überbewertet

Caching ist nahezu frei von Konfiguration, Geld und Zeit. Abonnieren Sie einfach CloudFlare, CloudFront, Akamai oder MaxCDN. Die Zeit, die ich zum Schreiben dieser Zeile benötige, ist länger als die Zeit, die zum Einrichten des Cachings erforderlich ist, UND das Bier, das ich in der Hand halte, ist teurer als das mittlere CloudFlare-Abonnement.

Alle diese Dienste funktionieren standardmäßig für statische * .css * .js * .png und mehr. Tatsächlich beachten sie meistens die Cache-ControlDirektive im HTTP-Header. Der erste Schritt des Zwischenspeicherns besteht darin, Ihre Webserver so zu konfigurieren, dass sie die richtigen Cache-Anweisungen senden. Egal welches CDN, welcher Lack, welcher Browser in der Mitte ist.

Leistungsüberlegungen

Der Lack wurde zu einer Zeit erstellt, als die durchschnittlichen Webserver erstickten, um ein Katzenbild in einem Blog zu veröffentlichen. Heutzutage kann eine einzelne Instanz des durchschnittlichen modernen asynchronen, Buzzword-gesteuerten Multithread-Webservers zuverlässig Kätzchen in ein ganzes Land liefern. Mit freundlicher Genehmigung von sendfile().

Für das letzte Projekt, an dem ich gearbeitet habe, habe ich einige schnelle Leistungstests durchgeführt. Eine einzelne Tomcat-Instanz kann 21.000 bis 33.000 statische Dateien pro Sekunde über HTTP bereitstellen (Testen von Dateien von 20 bis 12 KB bei unterschiedlicher Anzahl von HTTP- / Client-Verbindungen). Der anhaltende ausgehende Datenverkehr liegt über 2,4 Gbit / s. Die Produktion wird nur 1-Gbit / s-Schnittstellen haben. Kann nicht besser sein als die Hardware, es macht keinen Sinn, es mit Lack zu versuchen.

Komplexe Änderungen an dynamischen Inhalten zwischenspeichern

CDN- und Caching-Server ignorieren normalerweise URLs mit Parametern wie ?article=1843, sie ignorieren Anforderungen mit Sitzungscookies oder authentifizierten Benutzern und sie ignorieren die meisten MIME-Typen, einschließlich der application/jsonvon /api/article/1843/info. Es stehen Konfigurationsoptionen zur Verfügung, die jedoch normalerweise nicht feinkörnig sind, sondern "alles oder nichts".

Lack kann benutzerdefinierte komplexe Regeln haben (siehe VCL), um zu definieren, was zwischengespeichert werden kann und was nicht. Mit diesen Regeln können bestimmte Inhalte nach URI, Headern und dem aktuellen Sitzungscookie des Benutzers sowie nach MIME-Typ und Inhalt GEMEINSAM zwischengespeichert werden. Dies kann bei Webservern für ein bestimmtes Lademuster eine Menge Rechenleistung einsparen. Das ist, wenn Lack handlich und FANTASTISCH ist.

Fazit

Ich habe eine Weile gebraucht, um all diese Teile zu verstehen, wann sie verwendet werden und wie sie zusammenpassen. Hoffe das kann dir helfen.

Das stellt sich als ziemlich lang heraus (6 Stunden zu schreiben. OMG!: O). Vielleicht sollte ich einen Blog oder ein Buch darüber starten. Unterhaltsame Tatsache: Die Länge der Antwort scheint nicht begrenzt zu sein.

Es ist wahr, dass die 3 Tools gemeinsame Funktionen haben. Die meisten Setups eignen sich für jede Kombination von 2 unter 3. Es kommt darauf an, was ihr Hauptzweck ist. Wenn Sie wissen, dass Ihr Anwendungsserver statisch schnell ist (z. B .: nginx), ist es üblich, zu akzeptieren, dass Sie auf Zwischenspeicher verzichten. Es ist üblich, auf einige Lastausgleichsfunktionen zu verzichten, wenn Sie Dutzende oder Hunderte von Servern installieren und sich nicht darum kümmern, das Beste aus ihnen herauszuholen oder Probleme zu beheben. Es ist üblich, einige Webserver-Funktionen zu opfern, wenn Sie eine verteilte Anwendung mit vielen Komponenten überall ausführen möchten. Trotzdem bauen einige Leute mit ihnen interessante Farmen.

Sie sollten bedenken, dass es sich um 3 feste Produkte handelt. Im Allgemeinen müssen Sie sie nicht aufladen. Wenn Sie Front-SSL benötigen, ist nginx zunächst als Reverse-Proxy in Ordnung. Wenn Sie das nicht brauchen, ist der Lack auf der Vorderseite in Ordnung. Dann können Sie haproxy zum Lastenausgleich Ihrer Apps verwenden. Manchmal möchten Sie auch auf dem Haproxy selbst zu verschiedenen Serverfarmen wechseln, je nach Dateityp oder Pfad.

Manchmal müssen Sie sich vor schweren DDoS-Angriffen schützen, und Haproxy im Vordergrund ist geeigneter als die anderen.

Im Allgemeinen sollten Sie sich keine Gedanken darüber machen, welchen Kompromiss Sie zwischen Ihren Entscheidungen eingehen sollten. Sie sollten entscheiden, wie sie zusammengesetzt werden sollen, um jetzt und in Zukunft die bestmögliche Flexibilität für Ihre Anforderungen zu erhalten. Selbst wenn Sie mehrere davon mehrfach stapeln, kann es je nach Ihren Anforderungen manchmal richtig sein.

Ich hoffe, das hilft!

Alle anderen Antworten stammen aus der Zeit vor 2010, daher wird ein aktualisierter Vergleich hinzugefügt.

Nginx

• Ein vollständiger Webserver, andere Funktionen können ebenfalls verwendet werden. ZB: HTTP-Komprimierung
• SSL-Unterstützung
• Sehr leicht, da Nginx von Anfang an leicht ist.
• Caching-Leistung von Near Varnish
• Nahe an der HAProxy-Lastausgleichsleistung

Lack

• Am besten für komplexe Caching-Szenarien und die Einbindung in die Anwendungen.
• bester Cacher für statische Dateien
• Keine SSL-Unterstützung
• Speicher und CPU-Esser

Haproxy

• bester Loadbalancer für modernste Loadbalancer-Funktionen, vergleichbar mit Hardware-Loadbalancern
• SSL wird seit 1.5.0 unterstützt
• Einfacher, nur ein TCP-Proxy ohne eine HTTP-Implementierung zu sein, was ihn schneller und weniger fehleranfällig macht.

Die beste Methode scheint es also zu sein, alle in einer geeigneten Reihenfolge zu implementieren.

Für allgemeine Zwecke ist Nginx jedoch am besten geeignet, da Sie für alle eine überdurchschnittliche Leistung erzielen: Caching, Reverse Proxying, Lastausgleich mit sehr geringem Aufwand für die Ressourcennutzung. Und dann haben Sie SSL und volle Webserver-Funktionen.

Varnish unterstützt den Lastenausgleich: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx unterstützt den Lastenausgleich: http://wiki.nginx.org/NginxHttpUpstreamModule

Ich würde das einfach mit lack + stunnel konfigurieren. Wenn ich aus irgendeinem anderen Grund Nginx brauchte, würde ich nur Nginx + Lack verwenden. Sie können veranlassen, dass Nginx SSL-Verbindungen akzeptiert und diese zum Lackieren überträgt, und dann über http mit Nginx sprechen.

Einige Leute können Nginx (oder Apache) in die Mischung werfen, weil dies etwas allgemeinere Werkzeuge als Varnish sind. Wenn Sie beispielsweise Inhalte (z. B. mithilfe von XDV, Apache-Filtern usw.) auf der Proxy-Ebene transformieren möchten, benötigen Sie eine dieser Optionen, da Varnish dies nicht alleine kann. Einige Benutzer kennen die Konfiguration dieser Tools möglicherweise besser. Daher ist es einfacher, Varnish als einfachen Cache zu verwenden und den Lastenausgleich auf einer anderen Ebene durchzuführen, da sie bereits mit Apache / nginx / haproxy als Load Balancer vertraut sind.