OpenResty FAQ | Bagaimana OpenResty Digunakan dalam Praktik

API7.ai

February 10, 2023

OpenResty (NGINX + Lua)

  1. Beberapa Tanya Jawab tentang OpenResty, API Gateway, dan Lua
  2. FAQ OpenResty | Izin Proses Istimewa, Fase Eksekusi, dan Lainnya
  3. FAQ OpenResty | Struktur Jaringan untuk Pengujian, Fitur Terkait SSL, DSL, Alat ab
  4. FAQ OpenResty | Muatan Dinamis, NYI, dan Caching dari Shared Dict

Sampai saat ini, kita telah menyelesaikan bagian terakhir dari OpenResty, Microservices API Gateway. Selamat karena tidak tertinggal, aktif belajar dan berlatih, serta antusias meninggalkan pemikiran Anda.

Saya memilih beberapa pertanyaan yang khas dan menarik di sini untuk dibagikan dengan Anda. Mari kita lihat 5 pertanyaan hari ini.

Pertanyaan 1: Bagaimana OpenResty digunakan dalam praktik

Deskripsi: Kursus ini hampir selesai, dan saya bisa memahaminya, tetapi praktik saya sendiri masih rendah (belum digunakan dalam pekerjaan saya). Karena saya tidak bisa menggunakannya dalam pekerjaan saya. Namun, ini adalah seri artikel yang sangat membantu. Terima kasih kepada penulis karena terus berbagi, dan saya akan memperkenalkannya nanti dalam pekerjaan saya.

Saya ingin berbicara tentang memperkenalkan OpenResty di tempat kerja, topik yang layak dibahas.

OpenResty berbasis pada NGINX dan menambahkan modul C lua-nginx-module serta banyak pustaka lua-resty, sehingga OpenResty adalah alternatif yang baik untuk NGINX, yang merupakan cara termurah untuk mulai menggunakan OpenResty. Tentu saja, ada risiko yang terkait dengan proses penggantian ini, jadi Anda perlu memperhatikan tiga poin berikut.

Pertama, pastikan versi NGINX online sama dengan versi utama OpenResty, seperti OpenResty 1.15.8.1, yang menggunakan NGINX 1.15.8. Jika versi NGINX online saat ini lebih tinggi dari versi terbaru OpenResty, Anda perlu berhati-hati untuk beralih ke OpenResty. Bagaimanapun, OpenResty masih lambat dalam peningkatan dan tertinggal enam bulan hingga satu tahun dari versi utama NGINX. Jika versi NGINX online sama dengan atau lebih rendah dari OpenResty, maka Anda memiliki prasyarat untuk meningkatkan.

Kedua, pengujian. Pengujian adalah salah satu aspek terpenting. Ada sedikit risiko dalam menggunakan OpenResty untuk menggantikan NGINX, tetapi risiko masih ada. Misalnya, apakah ada modul C kustom yang perlu dikompilasi, versi openssl yang diandalkan OpenResty, dan apakah patch yang diberikan OpenResty pada NGINX akan berdampak pada bisnis. Anda perlu mereplikasi sebagian lalu lintas bisnis untuk memverifikasi ini.

Ketiga, pengalihan lalu lintas. Setelah validasi dasar berhasil, Anda masih perlu memverifikasi rilis canary dari lalu lintas nyata secara online. Untuk melakukan rollback dengan cepat, kita dapat membuka beberapa server baru untuk menyebarkan OpenResty alih-alih langsung menggantikan layanan NGINX asli. Jika tidak ada masalah, kita dapat melakukan peningkatan panas pada file biner atau secara bertahap menghapus dan menggantikan NGINX dari LB untuk meningkatkan.

Selain menggantikan NGINX, OpenResty memiliki dua titik masuk mudah lainnya: WAF dan API gateway. Keduanya adalah skenario dengan persyaratan kinerja dan dinamika tinggi dan memiliki proyek open-source yang dapat digunakan langsung, yang telah saya bahas sebagian sebelumnya.

Jika kita terus memperdalam OpenResty pada tingkat bisnis, kita perlu mempertimbangkan lebih banyak faktor di luar teknologi, seperti apakah mudah merekrut insinyur terkait OpenResty, apakah OpenResty dapat diintegrasikan dengan sistem teknis perusahaan yang ada, dll.

Secara umum, ide yang baik adalah memulai dengan menggantikan NGINX dan kemudian perlahan-lahan menyebar untuk menggunakan OpenResty.

Pertanyaan 2: Enkapsulasi database untuk OpenResty

Deskripsi: Menurut artikel sebelumnya, kita harus menggunakan .. (operator penggabungan string) sesedikit mungkin, terutama dalam jalur kode panas. Tetapi ketika menangani akses database, saya perlu membangun pernyataan SQL secara dinamis dengan menyisipkan variabel dalam pernyataan, yang seharusnya menjadi skenario penggunaan umum. Tetapi untuk kebutuhan ini, saya merasa bahwa penggabungan string adalah cara termudah, dan saya tidak dapat memikirkan cara lain yang sederhana dan berkinerja tinggi.

Anda dapat menganalisisnya terlebih dahulu dengan SystemTap atau alat lain yang kami perkenalkan dalam artikel sebelumnya untuk melihat apakah penggabungan pernyataan SQL adalah hambatan sistem. Jika tidak, tidak perlu mengoptimalkannya. Bagaimanapun, optimasi prematur adalah akar dari segala kejahatan.

