Mengapa Anda Memilih Apache APISIX Daripada NGINX atau Kong?

API gateway adalah komponen infrastruktur penting di era cloud-native. Ada dua kriteria umum untuk mengevaluasi sebuah API gateway: seberapa dinamisnya, dan seberapa matang observabilitasnya. Banyak perusahaan sebelumnya menggunakan Nginx atau Kong sebagai API gateway mereka, tetapi kemudian beralih ke Apache APISIX. Sebagai API gateway yang lahir untuk era cloud-native, Apache APISIX memang menyelesaikan banyak masalah bagi bisnis dalam berbagai dimensi. Sekarang Anda mungkin bertanya-tanya, mengapa?

Keterbatasan NGINX dan Kong

Di era layanan monolitik, NGINX dapat menangani sebagian besar skenario. Namun di era cloud-native, NGINX memiliki dua kekurangan karena arsitekturnya:

NGINX tidak mendukung manajemen kluster. Hampir setiap perusahaan memiliki sistem manajemen konfigurasi NGINX sendiri. Meskipun sistemnya serupa, tidak ada solusi yang terpadu.
NGINX tidak mendukung pemuatan ulang konfigurasi secara panas. Jika pengguna mengubah konfigurasi NGINX, maka perlu memuat ulang NGINX. Selain itu, di Kubernetes, layanan akan sering berubah. Jadi jika NGINX digunakan untuk menangani lalu lintas, Anda harus sering memulai ulang layanan, yang tidak dapat diterima oleh perusahaan.

Kong menyelesaikan kekurangan NGINX tetapi membawa keterbatasan baru:

Kong perlu bergantung pada database PostgreSQL atau Cassandra, yang membuat arsitektur Kong sangat besar dan akan membawa keterbatasan ketersediaan tinggi bagi perusahaan. Jika database gagal, seluruh API Gateway akan gagal.
Routing Kong menggunakan pencarian traversal. Ketika ada lebih dari seribu rute di gateway, kinerjanya akan turun drastis.

APISIX menyelesaikan semua keterbatasan di atas dan menjadi API gateway terbaik di era cloud-native.

Keunggulan Apache APISIX

Arsitektur yang dirancang dengan baik

Pertama, Apache APISIX memiliki arsitektur yang sangat baik. Cloud-native, sebagai tren teknologi saat ini, akan mengubah arsitektur teknis perusahaan tradisional. Banyak aplikasi sedang bermigrasi ke microservices dan kontainerisasi. APISIX telah mengikuti tren teknologi sejak awal:

Seperti yang ditunjukkan pada gambar di atas, kiri dan kanan adalah Data Plane dan Control Plane dari APISIX:

Data Plane: Berdasarkan library jaringan NGINX (tanpa menggunakan pencocokan rute NGINX, konfigurasi statis, dan modul C), menggunakan Lua dan NGINX untuk mengontrol lalu lintas permintaan secara dinamis;
Control Plane: Administrator dapat mengoperasikan etcd melalui RESTful API bawaan. Dengan bantuan mekanisme Watch etcd, APISIX dapat menyinkronkan konfigurasi ke setiap node dalam hitungan milidetik.

Untuk memperbarui data, Kong menggunakan metode polling database; mungkin membutuhkan 5-10 detik untuk mendapatkan konfigurasi terbaru, sementara APISIX mencapai hal yang sama dengan memantau perubahan konfigurasi etcd, yang dapat mengontrol waktu dalam hitungan milidetik.

Karena APISIX dan etcd mendukung penyebaran multi-instance, tidak ada titik kegagalan tunggal.

Ekosistem yang kaya

Gambar berikut menunjukkan peta ekosistem APISIX. Dari gambar ini, kita dapat melihat bahwa APISIX mendukung protokol L7 termasuk HTTP(S), HTTP2, Dubbo, protokol IoT MQTT, dll. Selain itu, APISIX mendukung protokol L4 seperti TCP/UDP.

Bagian kanan gambar berisi beberapa layanan open-source atau SaaS, seperti Apache SkyWalking, Prometheus, HashiCorp Vault, dll. Di bagian bawah gambar adalah lingkungan sistem operasi, vendor cloud, dan lingkungan perangkat keras yang lebih umum. Sebagai perangkat lunak open-source, APISIX juga dapat dijalankan di server ARM64.

APISIX tidak hanya mendukung banyak protokol dan sistem operasi, tetapi juga mendukung plugin pemrograman multi-bahasa. Ketika pertama kali diluncurkan, APISIX hanya mendukung penggunaan bahasa Lua untuk menulis plugin. Dalam hal ini, pengembang perlu menguasai teknologi terkait Lua dan NGINX. Namun, Lua dan NGINX adalah teknologi yang relatif niche dan hanya dikenal oleh sedikit pengembang. Oleh karena itu, kami kemudian mengaktifkan pengembangan plugin di APISIX dengan berbagai bahasa, dan telah secara resmi mendukung bahasa seperti Java, Golang, Node.js, dan Python.

