Prefazione
Aggiornamento nel 2016. Le cose si stanno evolvendo, tutti i server stanno migliorando, supportano tutti SSL e il Web è più sorprendente che mai.
Se non diversamente indicato, quanto segue è rivolto ai professionisti del settore e alle start-up, supportando da migliaia a milioni di utenti.
Questi strumenti e architetture richiedono molti utenti / hardware / denaro. Puoi provarlo in un laboratorio di casa o gestire un blog, ma non ha molto senso.
Come regola generale, ricorda che vuoi mantenerlo semplice . Ogni middleware aggiunto è un altro elemento fondamentale del middleware da mantenere. La perfezione non si ottiene quando non c'è nulla da aggiungere ma quando non c'è più niente da rimuovere.
Alcune implementazioni comuni e interessanti
HAProxy (bilanciamento) + nginx (applicazione php + memorizzazione nella cache)
Il server web è nginx con php in esecuzione. Quando nginx è già lì, potrebbe anche gestire la memorizzazione nella cache e i reindirizzamenti.
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (bilanciamento) + Varnish (memorizzazione nella cache) + Tomcat (applicazione Java)
HAProxy può reindirizzare a Varnish in base all'URI della richiesta (* .jpg * .css * .js).
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (bilanciamento) + nginx (SSL per l'host e la memorizzazione nella cache) + Webserver (applicazione)
I server web non parlano SSL anche se TUTTI DEVONO PARLARE SSL ( specialmente questo collegamento HAProxy-WebServer con le informazioni degli utenti privati che passano attraverso EC2 ). L'aggiunta di un nginx locale consente di portare SSL nell'host. Una volta che nginx è lì, potrebbe anche fare un po 'di cache e riscrittura degli URL.
Nota : il reindirizzamento delle porte 443: 8080 sta avvenendo ma non fa parte delle funzionalità. Non ha senso eseguire il reindirizzamento delle porte. Il bilanciamento del carico potrebbe parlare direttamente al server web: 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: il bilanciamento del carico
Caratteristiche principali :
- Bilanciamento del carico (TCP, HTTP, HTTPS)
- Algoritmi multipli (round robin, source ip, headers)
- Persistenza della sessione
- Terminazione SSL
Alternative simili : nginx (web server multiuso configurabile come bilanciamento del carico)
Diverse alternative : Cloud (Amazon ELB, Google load balancer), Hardware (F5, fortinet, citrix netscaler), Altro e in tutto il mondo (DNS, anycast, CloudFlare)
Cosa fa HAProxy e quando DEVI utilizzarlo?
Ogni volta che è necessario il bilanciamento del carico. HAProxy è la soluzione ideale.
Tranne quando si desidera molto economico o veloce e sporco O non si hanno le competenze disponibili, è possibile utilizzare un ELB: D
Tranne quando si è in banca / governo / simili che richiedono di utilizzare il proprio data center con requisiti rigidi (infrastruttura dedicata, failover affidabile, 2 livelli di firewall, elementi di controllo, SLA per pagare x% al minuto di downtime, tutto in uno) quindi è possibile inserire 2 F5 nella parte superiore del rack contenente i 30 server delle applicazioni.
Tranne quando si desidera superare 100k HTTP (S) [e siti multipli], è NECESSARIO disporre di multipli HAProxy con uno strato di bilanciamento del carico [globale] di fronte a loro (cloudflare, DNS, anycast). Teoricamente, il bilanciamento globale potrebbe parlare direttamente con i server web permettendo di abbandonare HAProxy. Di solito, tuttavia, DOVREBBE tenere HAProxy (s) come punti di accesso pubblici al tuo data center e ottimizzare le opzioni avanzate per bilanciare equamente tra host e ridurre al minimo la varianza.
Opinione personale : un progetto piccolo, contenuto e open source, interamente dedicato a UN VERO SCOPO. Tra la configurazione più semplice (UN file), il software open source più utile e più affidabile che ho incontrato nella mia vita.
Nginx: Apache che non fa schifo
Caratteristiche principali :
- WebServer HTTP o HTTPS
- Esegui applicazioni in CGI / PHP / alcuni altri
- Reindirizzamento / riscrittura URL
- Controllo di accesso
- Manipolazione delle intestazioni HTTP
- caching
- Proxy inverso
Alternative simili : Apache, Lighttpd, Tomcat, Gunicorn ...
Apache era il web server di fatto, noto anche come un gigantesco clusterfuck di dozzine di moduli e migliaia di righe httpd.confsu un'architettura di elaborazione delle richieste interrotta. nginx rifa tutto questo, con meno moduli, una configurazione (leggermente) più semplice e una migliore architettura di base.
Cosa fa nginx e quando DEVI usarlo?
Un server web è progettato per eseguire applicazioni. Quando l'applicazione è sviluppata per essere eseguita su nginx, hai già nginx e puoi anche usare tutte le sue funzionalità.
Tranne quando l'applicazione non è progettata per essere eseguita su nginx e nginx non si trova da nessuna parte nello stack (Java shop qualcuno?), Allora c'è poco senso in nginx. È probabile che le funzionalità dei server web esistano nel tuo attuale server web e le altre attività siano meglio gestite dallo strumento dedicato appropriato (HAProxy / Varnish / CDN).
Tranne quando il tuo server web / applicazione manca di funzionalità, difficile da configurare e / o preferisci morire di lavoro piuttosto che guardarlo (Gunicorn qualcuno?), Allora puoi mettere un nginx in primo piano (cioè localmente su ciascun nodo) per eseguire l'URL riscrivere, inviare 301 reindirizzamenti, applicare il controllo degli accessi, fornire la crittografia SSL e modificare le intestazioni HTTP al volo. [Queste sono le funzionalità attese da un server web]
Vernice: il server di cache
Caratteristiche principali :
- caching
- Caching avanzato
- Caching a grana fine
- caching
Alternative simili : nginx (server web multiuso configurabile come server di cache)
Diverse alternative : CDN (Akamai, Amazon CloudFront, CloudFlare), Hardware (F5, Fortinet, Citrix Netscaler)
Cosa fa Varnish e quando DEVI usarlo?
Fa il caching, solo il caching. Di solito non vale la pena ed è una perdita di tempo. Prova invece CDN. Tieni presente che la memorizzazione nella cache è l'ultima cosa di cui dovresti preoccuparti quando gestisci un sito web.
Tranne quando si esegue un sito Web esclusivamente su immagini o video, è necessario esaminare attentamente la CDN e pensare seriamente alla memorizzazione nella cache.
Tranne quando sei costretto a usare il tuo hardware nel tuo data center (CDN non è un'opzione) e i tuoi server web sono terribili nel fornire file statici (l'aggiunta di più server web non aiuta), allora Varnish è l'ultima risorsa.
Tranne quando si dispone di un sito con contenuto generato per lo più statico ma complesso in modo dinamico (vedere i paragrafi seguenti), Varnish può risparmiare molta potenza di elaborazione sui server web.
La memorizzazione nella cache statica è sopravvalutata nel 2016
La memorizzazione nella cache è quasi senza configurazione, senza denaro e senza tempo. Abbonati a CloudFlare o CloudFront o Akamai o MaxCDN. Il tempo impiegato per scrivere questa riga è più lungo del tempo necessario per impostare la memorizzazione nella cache E la birra che sto tenendo in mano è più costosa dell'abbonamento mediano CloudFlare.
Tutti questi servizi sono pronti all'uso per static * .css * .js * .png e altro. In effetti, onorano principalmente la Cache-Controldirettiva nell'intestazione HTTP. Il primo passo della memorizzazione nella cache è configurare i server Web per l'invio delle direttive cache appropriate. Non importa quale CDN, cosa Varnish, quale browser sia nel mezzo.
Considerazioni sulle prestazioni
Varnish è stato creato in un momento in cui i server Web medi soffocavano per pubblicare un'immagine di gatto su un blog. Al giorno d'oggi una singola istanza del server web moderno asincrono e multi-thread, basato su parole d'ordine, può consegnare gattini in modo affidabile in un intero paese. Per gentile concessione di sendfile().
Ho eseguito alcuni rapidi test delle prestazioni per l'ultimo progetto a cui ho lavorato. Una singola istanza di Tomcat potrebbe servire da 21.000 a 33.000 file statici al secondo su HTTP (test di file da 20B a 12kB con un numero variabile di connessioni HTTP / client). Il traffico in uscita sostenuto è oltre 2,4 Gb / s. La produzione avrà solo interfacce da 1 Gb / s. Non posso fare di meglio dell'hardware, inutile nemmeno provare Varnish.
Caching Complex Modifica del contenuto dinamico
I server CDN e di memorizzazione nella cache di solito ignorano l'URL con parametri come ?article=1843, ignorano qualsiasi richiesta con cookie di sessione o utenti autenticati e ignorano la maggior parte dei tipi MIME incluso il application/jsonda /api/article/1843/info. Ci sono opzioni di configurazione disponibili ma di solito non sono a grana fine, piuttosto "tutto o niente".
Varnish può avere regole complesse personalizzate (vedi VCL) per definire cosa è desiderabile e cosa no. Queste regole possono memorizzare nella cache contenuto specifico per URI, intestazioni e cookie della sessione utente corrente e tipo e contenuto MIME TUTTI INSIEME. Ciò può risparmiare molta potenza di elaborazione sui server web per alcuni schemi di carico molto specifici. Questo è quando Varnish è utile e FANTASTICO.
Conclusione
Mi ci è voluto un po 'di tempo per capire tutti questi pezzi, quando usarli e come si incastrano. Spero che questo possa aiutarti.
Questo risulta essere piuttosto lungo (6 ore per scrivere. OMG!: O). Forse dovrei iniziare un blog o un libro a riguardo. Curiosità: non sembra esserci un limite alla lunghezza della risposta.