Saya telah melihat orang merekomendasikan menggabungkan semua ini dalam aliran, tetapi mereka tampaknya memiliki banyak fitur yang tumpang tindih jadi saya ingin menggali mengapa Anda mungkin ingin melewati 3 program yang berbeda sebelum memukul server web Anda yang sebenarnya.

nginx:

• ssl: ya
• kompres: ya
• cache: ya
• backend pool: ya

pernis:

• ssl: tidak (stunnel?)
• kompres:?
• cache: ya (fitur utama)
• backend pool: ya

haproxy:

• ssl: tidak (stunnel)
• kompres:?
• cache: tidak
• backend pool: ya (fitur utama)

Apakah maksud merantai semua ini di depan server web utama Anda hanya untuk mendapatkan beberapa manfaat fitur utama mereka?

Tampaknya sangat rapuh untuk memiliki begitu banyak aliran daemon bersama-sama melakukan hal serupa.

Apa pilihan penempatan dan pemesanan Anda dan mengapa?

Sederhananya ..

HaProxy adalah loadbalancer opensource terbaik di pasar.
Varnish adalah cacher file statis opensource terbaik di pasaran.
Nginx adalah server web opensource terbaik di pasaran.

(tentu saja ini adalah pendapat saya dan banyak orang lain)

Tetapi secara umum, tidak semua permintaan melewati seluruh tumpukan.

Semuanya berjalan melalui haproxy dan nginx / multiple nginx's.
Satu-satunya perbedaan adalah Anda "baut" pada pernis untuk permintaan statis.

• setiap permintaan adalah beban untuk redundansi dan throughput (bagus, itu redundansi yang dapat diukur)
• setiap permintaan untuk file statis terlebih dahulu mengenai tembolok pernis (bagus, itu cepat)
• setiap permintaan dinamis langsung ke backend (hebat, pernis tidak digunakan)

Secara keseluruhan, model ini cocok dengan arsitektur yang skalabel dan terus berkembang (ambil haproxy jika Anda tidak memiliki banyak server)

Semoga ini bisa membantu: D

Catatan: Saya juga akan memperkenalkan Pound untuk kueri SSL: D
Anda dapat memiliki server yang didedikasikan untuk mendekripsi permintaan SSL, dan membagikan permintaan standar ke backend stack: D (Ini membuat seluruh tumpukan berjalan lebih cepat dan lebih sederhana)

Kata pengantar

Perbarui pada 2016. Semuanya berkembang, semua server menjadi lebih baik, mereka semua mendukung SSL dan web lebih luar biasa dari sebelumnya.

Kecuali jika dinyatakan, berikut ini ditujukan untuk para profesional dalam bisnis dan pemula, mendukung ribuan hingga jutaan pengguna.

Alat dan arsitektur ini membutuhkan banyak pengguna / perangkat keras / uang. Anda dapat mencoba ini di laboratorium rumah atau menjalankan blog tetapi itu tidak masuk akal.

Sebagai aturan umum, ingatlah bahwa Anda ingin membuatnya tetap sederhana . Setiap middleware yang ditambahkan adalah bagian penting dari middleware yang harus dipelihara. Kesempurnaan tidak tercapai ketika tidak ada yang ditambahkan tetapi ketika tidak ada yang tersisa untuk dihapus.

Beberapa Penyebaran yang Umum dan Menarik

HAProxy (balancing) + nginx (aplikasi php + caching)

Server web nginx menjalankan php. Ketika nginx sudah ada di sana mungkin juga menangani caching dan pengalihan.

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

HAProxy (balancing) + Varnish (caching) + Tomcat (aplikasi Java)

HAProxy dapat mengalihkan ke Varnish berdasarkan permintaan URI (* .jpg * .css * .js).

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

HAProxy (balancing) + nginx (SSL ke host dan caching) + Webserver (aplikasi)

Webserver tidak berbicara SSL meskipun SEMUA ORANG HARUS BERBICARA SSL ( khususnya tautan HAProxy-WebServer ini dengan informasi pengguna pribadi melalui EC2 ). Menambahkan nginx lokal memungkinkan untuk membawa SSL ke host. Setelah nginx ada di sana mungkin juga melakukan caching dan penulisan ulang URL.

Catatan : Pengalihan port 443: 8080 terjadi tetapi bukan bagian dari fitur. Tidak ada gunanya melakukan redirection port. Penyeimbang beban dapat berbicara langsung ke 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: THE balancer beban

Fitur Utama :