Komunitas yang aktif

Gambar di bawah ini adalah kurva pertumbuhan kontributor, di mana sumbu horizontal mewakili garis waktu, dan sumbu vertikal mewakili total jumlah kontributor. Kita dapat melihat bahwa dua proyek, Apache APISIX dan Kong, relatif lebih aktif. Apache APISIX telah mempertahankan tingkat pertumbuhan yang sangat baik sejak hari pertama dan tumbuh dengan cepat dengan kecepatan hampir dua kali lipat dari Kong. Hingga Juli 2022, jumlah kontributor APISIX telah melampaui Kong, yang menunjukkan popularitas APISIX. Tentu saja, ada banyak cara lain untuk mengevaluasi aktivitas sebuah proyek, seperti masalah aktif bulanan, total jumlah PR, dll. Kabar baiknya adalah bahwa APISIX juga tidak tertandingi dalam hal-hal ini.

Infrastruktur proxy yang terpadu

Dari gambar di bawah ini, saya yakin Anda sudah memahami tujuan APISIX: menyatukan infrastruktur proxy.

Karena inti dari APISIX adalah layanan proxy berkinerja tinggi, ia tidak mengikat properti lingkungan apa pun. Oleh karena itu, ketika berevolusi menjadi produk seperti Ingress dan Service Mesh, Anda tidak perlu mengubah struktur internal APISIX. Berikut ini akan memperkenalkan kepada Anda langkah demi langkah bagaimana APISIX mendukung skenario ini.

Load balance dan API gateway

Pertama adalah untuk skenario LB dan API gateway tradisional. Karena APISIX diimplementasikan berdasarkan NGINX + LuaJIT, ia memiliki fitur kinerja tinggi dan keamanan, dan mendukung pemuatan dinamis sertifikat SSL, optimasi SSL handshake, dan fungsi lainnya. Dalam hal load balancing, APISIX juga berkinerja lebih baik. Beralih dari NGINX ke APISIX tidak akan menurunkan kinerja tetapi justru meningkatkan efisiensi manajemen yang dibawa oleh fitur seperti manajemen terpadu.

Microservice Gateway

APISIX memungkinkan Anda menulis plugin ekstensi dalam berbagai bahasa, yang dapat menyelesaikan masalah utama yang dihadapi oleh API gateway microservice east-west - bagaimana mengelola secara terpadu dalam lingkungan heterogen. APISIX juga mendukung service discovery seperti Nacos, etcd dan Eureka, dan metode DNS standar, yang dapat sepenuhnya menggantikan API gateway microservice seperti Zuul, Spring Cloud Gateway, dan Dubbo.

Kubernetes Ingress

Saat ini, proyek Kubernetes Ingress Controller resmi dari K8s terutama dikembangkan berdasarkan file konfigurasi NGINX, sehingga sedikit kurang dalam kemampuan routing dan mode pemuatan dan memiliki beberapa keterbatasan yang jelas. Misalnya, ketika menambahkan atau memodifikasi API apa pun, Anda perlu memulai ulang layanan untuk menyelesaikan pembaruan konfigurasi NGINX baru. Memulai ulang layanan memiliki dampak besar pada lalu lintas online.

APISIX Ingress Controller dengan sempurna menyelesaikan semua keterbatasan yang disebutkan di atas: mendukung pemuatan ulang panas sepenuhnya. Pada saat yang sama, ia mewarisi semua keunggulan APISIX dan juga mendukung CRD Kubernetes asli, yang memudahkan pengguna untuk bermigrasi.

Service mesh

Dalam lima hingga sepuluh tahun ke depan, arsitektur service mesh berbasis model cloud-native akan mulai muncul. APISIX juga telah mulai mengunci jalur ini sebelumnya. Setelah banyak penelitian dan analisis teknis, APISIX telah mendukung protokol xDS. APISIX Mesh lahir, dan APISIX juga memiliki tempat di bidang service mesh.

Ringkasan

Sudah tiga tahun sejak hari pertama Apache APISIX diopen-source. Komunitas yang sangat aktif dan studi kasus telah membuktikan bahwa APISIX adalah API gateway yang sempurna di era cloud-native. Dengan membaca artikel ini, saya yakin Anda memiliki pemahaman yang lebih komprehensif tentang APISIX.

Jika Anda memiliki pertanyaan, Anda dapat meninggalkan pesan di GitHub issue; kontributor komunitas akan merespons dengan cepat; tentu saja, Anda juga dapat bergabung dengan saluran Slack APISIX dan milis; silakan merujuk ke Join Us.