xRPC Akan Dirilis, Dapatkan Detail Lebih Lanjut Tentang Ekosistem APISIX
API7.ai
January 21, 2021
Seiring dengan semakin kompleks dan beragamnya skenario dan kebutuhan bisnis, semakin banyak standar dan protokol yang bermunculan. Apache APISIX, sebagai proyek open source terkemuka dari Apache Foundation, telah aktif berpartisipasi dan mendorong perluasan aspek-aspek ekologi terkait.
Dalam artikel ini, kami akan membawa Anda contoh kerangka kerja xRPC yang akan datang dari Apache APISIX dan plugin multibahasa dari dua perspektif: proxy multi-protokol dan dukungan multibahasa.
Proxy Multi-Protokol
Di Apache APISIX, setiap permintaan sesuai dengan objek Route. Saat ini ada dua skenario proxy utama untuk Apache APISIX.
Yang pertama adalah proxy protokol HTTP, yang saat ini merupakan proxy permintaan yang paling umum digunakan di APISIX. Berdasarkan proxy protokol HTTP, Apache APISIX saat ini telah mengimplementasikan puluhan kemampuan pengelolaan lalu lintas, seperti kontrol aliran yang sangat detail, keamanan, dan observabilitas.
Yang kedua adalah proxy protokol dinamis dan load balancing berbasis TCP dan UDP, yang menyediakan kemampuan penerimaan lalu lintas paling dasar dan kemampuan pencatatan log tingkat tautan. Model proxy ini dapat memproksi permintaan berbasis protokol TCP/UDP apa pun seperti MySQL, Redis, Mongo, atau DNS. Namun, karena ini adalah proxy berbasis TCP/UDP tanpa protokol lapisan aplikasi atas, hanya dapat mendapatkan beberapa informasi dasar tentang kuadran, sehingga sedikit lebih lemah dalam hal skalabilitas.
Mengapa xRPC
Karena keterbatasan Stream Route dalam hal proxy protokol, dan keinginan kami untuk mendukung lebih banyak protokol lapisan aplikasi di APISIX untuk melayani lebih banyak pengguna dan skenario aplikasi, kerangka kerja xRPC pun lahir.
Kerangka kerja xRPC memudahkan untuk memperluas kemampuan protokol, baik protokol data spesifik maupun pribadi, dengan granularitas yang tepat dan kontrol tingkat 7 yang lebih tinggi mirip dengan proxy protokol HTTP, seperti observabilitas tingkat permintaan, kontrol akses lanjutan, dan kebijakan proxy.
Apa itu xRPC
xRPC secara harfiah berarti bahwa X adalah representasi abstrak dari sumber daya protokol. Dan RPC adalah apa yang kami anggap semua sumber daya yang melewati gateway sebagai proses pengiriman, yaitu ini adalah kerangka kerja ekstensi protokol. Jadi dalam hal penempatan, xRPC adalah kerangka kerja dasar daripada implementasi dari protokol tertentu.
Seperti yang dapat Anda lihat dari arsitektur di atas, xRPC adalah kerangka kerja berbasis ekstensi APISIX Core. Di atas kerangka kerja ini, pengguna dapat mengimplementasikan berbagai protokol lapisan aplikasi, seperti Redis, MySQL, Mongo, dan Postgres. Di atas berbagai protokol, Anda dapat mengabstraksikan beberapa faktor umum dan mengimplementasikan kemampuan plugin terkait sehingga berbagai protokol dapat berbagi kemampuan ini.
Jadi peran utama xRPC dapat disimpulkan sebagai: menyediakan akses ke protokol lapisan aplikasi yang terstandarisasi, mendukung berbagi kemampuan lintas protokol, dan memungkinkan pengguna mendapatkan kemampuan untuk memperluas protokol kustom.
Contoh Skenario Aplikasi
Dengan kerangka kerja protokol xRPC yang ada, skenario apa yang dapat diatasi? Berikut adalah beberapa contoh.
- Contoh 1: Redis tidak mendukung TLS di versi sebelumnya. Jika ada beberapa versi Redis di sistem kami, dan kami tidak dapat meningkatkan Redis di produksi karena beberapa alasan, tetapi kami perlu menambahkan kemampuan TLS. Dalam kasus ini, kami dapat menggunakan Protokol Redis berbasis xPRC untuk menyelesaikan situasi di atas.
- Contoh 2: Ketika kami ingin membatasi frekuensi IP atau pemanggil tertentu dan ingin memvisualisasikan frekuensi setiap sumber panggilan, yang tidak didukung oleh Redis. Ini dapat diselesaikan dengan sempurna dengan menggunakan Protokol Redis, yang diperluas oleh xRPC.
- Contoh 3: Jika Anda ingin menggunakan MySQL untuk sementara mengaktifkan fungsi kueri lambat, Anda hanya perlu mengakses MySQL Protocol dan mengonfigurasi kebijakan terkait di APISIX, yang menghemat Anda dari langkah yang membosankan untuk masuk ke mesin instance satu per satu.
Tentu saja, ada banyak skenario aplikasi serupa, dan kami berharap setelah rilis fitur ini, Anda dapat mengalami dan mempraktikkan lebih banyak dalam aplikasi aktual. Proses pemanggilan xPRC ditunjukkan dalam diagram berikut.
Setelah layanan upstream diambil alih oleh Apache APISIX, berbagai layanan aplikasi upstream dapat dikelola secara terpadu. Fungsi seperti pencatatan log, pemantauan, keamanan, dan pemecahan masalah semuanya dapat dilakukan melalui serangkaian kebijakan yang terstandarisasi.
Fase Implementasi yang Direncanakan
Desain saat ini dari kerangka kerja Apache APISIX xRPC awalnya dibagi menjadi 5 fase.
- Fase 1: Membaca data dan dekode protokol.
- Fase 2: Fase Akses. Menyediakan fungsi akses plugin, yang dapat mewujudkan skenario kebutuhan keamanan, kontrol aliran, dan akses.
- Fase 3: Proxy penerusan data dan load balancing. Menyediakan dukungan akses untuk kebijakan dan algoritma load balancing kustom.
- Fase 4: Mengirim data dan enkode protokol.
- Fase 5: Fase Pencatatan Log. Menyediakan akses plugin untuk mewujudkan skenario kebutuhan pencatatan log dan logging.
Ekologi Multibahasa
Untuk memenuhi basis bahasa komputasi yang semakin kaya dan besar, menciptakan dukungan kode untuk lingkungan multibahasa telah menjadi ambang pertama untuk menghadapi perkembangan teknologi di masa depan. Apache APISIX juga telah melakukan banyak eksplorasi dan praktik di jalan pengembangan multibahasa.
Misalnya, baru-baru ini telah mengimplementasikan dukungan untuk WebAssembly. Untuk detail dan fitur, silakan merujuk ke artikel "Apache APISIX Merangkul Ekologi WASM". Tentu saja, dukungan untuk WASM di Apache APISIX masih eksperimental, dan kami akan terus meningkatkan dukungan untuk WASM di masa depan. Jika Anda tertarik dengan proyek ini, silakan berkontribusi pada proyek wasm-nginx-module.
Sementara itu, Apache APISIX sudah mendukung beberapa bahasa pengembangan melalui "xPluginRunner Multilanguage Plugin Runtime" sebelum dukungan WASM diimplementasikan. Artinya, saat mengembangkan plugin APISIX, pengguna dapat menulis dan memperluas plugin APISIX tidak hanya dengan kode Lua, yang secara native didukung oleh APISIX, tetapi juga dengan bahasa yang mereka kenal, seperti Go, Java, dan Python.
xPluginRunner
Implementasi xPluginRunner ditunjukkan pada gambar di atas. Seluruh proses komunikasi adalah "sebelum" dan "setelah" eksekusi plugin bawaan, APISIX akan memulai permintaan RPC lokal ke runtime plugin dari setiap bahasa. Di runner plugin, komputasi dan pemrosesan kebijakan dalam setiap plugin diimplementasikan, dan hasilnya akhirnya direspons ke APISIX untuk pengambilan keputusan selanjutnya berdasarkan hasil respons.
xPluginRunner berfungsi sebagai jembatan komunikasi dengan Apache APISIX, dan terutama mengimplementasikan parsing protokol data pribadi dan enkapsulasi serta dekapsulasi pesan RPC.
Saat ini, solusi Apache APISIX xPluginRunner berada dalam tahap yang relatif stabil, dan kami tahu dari umpan balik komunitas bahwa beberapa perusahaan telah mulai mencobanya di lingkungan produksi. Jika Anda tertarik dengan proyek ini, Anda juga dipersilakan untuk berpartisipasi dalam berbagai proyek plugin bahasa pengembangan.
Akhirnya, kami akan menunjukkan kepada Anda cara mengembangkan plugin APISIX berdasarkan Java Plugin Runner dengan contoh sederhana Java.
Contoh Java Plugin Runner
Pertama-tama, saat mengembangkan plugin, kita perlu mengimplementasikan Interface dari PluginFilter. Metode name dalam Interface terutama digunakan untuk mengidentifikasi dan mengekstrak nama plugin, dan metode filter digunakan untuk memfilter permintaan (yaitu, mengeksekusi logika tubuh plugin).
Satu poin tambahan yang perlu diperhatikan adalah bahwa parameter request dan response yang muncul dalam kode di atas memiliki logika tetap di Runner (semua Runner berlaku):
- Jika Anda ingin permintaan terus diteruskan dan hanya melakukan beberapa pengaturan kebijakan (seperti menulis ulang parameter permintaan, header, dll.), Anda cukup memanipulasi objek
request. - Jika Anda ingin menghentikan permintaan, Anda dapat melakukannya dengan objek
response(misalnya, mengatur body respons, header respons, kode status, dll.).
APISIX akan menghentikan permintaan saat ini segera setelah merasakan bahwa objek response di Runner telah dimanipulasi.
Setelah pengembangan plugin selesai, saatnya untuk mempraktikkan aplikasi di APISIX.
Pertama, kompilasi Runner dan plugin dalam proyek menjadi paket jar dan konfigurasikan jalur absolut paket jar ke file konfigurasi utama APISIX dengan cara berikut.
Akhirnya, restart Apache APISIX dan Anda siap untuk sesi konfigurasi routing dan plugin serta validasi permintaan.
Ringkasan
Artikel ini membawa Anda rilis yang akan datang dari kerangka kerja xRPC untuk Apache APISIX dan detail terkait, serta demonstrasi rinci dari Apache APISIX dalam dukungan pengembangan multibahasa.
Artikel ini juga menunjukkan detail dukungan pengembangan multibahasa dari Apache APISIX. Ini menunjukkan upaya berorientasi ekologi dari Apache APISIX dari kedua perspektif proxy multi-protokol dan dukungan multibahasa.
Jangan ragu untuk memulai diskusi di GitHub Discussions atau berkomunikasi melalui mailing list.