• Load balancing (TCP, HTTP, HTTPS)
• Beberapa algoritma (round robin, ip sumber, header)
• Kegigihan sesi
• Pengakhiran SSL

Alternatif Serupa : nginx (server web multi-fungsi yang dapat dikonfigurasi sebagai penyeimbang beban)
Alternatif Lain : Cloud (Amazon ELB, penyeimbang beban Google), Perangkat Keras (F5, fortinet, citrix netscaler), Other & Worldwide (DNS, anycast, CloudFlare)

Apa yang dilakukan HAProxy dan kapan Anda HARUS menggunakannya?
Kapan pun Anda membutuhkan penyeimbangan beban. HAProxy adalah solusi untuk menuju.

Kecuali jika Anda ingin sangat murah ATAU cepat & kotor ATAU Anda tidak memiliki keterampilan yang tersedia, maka Anda dapat menggunakan ELB: D

Kecuali ketika Anda berada di perbankan / pemerintah / serupa yang membutuhkan untuk menggunakan pusat data Anda sendiri dengan persyaratan keras (infrastruktur khusus, failover yang dapat diandalkan, 2 lapisan firewall, hal-hal audit, SLA untuk membayar x% per menit downtime, semuanya dalam satu) lalu Anda dapat meletakkan 2 F5 di atas rak yang berisi 30 server aplikasi Anda.

Kecuali ketika Anda ingin melewati 100k HTTP (S) [dan multi-situs], maka Anda HARUS memiliki multipel HAProxy dengan lapisan penyeimbangan beban [global] di depannya (cloudflare, DNS, anycast). Secara teoritis, penyeimbang global dapat berbicara langsung dengan server web yang memungkinkan untuk membuang HAProxy. Namun biasanya, Anda HARUS menyimpan HAProxy sebagai titik masuk publik ke pusat data Anda dan menyetel opsi lanjutan untuk menyeimbangkan antar host dan meminimalkan varians.

Opini Pribadi : Sebuah proyek sumber terbuka kecil, berisi, terbuka, seluruhnya didedikasikan untuk SATU TUJUAN YANG BENAR. Di antara konfigurasi termudah (SATU file), perangkat lunak open source yang paling berguna dan paling dapat diandalkan yang pernah saya temui dalam hidup saya.

Nginx: Apache yang tidak payah

Fitur Utama :

• WebServer HTTP atau HTTPS
• Jalankan aplikasi dalam CGI / PHP / beberapa lainnya
• Pengalihan / penulisan ulang URL
• Kontrol akses
• Manipulasi HTTP Headers
• Caching
• Membalikkan Proksi

Alternatif Serupa : Apache, Lighttpd, Tomcat, Gunicorn ...

Apache adalah server web de-facto, juga dikenal sebagai clusterfuck raksasa dari puluhan modul dan ribuan baris httpd.confdi atas arsitektur pemrosesan permintaan yang rusak. nginx mengulang semua itu, dengan modul yang lebih sedikit, (sedikit) konfigurasi lebih sederhana dan arsitektur inti yang lebih baik.

Apa yang dilakukan nginx dan kapan Anda HARUS menggunakannya?
Server web dimaksudkan untuk menjalankan aplikasi. Ketika aplikasi Anda dikembangkan untuk berjalan di nginx, Anda sudah memiliki nginx dan Anda dapat menggunakan semua fitur-fiturnya.

Kecuali ketika aplikasi Anda tidak dimaksudkan untuk berjalan di nginx dan nginx tidak ditemukan di tumpukan Anda (Java shop anyone?) Maka ada sedikit gunanya di nginx. Fitur webservers kemungkinan ada di server web Anda saat ini dan tugas-tugas lain lebih baik ditangani oleh alat khusus yang sesuai (HAProxy / Varnish / CDN).

Kecuali ketika server web / aplikasi Anda kekurangan fitur, sulit dikonfigurasikan dan / atau Anda lebih memilih mati daripada melihatnya (Gunicorn anyone?), Maka Anda dapat meletakkan nginx di depan (yaitu secara lokal pada setiap node) untuk melakukan URL menulis ulang, mengirim 301 pengalihan, memberlakukan kontrol akses, menyediakan enkripsi SSL, dan mengedit tajuk HTTP sambil jalan. [Ini adalah fitur yang diharapkan dari server web]

Varnish: THE caching server

Fitur Utama :

• Caching
• Caching Tingkat Lanjut
• Caching Berbutir Halus
• Caching

Alternatif Serupa : nginx (server web multi-fungsi yang dapat dikonfigurasi sebagai server caching)
Alternatif Lain : CDN (Akamai, Amazon CloudFront, CloudFlare), Perangkat Keras (F5, Fortinet, Citrix Netscaler)

