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.