Mengapa Apache APISIX Adalah API Gateway Terbaik?

Saat ini, ponsel digunakan untuk berbagai keperluan, dan berbagai aplikasi tersedia di AppStore termasuk media sosial, utilitas, permainan, gaya hidup, belanja online, dll. Membangun aplikasi ini tidak terlepas dari API. Oleh karena itu, perusahaan yang menyediakan layanan melalui API harus memilih gateway API yang andal untuk memastikan kecepatan, stabilitas, dan keamanan layanan mereka.

Dalam landscape gateway API CNCF, terdapat hampir 20 jenis gateway API (tidak termasuk layanan vendor cloud), termasuk Apache APISIX, Kong, Tyk, dll. Banyak dari mereka mengklaim diri sebagai proyek gateway API open-source paling populer, gateway API generasi berikutnya, tetapi apakah benar demikian?

Dalam artikel ini, kita akan menganalisis beberapa gateway API dalam dimensi popularitas di kalangan pengembang, lisensi open source mereka, kinerja, dan ekosistem secara keseluruhan. Dalam analisis ini, kita akan melihat bagaimana Apache APISIX adalah gateway API generasi berikutnya, yang berkinerja lebih baik daripada rekan-rekannya dalam banyak aspek.

Insinyur Perangkat Lunak Mengetahuinya dengan Baik

Insinyur perangkat lunak adalah pengguna dan pengembang API dan gateway API, sehingga popularitas di kalangan insinyur adalah indikator langsung dari tren. Di bawah ini adalah grafik yang membandingkan total jumlah kontributor GitHub dari empat gateway API: Apache APISIX, Kong, Tyk, dan Gloo.

Dari grafik tersebut, kita dapat melihat bahwa baik Kong maupun Tyk dimulai sekitar tahun 2015, sementara Apache APISIX dan Gloo dimulai lebih baru pada tahun 2019. Yang lebih signifikan, kita juga dapat melihat bahwa Apache APISIX yang termuda memiliki kurva yang paling curam di antara semuanya dan telah mengumpulkan lebih dari 320 kontributor, melampaui Kong yang berada di posisi kedua dengan 57 orang, menjadi proyek gateway API yang memiliki jumlah kontributor terbanyak.

Selain jumlah total kontributor, jumlah kontributor aktif bulanan menunjukkan signifikansi yang lebih besar. Kontributor aktif bulanan untuk Tyk hanya sekitar 5 dan jarang melebihi 10, sementara Kong dan Gloo berfluktuasi antara 10 dan 20. Sementara itu, Apache APISIX memiliki kontributor aktif bulanan di atas 20 secara stabil, dan hampir 40 pada puncaknya, menjadikannya proyek gateway API yang paling aktif.

Di balik empat proyek gateway API open-source ini, ada empat perusahaan komersial yang sesuai. Jadi, indikator lain yang membuat APISIX menonjol adalah rasio jumlah kontributor aktif bulanan versus jumlah karyawan.

Pada tahun 2022, Kong dan Tyk memiliki rasio 4%, dan Gloo memiliki rasio 24%. Sebaliknya, APISIX hampir mencapai 100%. Alasan di baliknya adalah sejak awal ketika perusahaan API7.ai memulai proyek APISIX, mereka telah berusaha keras dalam komunitas open-source dan mendapatkan reputasi di kalangan pengembang.

Lisensi Open Source: Faktor Terpenting dalam Memilih Gateway API Open Source

Sejak MongoDB mengubah lisensi open-source-nya menjadi SSPL (Server Side Public License) pada tahun 2018, perusahaan sekarang harus membuka kode mereka sendiri ketika MongoDB digunakan sebagai layanan terkelola. Akibatnya, perusahaan perlu mempertimbangkan dengan serius lisensi open-source suatu proyek ketika memilih proyek.

Secara permukaan, Apache APISIX, Kong, dan Gloo semuanya menggunakan lisensi Apache License Version 2.0 yang ramah bisnis, dan Tyk menggunakan Mozilla Public License Version 2.0. Namun, jika dilihat lebih dalam, Kong, Gloo, dan Tky semuanya didukung oleh vendor open-source komersial. Mereka dapat mengubah lisensi mereka kapan saja seperti MongoDB, membatasi penggunaan bebas oleh cloud publik atau perusahaan lain, dan memaksa Anda untuk membayar untuk mengakses versi baru.

