Eksplorasi Teknis Open-Source API Gateway Apache APISIX

Latar Belakang

Apache APISIX adalah sebuah API gateway open-source yang dinamis, real-time, dan berkinerja tinggi yang menyediakan berbagai fungsi manajemen lalu lintas seperti load balancing, routing dinamis, canary release, circuit breaking, autentikasi identitas, dan observabilitas.

Sebagai sebuah API gateway, Apache APISIX dapat membantu perusahaan memproses lalu lintas API dan microservice dengan cepat dan aman dalam skenario seperti gateway, Kubernetes Ingress, dan service mesh. Selain itu, APISIX dapat menangani lalu lintas north-south dari klien ke server dan lalu lintas east-west antara berbagai microservice perusahaan.

Dibuka sebagai open-source pada 6 Juni 2019, APISIX disumbangkan ke Apache Software Foundation pada Oktober 2019 dan dengan cepat menjadi proyek tingkat atas Apache Software Foundation dalam beberapa bulan.

Mengapa APISIX bisa booming dalam waktu singkat? Eksplorasi teknis seperti apa yang dilakukan APISIX? Mengapa semakin banyak developer dan perusahaan yang bersedia menggunakan APISIX? Mari kita cari tahu.

Fitur Utama Apache APISIX

Bebas dari Ketergantungan pada Database

Sebelum proyek APISIX muncul, sudah ada banyak API gateway komersial atau proyek API gateway open-source. Masalah potensial dari pesaing-pesaing tersebut adalah bahwa sebagian besar produk tersebut menyimpan data API, informasi konfigurasi, konfigurasi sertifikat, dan informasi rute dalam database relasional.

Keuntungan yang jelas dari penyimpanan dalam database relasional adalah memudahkan pengguna untuk melakukan query fleksibel dengan pernyataan SQL dan melakukan backup serta pemeliharaan lanjutan.

Namun, setiap koin memiliki dua sisi. Sebagai middleware dasar, API gateway akan menangani semua lalu lintas klien, yang meningkatkan persyaratan ketersediaan yang lebih tinggi. Jika API gateway Anda bergantung pada database relasional, gateway akan terpengaruh begitu terjadi kesalahan database, seperti crash dan kehilangan data. Dalam hal ini, batasan ketersediaan keseluruhan sistem semakin diperkuat.

Oleh karena itu, para perancang APISIX berusaha keras untuk menghindari masalah tersebut dari segi arsitektur dasar.

Arsitektur APISIX terutama dibagi menjadi dua bagian. Bagian pertama, disebut data plane, adalah komponen yang menangani permintaan dan lalu lintas klien. Ini mendukung autentikasi, offloading sertifikat, analisis log, dan observabilitas. Data plane tidak menyimpan data, yang merupakan struktur stateless.

Bagian kedua disebut control plane. APISIX tidak menggunakan penyimpanan konfigurasi tradisional seperti MySQL, tetapi etcd pada control plane.

Keuntungan dari melakukan hal ini:

1. Lebih selaras dengan arsitektur cloud-native dari produk
2. Lebih cocok untuk jenis data yang disimpan oleh API gateway
3. Lebih mencerminkan karakteristik ketersediaan tinggi
4. Pemberitahuan perubahan dalam milidetik

Dengan menggunakan etcd, data plane hanya perlu memantau perubahan etcd. Jika Anda melakukan polling ke database, mungkin membutuhkan 5-10 detik untuk mendapatkan konfigurasi terbaru. Namun, jika Anda memantau perubahan konfigurasi etcd, Anda bisa mendapatkan umpan balik dalam milidetik untuk mencapai efek real-time.

Oleh karena itu, menggunakan etcd alih-alih database relasional membuat APISIX lebih kompatibel dengan lingkungan cloud-native di lapisan bawah dan memperkuat keunggulan ketersediaan tingginya.

Plugin untuk Berbagai Bahasa Pemrograman

API gateway agak berbeda dari database dan middleware lainnya. Dibandingkan dengan yang terakhir, gateway lebih sering digunakan dalam pengembangan kustom dan integrasi sistem.

Meskipun APISIX telah merilis banyak plugin resmi, masih sulit untuk mencakup semua skenario penggunaan untuk pengguna yang berbeda. Oleh karena itu, dalam penggunaan aktual, beberapa plugin kustom perlu dikembangkan untuk bisnis, lebih atau kurang. APISIX juga mengintegrasikan lebih banyak protokol atau sistem melalui gateway dan akhirnya mencapai manajemen terpadu di lapisan gateway.