Apa yang dilakukan Varnish dan kapan Anda HARUS menggunakannya?
Itu caching, hanya caching. Biasanya tidak sepadan dengan usaha dan itu buang-buang waktu. Coba CDN sebagai gantinya. Sadarilah bahwa caching adalah hal terakhir yang harus Anda perhatikan ketika menjalankan situs web.

Kecuali ketika Anda menjalankan situs web secara eksklusif tentang gambar atau video maka Anda harus melihat ke dalam CDN secara menyeluruh dan berpikir tentang caching dengan serius.

Kecuali ketika Anda dipaksa untuk menggunakan perangkat keras Anda sendiri di pusat data Anda sendiri (CDN bukan pilihan) dan server web Anda payah dalam mengirimkan file statis (menambahkan lebih banyak server web tidak membantu), maka Varnish adalah pilihan terakhir.

Kecuali ketika Anda memiliki situs dengan konten yang sebagian besar statis-namun-kompleks-yang dihasilkan secara dinamis (lihat paragraf berikut) maka Varnish dapat menghemat banyak daya pemrosesan pada server web Anda.

Caching statis dilebih-lebihkan pada tahun 2016

Caching hampir tanpa konfigurasi, bebas uang, dan bebas waktu. Berlangganan saja ke CloudFlare, atau CloudFront atau Akamai atau MaxCDN. Waktu yang saya perlukan untuk menulis baris ini lebih lama daripada waktu yang dibutuhkan untuk mengatur caching DAN bir yang saya pegang di tangan saya lebih mahal daripada berlangganan CloudFlare median.

Semua layanan ini bekerja di luar kotak untuk statis * .css * .js * .png dan banyak lagi. Bahkan, mereka sebagian besar menghormati Cache-Controlarahan di header HTTP. Langkah pertama caching adalah mengonfigurasi server web Anda untuk mengirim arahan cache yang tepat. Tidak masalah CDN apa, Varnish apa, browser apa yang ada di tengah.

Pertimbangan Kinerja

Varnish dibuat pada saat server web rata-rata tersedak untuk menyajikan gambar kucing di blog. Saat ini satu contoh dari rata-rata server web modern yang digerakkan multi-threaded asinkron yang andal dapat secara andal mengirimkan anak-anak kucing ke seluruh negara. Atas perkenan sendfile().

Saya melakukan beberapa pengujian kinerja cepat untuk proyek terakhir yang saya kerjakan. Contoh tunggal kucing jantan dapat melayani 21.000 hingga 33.000 file statis per detik melalui HTTP (menguji file dari 20B hingga 12kB dengan jumlah koneksi HTTP / klien yang bervariasi). Lalu lintas keluar berkelanjutan adalah di atas 2,4 Gb / s. Produksi hanya akan memiliki antarmuka 1 Gb / s. Tidak dapat melakukan lebih baik daripada perangkat keras, tidak ada gunanya bahkan mencoba Varnish.

Kompleks Caching Mengubah Konten Dinamis

CDN dan server caching biasanya mengabaikan URL dengan parameter seperti ?article=1843, mereka mengabaikan permintaan apa pun dengan cookie sesi atau pengguna terautentikasi, dan mereka mengabaikan sebagian besar tipe MIME termasuk application/jsondari /api/article/1843/info. Ada opsi konfigurasi yang tersedia tetapi biasanya tidak berbutir halus, melainkan "semua atau tidak sama sekali".

Varnish dapat memiliki aturan kompleks khusus (lihat VCL) untuk menentukan apa yang bisa di-cachable dan apa yang tidak. Aturan-aturan ini dapat menembolok konten tertentu dengan URI, tajuk dan cookie sesi pengguna saat ini dan jenis dan konten MIME SEMUA BERSAMA. Itu dapat menghemat banyak daya pemrosesan pada server web untuk beberapa pola beban yang sangat spesifik. Saat itulah Varnish berguna dan MENGAGUMKAN.

Kesimpulan

Perlu beberapa saat bagi saya untuk memahami semua bagian ini, kapan menggunakannya dan bagaimana mereka cocok bersama. Semoga ini bisa membantu Anda.

Itu ternyata cukup lama (6 jam untuk menulis. OMG!: O). Mungkin saya harus memulai blog atau buku tentang itu. Fakta menyenangkan: Tampaknya tidak ada batasan pada panjang jawaban.