Tidak ada yang tahu probabilitas perubahan lisensi. Risiko ini, bagaimanapun, seperti pedang Damocles, menggantung di atas pengguna.

Dalam situasi seperti ini, memilih proyek open-source dari Apache Software Foundation (ASF) atau CNCF adalah pilihan terbaik, karena mereka tidak dapat mengubah lisensi proyek. Apache APISIX adalah proyek seperti itu. Ini adalah proyek tingkat atas ASF, yang berarti tidak ada perusahaan komersial yang memiliki kendali absolut atas proyek Apache APISIX, semua kode milik ASF dan lisensi tidak akan diubah. Pengguna perusahaan dapat menggunakannya dengan bebas tanpa khawatir menerima email permintaan dari pengacara dan departemen kepatuhan.

Kinerja Apache APISIX, Kong, dan Gloo

Pertanyaan yang sering diajukan di komunitas: mana yang memiliki kinerja lebih baik, Gloo berbasis Envoy atau APISIX berbasis NGINX? Meskipun kinerja bukan metrik yang paling kritis, itu adalah metrik yang paling langsung. Tabel di bawah ini menunjukkan skor benchmark dari Apache APISIX dan Gloo. QPS dari Apache APISIX adalah 4,6 kali lipat dari Gloo, dan latensi Apache APISIX hanya 7% dari Gloo.

Pilihan NGINX atau Envoy bukanlah faktor utama perbedaan kinerja, tetapi optimasi yang dilakukan APISIX dalam kode sumbernya. Bahkan dibandingkan dengan KONG, yang juga berbasis NGINX, APISIX memiliki keunggulan kinerja yang besar. Grafik di bawah ini diambil dari laporan GigaOm tentang pengujian Edisi Enterprise Kong dan Edisi Enterprise API7 (Anda dapat menghubungi kami untuk data lengkap).

Latensi Kong puluhan bahkan ratusan kali lipat dari API7 (Edisi Enterprise yang dibuat oleh penulis Apache APISIX).

Mengapa APISIX memiliki keunggulan kinerja yang begitu besar? Tidak ada rahasia di depan kode.

Bicara Itu Murah, Tunjukkan Kodenya

Sekarang, mari kita analisis Apache APISIX, Kong, dan Gloo dari sudut pandang teknis. Keunggulan Apache APISIX sebagian besar bergantung pada optimasi dan inovasi kode sumber. Keunggulan teknologi ini tidak selalu tercermin dalam PoC (Proof of Concept) sederhana, tetapi ditunjukkan dalam lingkungan produksi yang lebih kompleks.

Sebelum munculnya proyek APISIX, ada banyak gateway API komersial atau produk gateway API open-source. Produk-produk ini menyimpan data API, informasi routing, sertifikat, dan data konfigurasi dalam database relasional. Keuntungan menyimpan data ini dalam database relasional sangat jelas. Pengguna dapat menggunakan pernyataan SQL untuk melakukan kueri yang fleksibel, dan juga memudahkan pengguna untuk melakukan pencadangan dan pemeliharaan selanjutnya.

Namun, gateway adalah middleware yang menangani semua lalu lintas dari klien. Persyaratan untuk ketersediaan sangat tinggi. Jika gateway API bergantung pada database relasional, itu berarti bahwa begitu database relasional gagal (seperti downtime atau kehilangan data), gateway API juga akan terpengaruh, dan ketersediaan seluruh sistem juga akan menderita.

Untuk mengurangi kerusakan, APISIX menyusun arsitekturnya untuk menghindari kemungkinan downtime dan kehilangan data. APISIX menggunakan etcd untuk menyimpan data konfigurasi alih-alih database relasional, keuntungan dari melakukan ini adalah sebagai berikut:

1. Lebih selaras dengan arsitektur cloud-native
2. Representasi yang lebih baik dari tipe data yang dibutuhkan untuk gateway API
3. Akan memiliki ketersediaan yang lebih tinggi
4. Perubahan dapat diberitahukan pada tingkat sub-milidetik

Setelah menggunakan etcd untuk menyimpan data konfigurasi, pengguna hanya perlu memantau pembaruan etcd untuk perubahan data. APISIX akan dapat memperoleh konfigurasi terbaru dalam hitungan milidetik, mencapai efek real-time. Namun, jika kita melakukan polling dari database, mungkin membutuhkan 5-10 detik untuk memperoleh informasi konfigurasi terbaru. Oleh karena itu, menggunakan etcd sebagai skema penyimpanan tidak hanya membuat APISIX lebih cloud-native tetapi juga memiliki ketersediaan yang lebih tinggi.