Pada awalnya, APISIX hanya mendukung pengembangan plugin dalam bahasa Lua. Keuntungannya adalah plugin yang dikembangkan dapat memiliki kinerja tinggi melalui optimasi dasar dari bahasa pemrograman asli. Namun, ada kerugian yang jelas, yaitu mempelajari Lua, bahasa baru, membutuhkan waktu dan biaya pembelajaran.

Pada dasarnya, APISIX menyelesaikan masalah ini dengan dua cara.

Cara pertama adalah mendukung lebih banyak bahasa pemrograman utama, seperti Java, Python, Go, dll., melalui Runner Plugin. Jika Anda adalah seorang insinyur backend, Anda seharusnya mengetahui setidaknya satu dari bahasa-bahasa ini; maka, Anda dapat dengan mudah memanfaatkan protokol RPC dan mengembangkan plugin APISIX menggunakan bahasa yang Anda kuasai.

Di satu sisi, ini bermanfaat untuk mengurangi biaya pengembangan dan meningkatkan efisiensi pengembangan. Namun, di sisi lain, ada beberapa latensi pada tingkat kinerja. Jadi muncul pertanyaan. Apakah ada solusi yang dapat mencapai kinerja asli Lua dan sekaligus mempertimbangkan bahasa tingkat tinggi?

Di sinilah metode kedua, yang ditunjukkan di bagian kiri gambar di atas. WebAssembly awalnya digunakan sebagai teknologi di front-end atau browser dan secara bertahap menawarkan keunggulannya di sisi server.

Dengan menyematkan WebAssembly ke dalam APISIX, pengguna dapat menggunakannya untuk mengkompilasi ke bytecode WebAssembly yang berjalan di APISIX. Efek akhirnya adalah mengembangkan plugin APISIX yang efisien, yang memiliki kinerja tinggi dan ditulis dalam bahasa pemrograman tingkat tinggi.

Jadi dalam versi APISIX saat ini, pengguna dapat menggunakan Lua, Go, Python, Wasm, dan metode lainnya untuk menyesuaikan kode berdasarkan APISIX. Desain ini menurunkan ambang batas bagi pengembang dan memberikan lebih banyak kemungkinan untuk fungsi APISIX.

Hot Reloading Plugin

APISIX memiliki dua kemajuan signifikan dibandingkan NGINX: APISIX mendukung manajemen cluster dan reloading dinamis.

Jika Anda pernah menggunakan NGINX, Anda akan tahu bahwa semua konfigurasi NGINX akan ditulis dalam file konfigurasi nginx.conf. Untuk melakukan kontrol cluster, Anda perlu memodifikasi file nginx.conf di setiap server. Tidak ada control plane manajemen terpusat dalam seluruh proses. Setiap NGINX adalah kombinasi dari data plane dan control plane. Biaya manajemen akan sangat tinggi jika pengguna memiliki puluhan atau ratusan server NGINX.

Dalam skenario yang disebutkan di atas, setiap server NGINX perlu di-restart untuk bekerja setelah memodifikasi file nginx.conf. Misalnya, untuk pembaruan sertifikat atau perubahan upstream, Anda perlu memodifikasi file konfigurasi terlebih dahulu dan me-reboot server agar perubahan berlaku. Metode ini masih bisa diterima jika permintaan Anda tidak terlalu besar. Namun, seiring dengan semakin banyaknya API dan microservice, dampak pada klien akan sangat besar jika server perlu di-reboot untuk setiap modifikasi.

• Hot Updates Dan Hot Plugins: Terus memperbarui konfigurasi dan pluginnya tanpa perlu restart!
• Proxy Rewrite: Mendukung penulisan ulang host, uri, skema, metode, dan header permintaan sebelum mengirimkannya ke upstream.
• Response Rewrite: Menetapkan kode status, body, dan header respons yang disesuaikan ke klien.
• Load Balancing Dinamis: Load balancing round-robin dengan bobot.
• Load Balancing Berbasis Hash: Load balancing dengan sesi hashing konsisten.
• Health Checks: Mengaktifkan pemeriksaan kesehatan pada node upstream dan secara otomatis menyaring node yang tidak sehat selama load balancing untuk memastikan stabilitas sistem.
• Circuit-Breaker: Pelacakan cerdas terhadap layanan upstream yang tidak sehat.
• Proxy Mirror: Menyediakan kemampuan untuk mencerminkan permintaan klien.
• Traffic Split: Memungkinkan pengguna untuk secara bertahap mengarahkan persentase lalu lintas antara berbagai upstream.

