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.