Algoritma Pencocokan Rute Berkinerja Tinggi

Untuk memproses permintaan, Gateway API perlu mencocokkan ekspresi target dengan informasi host, URI, metode HTTP, dan informasi lainnya dari setiap permintaan. Dengan demikian, algoritma pencocokan yang efisien sangat penting. Algoritma berbasis hash memiliki kinerja yang baik, tetapi tidak dapat mencapai pencocokan fuzzy. Ekspresi reguler dapat melakukan pencocokan fuzzy, tetapi kinerjanya tidak begitu baik. Solusi Apache APISIX adalah menggunakan pohon, struktur data pencarian yang efisien yang mendukung pencocokan fuzzy. Lebih tepatnya, Apache APISIX menggunakan radix tree (pohon prefiks terkompresi), struktur data yang hanya mengompresi node tengah dengan satu anak. Di antara semua produk gateway API yang dikenal, Apache APISIX adalah yang pertama menerapkan radix tree dalam pencocokan rute dan mendukung skenario di mana satu prefiks dapat mencocokkan beberapa rute. Untuk detail implementasi, lihat lua-resty-radixtree.

Saat mencocokkan permintaan, algoritma dengan radix tree akan mencocokkannya secara progresif, dengan kompleksitas O(K) (K adalah panjang URI dalam rute, dan itu independen dari jumlah API). Algoritma ini sangat cocok dalam skenario ketika ada sejumlah besar rute, seperti di cloud publik atau CDN. Ini juga tidak memiliki masalah dalam menangani sejumlah besar rute yang meningkat dengan cepat.

Algoritma Pencocokan IP Berkinerja Tinggi

Alamat IP memiliki dua notasi: notasi IP standar dan notasi CIDR, mengambil IPv4 32-bit sebagai contoh:

• Notasi IP standar: 192.168.1.1
• Notasi CIDR: 192.168.1.1/8

Pencocokan IP dan pencocokan rute Apache APISIX menggunakan algoritma yang berbeda. Ambil contoh IP 192.168.1.1, karena rentang setiap segmen IP adalah 0 hingga 255, kita dapat menganggap bahwa alamat IP terdiri dari empat angka integer 16-bit, dan panjang IP tetap. Dengan demikian, kita dapat menggunakan algoritma yang lebih efisien untuk menyelesaikan pencocokan.

Asumsikan ada perpustakaan IP yang berisi 500 catatan IPv4, APISIX akan menyimpan 500 catatan IPv4 tersebut dalam tabel hash, dan menggunakan tabel hash untuk pencocokan IP. Kompleksitas waktu adalah O(1). Gateway API lainnya menyelesaikan pencocokan IP melalui iterasi daftar dan setiap permintaan yang dikirim ke gateway mungkin diiterasi hingga 500 kali. Oleh karena itu, algoritma pencocokan IP presisi tinggi APISIX sangat meningkatkan efisiensi skenario yang membutuhkan pencocokan daftar izin dan daftar blokir IP yang besar (seperti WAF).

Penyempurnaan Rute

Gateway API mencocokkan aturan yang telah ditentukan dengan berbagai informasi permintaan, seperti informasi host, URI, parameter query URI, parameter path URI, metode HTTP, header permintaan, dll. Informasi ini didukung oleh sebagian besar gateway API. Namun, Apache APISIX mendukung lebih banyak data selain ini untuk menyelesaikan kasus yang lebih kompleks.

Pertama, Apache APISIX mendukung variabel bawaan NGINX, yang berarti kita dapat menggunakan puluhan variabel bawaan NGINX sebagai parameter pencocokan, termasuk uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name.

Untuk daftar variabel bawaan NGINX, lihat NGINX Variables.

Kedua, Apache APISIX mendukung ekspresi kondisional sebagai aturan pencocokan, dan strukturnya adalah [var, operator, val], ...]], di mana:

• Nilai var dapat berupa variabel bawaan NGINX.
• operator mendukung sama dengan, lebih besar dari, kurang dari, ekspresi reguler, mengandung, dll.