Gambar di atas mencantumkan komponen-komponen di mana APISIX saat ini menerapkan hot reloading. Kita dapat melihat bahwa kode berlaku secara real-time dari upstream ke sertifikat dan bahkan plugin. Beberapa anggota komunitas mungkin memahami mengapa upstream dan sertifikat bersifat dinamis karena data sering berubah. Namun, mereka mungkin bertanya mengapa modifikasi plugin perlu dinamis karena mereka beranggapan bahwa modifikasi plugin jarang terjadi, yang tampaknya tidak perlu sangat aktif.

Sebagai perancang dasar APISIX, kami berharap ini bisa benar-benar dinamis, yang membawa keuntungan signifikan dalam meningkatkan lebih banyak kemungkinan bagi perusahaan. Misalnya, pengguna dapat memecahkan masalah kode sambil memodifikasi plugin debug tanpa mengubah kode plugin apa pun. Dalam keadaan seperti itu, pengguna dapat mereproduksi masalah kapan saja dan mencatatnya tanpa perlu restart. Plugin dengan fungsi debugging yang dikombinasikan dengan mekanisme hot reloading akan sangat fleksibel, membantu pengembang menghemat waktu dan tenaga dalam memecahkan masalah.

Orkestrasi Dinamis Plugin

Selain hot reloading, APISIX mendukung orkestrasi dinamis real-time di antara plugin. Orkestrasi dinamis juga membawa kemungkinan tak terbatas untuk operasi plugin.

Apa itu orkestrasi plugin? Ketika kami mengajukan berbagai persyaratan, kami berharap dapat mengubah permintaan menjadi plugin, seperti bermain LEGO. Kami dapat membangun berbagai kemungkinan bentuk melalui standar yang seragam seperti bentuk yang cocok dan persimpangan, yang merupakan salah satu kesenangan dari LEGO. Untuk plugin APISIX, setiap plugin memenuhi persyaratan kasus yang independen. Kami tidak bisa berhenti bertanya apakah mungkin untuk memungkinkan pengguna menyesuaikan kebutuhan mereka dengan plugin seperti bermain LEGO.

Misalnya, jika ada 100 plugin di APISIX, pengguna hanya dapat melihat fungsi dari 100 plugin ini daripada fleksibilitas dasarnya. Oleh karena itu, ketika mengembangkan middleware, kami perlu mempertimbangkan apa yang dapat dilakukan produk dan bagaimana memberikan lebih banyak kemungkinan ketika orang menggunakannya.

APISIX saat ini memiliki hampir 100 plugin, tetapi memiliki lebih dari 100 kemungkinan. Akibatnya, setelah mengembangkan kemampuannya dalam pengaturan plugin, kombinasi menjadi 100 * 99 * 98 * 97 * 96 * ..., mendekati tak terbatas.

Misalnya, kode kesalahan biasanya akan muncul setelah Anda membatasi laju pengguna. Anda dapat mencoba menghubungkan plugin logging atau plugin pelaporan kesalahan untuk pencatatan aktivitas selanjutnya. Gambar di bawah ini menunjukkan model orkestrasi plugin APISIX.

Fitur ini memiliki manfaat tersembunyi: suite pengujian lengkap mencakup kode setiap plugin. Ketika pengguna mengatur plugin, dia tidak perlu menulis kode apa pun. Desain ini akan sangat ramah bagi manajer produk, insinyur keamanan, dan insinyur operasi dan pemeliharaan yang tidak perlu menghabiskan waktu lama untuk pelatihan dan pembelajaran. Sebaliknya, mereka dapat membuat plugin APISIX baru dengan menjatuhkan plugin untuk menyesuaikan beberapa pengaturan. Selain itu, kualitas kode plugin baru setinggi kode resmi dari APISIX open-source.

Gateway untuk Lalu Lintas Semua Arah

Insinyur sisi server yang melakukan beberapa pengembangan terkait gateway mungkin familiar dengan dua konsep dasar: Lalu Lintas North-South, yang mengacu pada lalu lintas dari klien, browser, atau perangkat IoT (Internet of Things) ke server, dan Lalu Lintas East-West, yang mengacu pada panggilan timbal balik antara sistem dan microservices dalam perusahaan.

