Variabel nginx dengan njs: sederhana, tidak menyakitkan dan melalui JavaScript

njs adalah penerjemah JavaScript di server web yang ringan yang dengannya Anda dapat membuat variabel nginx baru dan meminta penangan tahap. Apa manfaatnya? Apa yang tidak bisa? Dan mengapa mereka melakukannya? Pertanyaan-pertanyaan ini dan lainnya akan dijawab oleh Dmitry Volyntsev ( xeioex ), pengembang nginx dan pengembang utama interpreter njs.



- Dmitry, mengapa Anda perlu skrip di konfigurasi nginx?


- Alasan pertama adalah if direktif. Orang-orang yang melihatnya untuk pertama kali berpikir bahwa mereka dapat digunakan secara imperatif. Sebenarnya tidak demikian - konfigurasi nginx bersifat deklaratif. Pada contoh di bawah ini, Anda mungkin berpikir bahwa respons akan memiliki dua header: X-First dan X-Second. Tetapi hanya header kedua yang akan mendapatkan jawabannya, karena nginx sudah diatur: jika kita menulis dua jika arahan, maka yang terakhir akan dipilih.

 location /only-one-if { set $true 1; if ($true) { add_header X-First 1; } if ($true) { add_header X-Second 2; } 

Alasan kedua adalah apa yang nginx lakukan sekarang. Sebelumnya, ini digunakan untuk men-cache statika dan permintaan, serta load balancing - satu set proxy klasik. Proliferasi layanan-layanan mikro telah mengikis lingkup nginx. Jika pengaturan konfigurasi sebelumnya berakhir dengan sepasang lokasi pada beberapa backend dalam beberapa bahasa, maka dengan arsitektur layanan mikro kami memiliki lebih banyak bagian yang bergerak. Backend telah menjadi banyak komponen kecil. Logika otorisasi, misalnya, perlu diduplikasi pada setiap layanan-mikro atau diambil, misalnya, di frontend. Untuk menerapkan otorisasi tingkat lanjut, tidak selalu cukup mekanisme solusi bawaan di nginx.

Ketiga, dalam nginx banyak arahan menerima ekspresi yang dihitung secara dinamis, misalnya:

 proxy cache bypass $cookie_nocache $arg_nocache; 

Anda dapat menggabungkan variabel satu sama lain atau dengan string literal. Tapi ini tidak cukup, dan saya ingin memiliki alat yang lebih kuat, misalnya, untuk menghitung hash, untuk bekerja dengan data numerik, untuk digunakan pada huruf besar dan kecil.

Untuk memperluas semua hambatan di nginx, Anda harus mengembangkan sintaks Anda sendiri atau menggunakan sesuatu yang sudah jadi. Kami sampai pada kesimpulan bahwa yang terbaik adalah mengambil bahasa pemrograman scripting yang ada. Dengan demikian, pengembang tidak perlu mempelajari bahasa baru, yang juga akan menghemat waktu dan menurunkan ambang entri. Kami memilih JavaScript.

- Dan mengapa JavaScript?


- Kami memilih JavaScript karena beberapa alasan:

  • Dialek modern, yang bagus untuk pengembang yang beralih dari bahasa lain.
  • Gaya seperti C. Ini penting karena konfigurasi nginx menggunakan kurung kurawal, dan di masa depan kami ingin menambahkan kemampuan untuk menulis kode JS tepat di dalam konfigurasi. Kawat gigi akan membantu kita dengan ini. Di Lua, misalnya, peran kawat gigi keriting dilakukan dengan mulai dan akhir - ini tidak nyaman.
  • Model JavaScript sangat cocok dengan arsitektur nginx.

"Jadi Lua juga dipertimbangkan?" Apakah karena awal dan akhir?


- Sudah ada proyek pihak ketiga yang sudah jadi, OpenResty. Jika Anda tidak masuk ke detail, maka ini pada dasarnya adalah nginx + Lua, tetapi memiliki arsitektur yang berlawanan dengan nginx. Kami ingin menghindari persimpangan dengan ekosistem ini. Selain itu, ada beberapa alasan lain:

  • Lua memiliki sintaksis seperti pascal.
  • Array diindeks dari 1.
  • Lua masih merupakan bahasa pemrograman khusus.

- Bagaimana njs dibandingkan dengan pesaing?


- Kami memberi peringkat njs dibandingkan dengan mesin yang terkenal - V8 dan SpiderMonkey. Mereka tidak efektif untuk tugas-tugas di dalam nginx, karena mereka dipertajam oleh browser dan sangat kelas berat, dan nginx membutuhkan kecepatan tinggi. Selain itu, kedua mesin ini berkembang pesat, API mereka tidak stabil. Akhirnya, njs dapat diintegrasikan secara lebih efisien ke dalam nginx:


Jumlah konteks yang dibuat per detik

- Standar apa yang didukung njs?


- Saat ini, hampir semua elemen dasar dari spesifikasi ECMAScript 5.1 diimplementasikan dengan beberapa elemen berselang dari spesifikasi 6 dan 7. Yaitu, objek standar seperti Objek, Array, String, Nomor, Tanggal, RegExp, JSON. Penutupan, fungsi anonim, dan bekerja dengan pengecualian didukung sepenuhnya.

Kami tidak menetapkan sebagai tujuan utama kami kepatuhan penuh dengan spesifikasi bahasa. Jadi saat ini tidak ada dukungan untuk eval () , dan sejauh ini kami tidak berencana untuk menambahkannya. Tetapi kami berencana untuk menambahkan dukungan untuk const dan membiarkan kata kunci, serta fungsi panah.


Apa yang mampu dan apa yang tidak dapat dilakukan saat ini

Penting untuk menyebutkan satu hal lagi: kurangnya pengumpulan sampah. Sebagian besar bahasa modern secara mandiri memonitor masa pakai objek. Jika objek tidak lagi digunakan, itu secara otomatis dihapus. Anda tidak dapat melakukannya tanpa mekanisme ini, tetapi biasanya Anda harus mengorbankan sesuatu untuk itu - pekerjaan program melambat atau bahkan berhenti. Dalam njs, memori tidak dibebaskan sampai objek permintaan dibebaskan.

Pendekatan ini memiliki pro dan kontra. Kerugian utama adalah tidak memungkinkan Anda untuk bekerja secara efektif dengan permintaan panjang. Karenanya, di masa mendatang kami berencana untuk menambahkan pengumpulan sampah sebagai opsi untuk mengaktifkannya sesuai kebutuhan.

- Apa yang bukan?


- Sebelum menjawab pertanyaan ini, saya ingin mengulangi sekali lagi bahwa tugas utama njs adalah untuk mengembangkan kemampuan untuk konfigurasi fleksibel nginx dan menyelesaikan tugas-tugas di sisi proxy.

Sekarang pertanyaannya sendiri. Apa yang harus dipertimbangkan terlebih dahulu?
  • njs bukan pengganti untuk Node.js.
  • Bundel nginx + njs bukan server aplikasi.
  • njs tidak sepenuhnya mengimplementasikan standar ECMAScript, karena tidak ada dukungan untuk eval ().



Jika topik ini sangat relevan untuk Anda dan Anda membutuhkan lebih banyak detail, kami sarankan Anda menonton rekaman video laporan Dmitry Volintsev di HighLoad ++ Siberia 2018, tempat ia mengungkapkannya dari semua sisi.


Kami juga mengundang semua pro untuk mengirimkan laporan mereka ke konferensi HighLoad ++ 2018 November, yang akan diadakan di Skolkovo pada 8 dan 9 November. Jika Anda memiliki pengalaman yang unik dan menarik dan Anda siap untuk membagikannya - daftar sebelum 1 September dan isi formulir .

Jika Anda takut untuk berbicara di depan umum, kami memiliki apa yang disebut sekolah pembicara , di mana kami membantu memompa keterampilan ini secara gratis.

Source: https://habr.com/ru/post/id420465/


All Articles