Asumsikan ekspresinya adalah ["arg_name", "==", "json"], itu berarti apakah ada nilai parameter name yang sama dengan json dalam parameter query URI dari permintaan saat ini. Apache APISIX mengimplementasikan fitur ini melalui perpustakaan lua-resty-expr. Untuk detailnya, silakan merujuk ke lua-resty-expr. Fitur ini memberikan banyak fleksibilitas kepada pengguna dan sangat dapat diperluas.

Selain itu, Apache APISIX memungkinkan pengguna untuk mengatur ttl (time to live) rute.

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

Kode di atas berarti bahwa APISIX akan secara otomatis menghapus konfigurasi routing setelah 60 detik, yang akan diperlukan untuk beberapa skenario verifikasi sementara, seperti rilis canary. Ini juga sangat nyaman untuk pemisahan lalu lintas online, fitur yang tidak dimiliki oleh produk gateway lainnya.

Terakhir, Apache APISIX mendukung fungsi filter yang disesuaikan, seseorang dapat menulis fungsi Lua kustom dalam parameter filter_func, misalnya:

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

Parameter input dari filter_func adalah vars, dan variabel NGINX dapat diperoleh dari vars, dan kemudian logika penyaringan dapat disesuaikan.

Dukungan untuk Plugin Multi-Bahasa

Pengguna sering perlu menyesuaikan beberapa pengembangan dan integrasi sistem gateway API untuk skenario tertentu.

APISIX saat ini mendukung lebih dari 80 plugin, tetapi masih sulit untuk mencakup semua skenario pengguna. Dengan demikian, sebagian besar perusahaan akan mengembangkan plugin yang disesuaikan untuk bisnis tertentu, mengintegrasikan lebih banyak protokol dan sistem melalui gateway, dan mencapai manajemen terpadu di lapisan gateway.

Dalam versi sebelumnya dari APISIX, pengembang hanya dapat menggunakan Lua untuk mengembangkan plugin. Meskipun plugin yang dikembangkan dalam bahasa komputasi asli memiliki kinerja yang sangat tinggi, mempelajari Lua, bahasa pengembangan baru, membutuhkan waktu dan biaya pembelajaran.

Menanggapi situasi ini, APISIX menyediakan dua solusi.

Solusi pertama adalah mendukung lebih banyak bahasa pemrograman utama (seperti Java, Python, Go, dll.) melalui Plugin Runner. Menggunakan Plugin Runner, insinyur back-end dapat berkomunikasi melalui RPC lokal untuk mengembangkan plugin APISIX menggunakan bahasa pemrograman yang mereka kuasai. Keuntungan dari ini adalah mengurangi biaya pengembangan dan meningkatkan efisiensi pengembangan. Kerugiannya adalah kehilangan kinerja. Jadi, apakah ada cara untuk mencapai kinerja yang mendekati asli Lua menggunakan bahasa tingkat tinggi yang familiar dengan pengembang?

Solusi kedua adalah menggunakan Wasm untuk mengembangkan plugin, seperti yang ditunjukkan pada bagian kiri gambar di atas. Wasm (WebAssembly) pertama kali digunakan sebagai teknologi baru yang berjalan di browser, tetapi sekarang juga mulai menunjukkan keunggulannya di sisi server. Kami menyematkan Wasm ke dalam APISIX, dan pengguna dapat menggunakan Wasm untuk mengkompilasi bytecode Wasm untuk berjalan di APISIX. Untuk memanfaatkan Wasm, kami mengembangkan plugin Wasm di mana pengguna dapat mengembangkan plugin APISIX yang mendekati asli menggunakan bahasa pemrograman tingkat tinggi.

Hasilnya, pengguna dapat menggunakan Lua, Go, Java, Python, Node.js, dan Wasm untuk menulis plugin kustom di APISIX. Dengan membuat pengembangan menjadi mudah, itu membuka pintu untuk pengembangan plugin APISIX.

Kesimpulan

Dalam artikel ini, kami menganalisis dan membandingkan produk gateway API dari berbagai perspektif seperti insinyur perangkat lunak, protokol open source, evaluasi kinerja, teknologi, dan ekosistem. Kami dapat melihat bahwa Apache APISIX unggul dalam banyak aspek, menjadi pelopor dalam jaringan API.

Apache APISIX bukan hanya gateway API yang dapat menangani lalu lintas utara-selatan, tetapi juga memiliki produk open source seperti APISIX Ingress Controller dan Service Mesh.

Ini juga menyediakan produk tingkat perusahaan dan produk SaaS berbasis APISIX.

Coba Apache APISIX dan produk Enterprise API7 hari ini!