Komponennya berbeda dalam menangani lalu lintas north-south dan east-west. Misalnya, lalu lintas north-south mungkin melewati load balancer, menuju ke API gateway, dan kemudian masuk ke service gateway. Itulah mengapa ada komponen seperti NGINX, APISIX, dan Spring Cloud Gateway. Ketika menangani lalu lintas east-west dengan service mesh, Anda mungkin menggunakan komponen seperti Envoy, yang tampaknya banyak, tetapi Anda dapat menemukan kesamaannya jika Anda fokus pada fungsinya. Sebagian besar adalah plugin untuk penjadwalan routing, upstream dinamis, dan autentikasi identitas yang aman. Dalam hal ini, bisakah kita menyatukan komponen yang menangani lalu lintas north-south dan east-west? Cara idealnya adalah ketika permintaan klien masuk ke server, semuanya ditangani oleh APISIX. Baik north-south maupun east-west, semua lalu lintas dan data dikontrol melalui control plane. Ini sepenuhnya dapat dicapai dengan teknologi APISIX saat ini.

Beberapa pengguna kami sudah mengkonfirmasi bahwa mode ini dapat secara signifikan mengurangi biaya operasi dan pemeliharaan pengguna. Pada saat yang sama, ini dapat mengurangi kompleksitas, sehingga meningkatkan kecepatan respons seluruh sistem. Selain itu, umpan balik positif ini memberikan arah yang lebih jelas untuk iterasi selanjutnya dari APISIX, memungkinkan APISIX untuk mencoba lebih banyak fungsi dan peran di tingkat gateway full-traffic.

Dukungan untuk Multi-Komponen Service Discovery

Gateway adalah komponen dasar tetapi vital. Ini memproses semua permintaan klien dan mengintegrasikan berbagai sistem dan proyek open-source, yang lebih penting.

Komponen penting lainnya - service discovery dan registrasi akan digunakan dalam integrasi dengan elemen lain. Pengguna akan menempatkan berbagai layanan ke dalam bagian terpisah, seperti Eureka dan Nacos. Akibatnya, sangat umum bagi beberapa komponen service discovery untuk hidup berdampingan dalam sistem IT skala besar dan berumur panjang.

Dalam situasi ini, semua lalu lintas masuk dan keluar menjadi gateway. Hampir semua gateway hanya mendukung satu service discovery. Anda perlu menentukan komponen service discovery Nacos terpisah di rute A dan komponen Consul lain di rute B. Akibatnya, Anda harus menyebarkan beberapa gateway untuk mencocokkan gateway tertentu dengan komponen service discovery yang berbeda.

Saat ini, APISIX tidak hanya mendukung service discovery di data plane tetapi juga secara bertahap mendukung komponen registrasi layanan dan service discovery di control plane. Ini adalah solusi yang sangat efisien untuk beberapa layanan perusahaan skala besar dan jangka panjang. Anda dapat dengan mudah terhubung ke berbagai komponen service discovery dan registrasi hanya dengan menyebarkan satu API gateway.

Eksplorasi Skenario Multi-Cloud dan Hybrid Cloud

Jika pengguna menyebarkan gateway ke lingkungan produksi yang dilengkapi dengan arsitektur Cloud-Native, multi-cloud dan hybrid cloud pasti akan menjadi skenario teknis jangka panjang. Di sisi lain, jika APISIX diatur dengan fitur lengkap, kinerja, plugin, dan multi-service discovery, masalah yang tak terhindarkan muncul dari bagaimana membuat pengguna berjalan lebih baik dalam lingkungan produksi. Skenario multi-cloud dan hybrid cloud membawa lebih banyak tantangan bagi APISIX. Oleh karena itu, lebih banyak detail berikut perlu dipertimbangkan.

1. Baik Upstream maupun Downstream Mendukung mTLS

Kami sebelumnya tidak menyadari bahwa fungsi mendukung upstream mTLS adalah prioritas tinggi. Namun, begitu berada dalam skenario lintas cloud, upstream mungkin adalah layanan di cloud lain atau bahkan menjadi layanan SaaS lain. Dengan demikian, perlu mendukung upstream mTLS untuk meningkatkan keamanan data.

2. Pemisahan Lengkap Arsitektur Control Plane dan Data Plane

Beberapa kerentanan keamanan APISIX terungkap dalam setahun terakhir, sebagian besar berasal dari penyebaran hybrid dari control dan data planes. Dengan kata lain, control dan data planes berada dalam layanan yang sama setelah layanan APISIX dimulai. Jadi begitu seorang peretas menyerang data plane tertentu melalui celah keamanan, dia juga bisa masuk ke control plane untuk mengontrol seluruh data, menyebabkan konsekuensi yang menghancurkan.