Memang benar bahwa 3 alat berbagi fitur umum. Sebagian besar pengaturan baik-baik saja dengan kombinasi 2 di antara 3. Itu tergantung apa tujuan utama mereka. Adalah umum untuk menerima pengorbanan caching jika Anda tahu server aplikasi Anda cepat menggunakan statika (mis: nginx). Adalah umum untuk mengorbankan beberapa fitur penyeimbangan beban jika Anda akan menginstal puluhan atau ratusan server dan tidak peduli untuk mendapatkan yang terbaik dari mereka atau tentang masalah pemecahan masalah. Adalah umum untuk mengorbankan beberapa fitur server web jika Anda bermaksud menjalankan aplikasi terdistribusi dengan banyak komponen di mana-mana. Namun, beberapa orang membangun pertanian yang menarik dengan semuanya.

Anda harus ingat bahwa Anda berbicara tentang 3 produk padat. Secara umum Anda tidak perlu memuat keseimbangan mereka. Jika Anda memerlukan SSL depan, maka nginx terlebih dahulu karena reverse-proxy baik-baik saja. Jika Anda tidak membutuhkannya, maka pernis di bagian depan tidak apa-apa. Kemudian Anda dapat menempatkan haproxy untuk memuat keseimbangan aplikasi Anda. Terkadang, Anda juga ingin beralih ke berbagai server server di haproxy itu sendiri, tergantung pada jenis file atau jalur.

Terkadang Anda harus melindungi dari serangan DDoS yang berat, dan haproxy di depan akan lebih cocok daripada yang lain.

Secara umum, Anda tidak perlu khawatir tentang apa yang harus dilakukan kompromi di antara pilihan Anda. Anda harus memilih cara merakitnya untuk mendapatkan fleksibilitas terbaik untuk kebutuhan Anda sekarang dan yang akan datang. Bahkan jika Anda menumpuk beberapa kali beberapa kali, kadang-kadang mungkin benar tergantung pada kebutuhan Anda.

Semoga ini bisa membantu!

Semua jawaban lain adalah sebelum 2010, karenanya menambahkan perbandingan yang diperbarui.

Nginx

• Server web lengkap, fitur lain juga dapat digunakan. Misalnya: Kompresi HTTP
• Dukungan SSL
• Bobotnya sangat ringan karena Nginx dirancang untuk menjadi ringan sejak awal.
• Dekat kinerja caching Varnish
• Dekat dengan kinerja penyeimbangan beban HAProxy

Pernis

• terbaik untuk skenario caching yang kompleks dan digabungkan dengan aplikasi.
• cacher file statis terbaik
• Tidak Ada Dukungan SSL
• Pemakan memori dan CPU

Haproxy

• loadbalancer terbaik, untuk fitur balancing load edge, sebanding dengan loadbalancers perangkat keras
• SSL didukung sejak 1.5.0
• Lebih sederhana, menjadi proxy tcp tanpa implementasi http, yang membuatnya lebih cepat dan lebih sedikit bug yang rentan.

Jadi metode terbaik tampaknya menerapkan semuanya dalam urutan yang tepat.

Namun, untuk tujuan umum, Nginx adalah yang terbaik karena Anda mendapatkan kinerja di atas rata-rata untuk semua: Caching, Reverse proxying, Load balancing , dengan overhead yang sangat sedikit pada pemanfaatan sumber daya. Dan kemudian Anda memiliki fitur SSL dan server web lengkap.

Varnish memiliki dukungan untuk penyeimbangan beban: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx memiliki dukungan untuk penyeimbangan muatan: http://wiki.nginx.org/NginxHttpUpstreamModule

Saya hanya akan mengkonfigurasi ini dengan pernis + stunnel. Jika saya membutuhkan nginx untuk beberapa alasan lain, saya hanya akan menggunakan nginx + varnish. Anda dapat meminta nginx menerima koneksi SSL dan mem-proksi mereka untuk varnish, kemudian berbicara dengan nginx melalui http.

Beberapa orang mungkin melempar nginx (atau Apache) ke dalam campuran karena ini adalah alat yang agak lebih umum daripada Varnish. Misalnya, jika Anda ingin mengubah konten (misalnya, menggunakan XDV, filter apache, dll) di lapisan proxy Anda akan memerlukan salah satu dari ini, karena Varnish tidak dapat melakukannya dengan sendirinya. Beberapa orang mungkin lebih terbiasa dengan konfigurasi alat-alat ini, jadi lebih mudah untuk menggunakan Varnish sebagai cache sederhana dan melakukan load balancing di layer lain karena mereka sudah terbiasa dengan Apache / nginx / haproxy sebagai load balancer.