Jika hambatan memang adalah penggabungan pernyataan SQL, maka kita dapat menggunakan pernyataan prepare database untuk melakukan optimasi atau menggunakan array untuk melakukan penggabungan. Tetapi dukungan lua-resty-mysql untuk prepare berada dalam status TODO, jadi kita hanya dapat menggunakan penggabungan array. Ini juga merupakan masalah umum dengan beberapa pustaka lua-resty, yang mengimplementasikan sebagian besar fungsionalitas dan berjalan normal tetapi tidak diperbarui tepat waktu. Selain pernyataan prepare database, lua-resty-redis tidak memiliki dukungan untuk cluster.

Penggabungan string dan pustaka lua-resty adalah jenis masalah yang ingin diselesaikan OpenResty sepenuhnya dengan DSL - menggunakan teknologi kompilator untuk secara otomatis menghasilkan array untuk menggabungkan string, menyembunyikan detail ini dari pengguna tingkat atas; menggunakan DSL wirelang untuk secara otomatis menghasilkan berbagai pustaka komunikasi jaringan lua-resty, menghilangkan kebutuhan untuk menulis tangan.

Ini terdengar indah, bukan? Tetapi kita harus menghadapi masalah: kode yang dihasilkan secara otomatis tidak ramah bagi pengembang. Jika Anda ingin mempelajari atau memodifikasi kode yang dihasilkan, Anda harus mempelajari teknologi kompilator dan DSL yang mungkin tidak open-source, yang membuat hambatan untuk berpartisipasi dalam komunitas semakin tinggi.

Pertanyaan 3: Kerangka Web OpenResty

Deskripsi: Saya ingin membuat proyek Web dengan OpenResty, tetapi ini menyakitkan terutama karena saya tidak dapat menemukan kerangka yang matang, dan saya perlu membangun banyak roda. Misalnya, masalah operasi database. Saya tidak menemukan pustaka kelas yang dapat membangun pernyataan SQL secara dinamis dan operasi koheren. Jadi saya ingin bertanya kepada penulis, bisakah Anda merekomendasikan kerangka web yang baik?

Dalam repositori awesome-resty, kita dapat melihat bahwa ada kategori khusus untuk kerangka web, ada 20 proyek open-source, tetapi sebagian besar stagnan. Di antaranya, Lapis, lor, dan vanilla adalah tiga proyek yang dapat Anda coba untuk melihat mana yang lebih cocok.

Memang, tanpa kerangka web yang kuat untuk mendukungnya, OpenResty kewalahan ketika menangani proyek besar, yang merupakan salah satu alasan mengapa sedikit orang menggunakan OpenResty untuk sistem bisnis.

Pertanyaan 4: Bagaimana mengubah content-length dalam header respons setelah memodifikasi badan respons?

Deskripsi: Jika saya perlu memodifikasi konten badan respons, saya hanya dapat melakukan perubahan dalam filter badan, tetapi ini akan menyebabkan panjang badan tidak konsisten dengan panjang content-length. Bagaimana saya harus menanganinya?

Dalam kasus ini, kita perlu mengatur header respons panjang konten ke nil dalam fase filter header sebelum filter badan dan tidak mengembalikannya dan mengalirkan output sebagai gantinya.

Berikut adalah contoh kode:

server {
    listen 8080;
    location /test {
            proxy_pass http://api7.ai;
            header_filter_by_lua_block {
                     ngx.header.content_length = nil
            }
            body_filter_by_lua_block {
                    ngx.arg[1] = ngx.arg[1] .. "abc"
            }
     }
}

Seperti yang dapat Anda lihat dari kode ini, dalam fase filter badan, ngx.arg[1] mewakili badan respons. Jika kita menambahkan string abc setelahnya, header respons panjang konten akan tidak akurat, jadi kita dapat menonaktifkannya dalam fase filter header.

Juga, contoh ini menunjukkan bagaimana berbagai fase OpenResty bekerja sama, yang saya harap Anda perhatikan dan pikirkan.

Pertanyaan 5: Jalur paket Lua dalam OpenResty

Deskripsi: lua_package_path tampaknya dikonfigurasi sebagai jalur pencarian untuk dependensi Lua. Untuk content_by_lua_file, saya bereksperimen dan menemukan bahwa itu hanya mencari di bawah prefiks berdasarkan jalur relatif ke file yang disediakan oleh direktif, bukan di bawah lua_package_path. Saya tidak tahu apakah pemahaman saya benar.

lua_package_path digunakan untuk memuat modul Lua, misalnya, ketika kita memanggil require 'cjson', kita akan pergi ke direktori yang ditentukan dalam lua_package_path dan mencari modul cjson. Sebaliknya, content_by_lua_file diikuti oleh jalur file di disk.

location /test {
     content_by_lua_file /path/test.lua;
 }

Jika ini bukan jalur absolut tetapi jalur relatif.

 content_by_lua_file path/test.lua;

Maka akan dilakukan penggabungan menggunakan direktori -p yang ditentukan saat startup OpenResty untuk mendapatkan jalur absolut.

Terakhir, Anda dipersilakan untuk terus menulis pertanyaan Anda di bagian komentar, dan saya akan terus menjawabnya. Saya berharap melalui komunikasi dan tanya jawab, saya dapat membantu Anda mengubah apa yang Anda pelajari menjadi apa yang Anda dapatkan. Anda juga dipersilakan untuk meneruskan artikel ini sehingga kita dapat berkomunikasi dan meningkatkan bersama.