3. Memperkuat Manajemen Keamanan

Gateway umumnya menyimpan beberapa data sensitif. Misalnya, beberapa pengguna mungkin menyimpan sertifikat SSL atau informasi kritis untuk terhubung ke etcd di gateway. Dalam keadaan seperti itu, begitu etcd atau data plane diretas, itu dapat menyebabkan kebocoran data yang parah. Oleh karena itu, ketika menyimpan beberapa informasi penting, perlu mempertimbangkan menggunakan komponen khusus untuk menyimpan kunci seperti Vault untuk melindungi data sensitif.

4. Mengintegrasikan Lebih Banyak Standar Cloud

Kami bermaksud memastikan bahwa pengguna dapat berjalan dengan lancar di berbagai platform cloud tanpa mengonfigurasi apa pun dalam skenario multi-cloud. Ini tidak berarti bahwa pengguna perlu mengonfigurasi plugin kustom, tetapi langsung memungkinkan APISIX untuk mengintegrasikan standar, API, atau layanan lain dari berbagai cloud. Mode ini dapat membantu pengguna beradaptasi sebelumnya dan memastikan kenyamanan dan kenyamanan untuk penggunaan selanjutnya.

Pendukung Apache APISIX

Sepanjang sejarah pengembangan APISIX, banyak inovasi teknis telah dilakukan. Kontributor komunitas yang berkembang bekerja sama sejak fase konstruksi kode untuk membangun APISIX menjadi API gateway yang terintegrasi. Saat ini, APISIX mempertahankan iterasi cepat, berkat upaya para pendukung.

Iterasi dan peningkatan produk open-source pasti dikaitkan dengan kontributor dan pengguna.

Ketika APISIX disumbangkan ke Apache Software Foundation tiga tahun lalu, itu adalah proyek yang belum matang dengan hanya 20 kontributor. Untungnya, APISIX telah menarik lebih banyak pengguna, kontributor, dan perusahaan di seluruh dunia karena perkembangannya yang cepat. Misalnya, pelanggan kami termasuk perusahaan seperti Tencent, WPS, Sina Weibo, dan iQiyi, yang membawa miliaran panggilan API setiap hari. Selain itu, banyak pengguna internasional dari berbagai industri, seperti NASA, European Factory Platform, Swisscom, dll., ada dalam daftar klien kami.

Ambil WPS sebagai contoh. Ini adalah perusahaan perangkat lunak kantor SaaS di Cina, menyediakan perangkat lunak seperti Microsoft office 365. Baik Anda bekerja dengan banyak orang di ponsel, browser, atau perangkat terminal, puluhan atau ratusan pengguna dapat mengedit dokumen yang sama dan melihat modifikasi secara bersamaan. Fungsi ini diwujudkan melalui berbagai panggilan API.

Sebagian besar raksasa menangani miliaran panggilan API, dengan puncak QPS melebihi satu juta. Skala penggunaan seperti itu juga memungkinkan APISIX mendapatkan umpan balik dari pengguna nyata dalam skala besar. Berkat dukungan dari pengguna perusahaan ini, APISIX telah berkembang pesat menjadi proyek open-source yang matang.

Selain itu, banyak pengguna juga berbagi pengalaman atau iterasi fungsi kode mereka menggunakan APISIX di komunitas, berkontribusi pada manfaat timbal balik dan win-win untuk kedua belah pihak. Ini menunjukkan bahwa pengguna menganggap APISIX sebagai produk yang baik dan lebih dari proyek open-source yang layak. Hanya setelah kami memenangkan kepercayaan pengembang, kami memiliki kesempatan untuk menjadi proyek open-source yang berharga.

Kontributor menyesuaikan pengalaman dan umpan balik untuk menciptakan banyak fitur produk; pengguna dapat memanfaatkan fitur-fitur ini untuk membawa nilai bagi perusahaan. Lingkaran yang baik muncul, yang merupakan esensi dari open source. Kami selalu mencari kebenaran semacam ini daripada mengejar gelembung pengikut yang banyak.

Pratinjau APISIX 3.0

Sejauh ini, kami telah berbicara banyak tentang apa yang telah dilakukan APISIX di masa lalu dan sekarang. Proses pengembangan APISIX dapat dibagi menjadi beberapa tahap.

APISIX 1.0 adalah untuk membangun kerangkanya, memperkuat arsitektur dasar, dan menyajikan beberapa fungsi penting dari API gateway. Kami menjelajahi lebih dalam dalam versi 2.0, membuat lapisan bawah lebih fleksibel dan arsitektur lebih matang.

Untuk proyek open-source yang matang, tanda kematangannya tidak hanya pada fungsinya yang hebat tetapi pada membawa pengalaman yang lebih baik bagi pengguna dan pengembang.

Pada tahap saat ini, APISIX telah melakukan banyak eksplorasi dan inovasi teknis tetapi belum sepenuhnya mempertimbangkan pengalaman pengguna. Masalahnya menunjukkan kualitas dokumen yang tidak stabil dan kurangnya video tutorial. Oleh karena itu, banyak pengguna bingung ketika mereka pertama kali berhubungan dengan APISIX. Mereka tidak tahu bagaimana menggunakannya atau menerapkan fungsi tertentu ke kasus pengguna yang berbeda, dan mereka tidak yakin tentang nilai unik apa yang dapat dibawa APISIX ke perusahaan.

Oleh karena itu, dalam versi APISIX 3.0 berikutnya, kami akan mencoba menyelesaikan masalah serupa dan merekonstruksi banyak kekurangan yang tidak ramah terhadap pengalaman pengembang. Misalnya, kami akan mendesain ulang API untuk menghilangkan ketergantungan pada nilai kembalian tertentu dari etcd dan memperbarui dokumentasi resmi agar lebih ramah pengguna dengan deskripsi yang jelas. Pada tingkat fungsi, control plane dan data plane juga akan dipisahkan untuk meningkatkan keamanan; ini mendukung lebih banyak protokol layer-4 dan protokol RPC sehingga pengguna dapat dengan cepat mendapatkan lalu lintas dari semua arah gateway.

Setelah menerapkan fungsi-fungsi di atas, APISIX 3.0 akan menjadi lebih aman, andal, dan mudah digunakan. Kami selalu memperhatikan operasi yang baik dan pengalaman pengguna. Kami berharap APISIX dapat menangani permintaan dari semua API dan microservice di seluruh dunia dan membantu perusahaan mengelola lalu lintas API dan microservice dengan lebih efisien.

Diharapkan APISIX akan merilis versi baru, 3.0, pada akhir 2022. Kami berharap Anda akan terus mengikuti tren versi terbaru APISIX dan secara aktif berpartisipasi dalam kontribusi proyek Apache APISIX.

Masa Depan APISIX

Pengembangan dan penggantian teknologi sisi server sangat cepat, karena banyak teknologi dan kerangka kerja populer lima tahun lalu mulai memudar. Alasannya bukan karena insinyur lebih menyukai hal-hal baru, tetapi karena teknologi ini tidak dapat memenuhi kebutuhan nyata insinyur dan perusahaan. Nasib mereka sudah ditentukan: ditendang keluar. Kenyataan penting ini memberi tahu kita bahwa teknologi harus melayani bisnis dan produk dan tidak dapat bertahan tanpa mencocokkan kebutuhan pasar saat ini.

"Jangan membangun kastil di atas rawa." Pepatah ini selalu mengingatkan pengembang Apache APISIX bahwa mereka harus mengandalkan kebutuhan dan skenario aktual untuk memandu pengembangan dan evolusinya. Jika tidak, produk akan ditinggalkan oleh insinyur secara bertahap.

Bagaimana kita bisa menjaga teknologi Apache APISIX tetap terdepan di industri? Ini adalah pertanyaan penting apakah Apache APISIX dapat terus menarik pengembang dan pengguna perusahaan di masa depan. Jawabannya sederhana: bergabung dengan perusahaan dan insinyur yang berkembang pesat, tumbuh bersama, dan saling mendukung. Ini membuat Apache APISIX selalu berdiri di garis depan teknologi. Hanya dengan melakukan ini, APISIX memiliki potensi untuk menjadi proyek open-source evergreen kelas dunia.

Masa depan APISIX adalah untuk lebih mendukung skenario Serverless, meningkatkan service mesh, membangun platform siklus hidup API yang lengkap, dan meningkatkan pengalaman pengguna di cloud publik. Ini tidak direncanakan oleh beberapa pengembang internal tetapi oleh ribuan pengembang di industri. Jadi bergabunglah dengan kami untuk merasakan pesona open source!