Cara Menerapkan Plugin Orchestration di API Gateway

Lihat Video

Pertama-tama, izinkan saya memperkenalkan diri. Saya Ming Wen, salah satu pendiri API7.ai. Saya adalah Wakil Presiden dan anggota PMC dari proyek open source Apache APISIX. Saya juga seorang committer dari Apache SkyWalking. Selain itu, saya adalah pendiri Komite Open Source Qihoo 360, Tencent Cloud TVP, dan anggota TOC dari TARS Foundation. Saya memiliki lebih dari 40 paten keamanan.

Dalam topik hari ini, saya akan memperkenalkan 4 bagian. Pertama, pengenalan singkat tentang Apache APISIX. Apa itu Apache APISIX dan apa yang dapat membantu kita atasi? Bagian kedua adalah pengembangan kustom di API gateway, dan bagian ketiga adalah plugin di Apache APISIX. Bagaimana kita dapat menghasilkan plugin secara otomatis? Bagian terakhir adalah beberapa pemikiran tentang masa depan API gateway.

Pertama-tama, mari saya perkenalkan secara singkat Apache APISIX. Dalam satu kalimat, ini adalah API gateway cloud-native. Berikut adalah alamat repo Apache APISIX di GitHub.

Apache APISIX adalah proyek yang sangat muda. Ini di-open-source pada Juni tahun lalu dan disumbangkan ke inkubator Apache pada Oktober. Pada Juli tahun ini, proyek ini lulus dari inkubator Apache dan menjadi proyek tingkat atas. Ini adalah komunitas yang berkembang pesat, hanya membutuhkan waktu sembilan bulan.

Bagi pengembang yang belum familiar dengan Apache APISIX, Anda dapat menganggapnya sebagai versi yang ditingkatkan dari NGINX, yang mencakup semua fungsi NGINX sambil menggunakan Lua. Ini membawa lebih banyak fitur dinamis ke NGINX, mengubah NGINX menjadi API gateway yang sangat kuat. Fitur terbesar dari Apache APISIX adalah bahwa ini sepenuhnya dinamis, termasuk routing, sertifikat SSL, plugin, dll. Di Apache APISIX, semua fitur dikonfigurasi secara dinamis melalui admin API, tanpa perlu me-restart layanan sama sekali. Di Apache APISIX, kebutuhan bisnis pengguna semuanya diwujudkan dengan menggunakan Lua untuk mengembangkan plugin. APISIX memiliki lebih dari 40 plugin bawaan, termasuk autentikasi, pembatasan kecepatan, pembatasan permintaan, keamanan, log, observabilitas, dll., yang pada dasarnya mencakup semua fitur yang mungkin dihadapi pengguna di perusahaan.

Jadi mari kita lihat apa yang dapat dilakukan Apache APISIX untuk Anda? Ini dapat menangani lalu lintas Layer 4 dan Layer 7, termasuk HTTP, HTTPS, TCP, UDP, MQTT, dll.

Karena Apache APISIX berbasis NGINX, Anda secara alami dapat menggunakan Apache APISIX sebagai pengganti NGINX untuk menangani lalu lintas utara-selatan. Pada saat yang sama, Apache APISIX juga dapat menangani lalu lintas antara layanan mikro dengan baik, sehingga Anda dapat menggunakannya untuk menggantikan Envoy. Kami juga memiliki beberapa pengguna yang menggunakan Apache APISIX sebagai ingress controller Kubernetes. Pada saat yang sama, dengan bantuan plugin MQTT Apache APISIX, kita dapat menggunakan Apache APISIX sebagai gateway IoT, atau menggunakan plugin IDP untuk mengubah APISIX menjadi gateway zero-trust. Jadi APISIX lebih fokus pada kekuatan di gateway itu sendiri. Melalui plugin, pengguna dapat mengubah APISIX menjadi berbagai gateway yang dibutuhkan oleh bisnis mereka.

Ini adalah arsitektur teknis Apache APISIX. Dari sini kita dapat melihat bahwa APISIX memiliki dua bagian, bagian kiri adalah data plane, dan bagian kanan adalah control plane.

Mari kita lihat data plane terlebih dahulu. Setelah permintaan pengguna diproses melalui Apache APISIX, itu dapat diteruskan ke API pribadi, API publik, atau API mitra. Di dalam Apache APISIX, plugin dibangun dengan cara yang mirip dengan Lego. Anda dapat dengan mudah menghapus atau menambahkan plugin tanpa perlu me-restart layanan.

Kemudian mari kita lihat control plane. Di control plane, admin menulis konfigurasi ke kluster etcd melalui admin API, dan data plane APISIX akan memantau etcd, sehingga konfigurasi dapat mencapai semua data plane dalam hitungan milidetik. Setelah node data plane memproses data, mereka kemudian melaporkan beberapa metrik dan data log ke komponen seperti SkyWalking, Prometheus, dll.

Dari diagram arsitektur ini, kita dapat melihat bahwa APISIX hanya bergantung pada etcd, dan tidak memiliki RDS seperti MySQL dan PostgreSQL. Oleh karena itu, APISIX dirancang lebih baik untuk ketersediaan tinggi. Pada saat yang sama, arsitekturnya akan lebih sederhana, memudahkan untuk deployment dan operasional.

Gambar ini adalah lanskap Apache APISIX. Melihatnya dari kiri, APISIX mendukung banyak protokol Layer 4 dan Layer 7. Ini tidak hanya mendukung lalu lintas dari browser dan aplikasi seluler, tetapi juga mendukung berbagai perangkat IoT untuk melaporkan lalu lintas ke APISIX.

Apache APISIX juga mendukung banyak pusat penemuan layanan eksternal, termasuk etcd dan Consul.

Sebagai perangkat lunak infrastruktur yang sangat penting, API gateway umumnya ditempatkan di pintu masuk lalu lintas. Oleh karena itu, ini tidak hanya perlu memproses semua permintaan dari klien, tetapi juga perlu terhubung ke beberapa layanan backend, seperti SkyWalking, Datadog, Kafka, dll.

Di bagian bawah gambar ini, APISIX tidak hanya mendukung berjalan di bare metal, tetapi juga di server di berbagai cloud publik. Kami juga mendukung berjalan di platform ARM.

Oke, Bagian 1 adalah pengenalan singkat tentang APISIX, dan kemudian di Bagian 2, saya akan memperkenalkan pengembangan plugin kustom di API Gateway.

Pengembangan kustom adalah poin yang sangat penting ketika kita menggunakan gateway open source, dan ini memiliki tingkat kesulitan yang tinggi. Gateway bukanlah perangkat lunak yang dapat digunakan langsung. Ini berbeda dengan database dan antrian pesan. MQ dan database dapat digunakan langsung setelah kita menginstalnya, tetapi gateway tidak. Ini karena gateway memerlukan lebih atau kurang pengembangan kustom.

Misalnya, jika perusahaan Anda memiliki beberapa sistem lama, atau beberapa protokol khusus, seperti beberapa protokol di industri keuangan dan keamanan, Anda perlu melakukan beberapa transkode di tingkat gateway.

Di sisi lain, meskipun APISIX menyediakan lebih dari 40 plugin, ini pasti tidak dapat memenuhi semua kebutuhan perusahaan, karena setiap perusahaan memiliki beberapa kebutuhan unik. Jadi, kita sering perlu melakukan beberapa pengembangan kustom dari plugin yang ada untuk memenuhi kebutuhan kita. Ini sebenarnya adalah masalah besar, karena pengembangan plugin masih membutuhkan lebih banyak keterampilan. Untuk pengembangan plugin, proyek open source yang berbeda memiliki solusi yang berbeda.

Mari kita lihat Kong terlebih dahulu. Ini adalah proyek API gateway yang terkenal. Ini berusia 5 tahun. Stack teknologi Kong pada dasarnya sama dengan APISIX, dan keduanya diimplementasikan berdasarkan NGINX dan Lua. Tetapi arsitektur teknis Kong tidak sama dengan APISIX. Kong berbasis RDS seperti PostgreSQL dan Cassandra. APISIX menggunakan etcd, dan solusi APISIX lebih dekat dengan Kubernetes dan cloud native.

Kesamaan antara Kong dan APISIX adalah bahwa pengembang perlu menggunakan Lua untuk mengembangkan plugin. Lua bukan bahasa pemrograman yang populer, dan banyak pengembang tidak familiar dengannya, meskipun Lua sendiri sederhana. Jadi selain membuat plugin lebih sederhana, solusi apa yang lebih baik?

Solusi Kong adalah mendukung penulisan plugin dengan Go. Pendekatan ini akan menarik lebih banyak pengembang Go untuk menulis plugin untuk memenuhi kebutuhan kustom perusahaan mereka sendiri. Ini adalah ide yang bagus, tetapi di sisi lain, Kong diimplementasikan secara native berdasarkan Nginx dan Lua, dan plugin yang ditulis dalam Go sebenarnya perlu memanggil proses lain, yang akan memiliki komunikasi antar-proses, yang memiliki masalah kinerja.

Mari kita lihat yang kedua, yang juga merupakan proyek data plane open source yang sangat terkenal untuk memproses lalu lintas timur-barat, Envoy, yang ditulis dalam C++. Jadi, plugin Envoy secara alami juga diimplementasikan dalam C++. Jadi tidak mudah untuk memulai.

Envoy juga mendukung bahasa lain untuk pengembangan. Misalnya, Envoy mendukung filter Lua, dan filter Lua memiliki masalah yang sama dengan Kong, yaitu ada sedikit pengembang yang familiar dengan Lua. Jadi Envoy juga mendukung WASM, yang dapat menarik lebih banyak pengembang bahasa lain untuk menulis plugin. Solusi ini tidak sempurna, dan stabilitas dan kinerja WASM masih perlu waktu untuk ditingkatkan.

Solusi Kong dan Envoy adalah sama: mereka berharap lebih banyak pengembang memiliki kemampuan untuk mengembangkan plugin, apakah mereka menggunakan Go, Lua, atau WASM. Jadi kembali ke APISIX, kami berharap menemukan solusi yang sempurna.

Jadi seperti apa solusi sempurna ini? Kami berpikir bahwa di tingkat gateway, dua masalah berikut harus diselesaikan terlebih dahulu untuk menyelesaikan masalah pengembangan kustom.

Yang pertama adalah bahwa banyak plugin yang perlu dikembangkan sebenarnya sederhana. Bagaimana cara menggunakan kembali lebih dari 40 plugin open source yang sudah ada?

Yang kedua adalah memungkinkan pihak yang membutuhkan gateway di perusahaan, seperti manajer produk, tim operasi, dan tim keamanan, untuk mengimplementasikan kebutuhan mereka sendiri di gateway dengan biaya sesedikit mungkin, lebih baik jika tidak perlu menulis kode sama sekali.

Jika kita dapat menyelesaikan dua masalah ini, maka kita memiliki kesempatan untuk membiarkan lebih banyak orang, bukan hanya pengembang, untuk dapat mengembangkan gateway AP.

Pertama-tama, mari kita lihat masalah pertama adalah bagaimana menyelesaikan penggunaan kembali plugin yang ada. Microservices sudah menjadi teknologi yang sangat populer, jadi bisakah kita memperkenalkan konsep ini ke dalam plugin API gateway?

Kita dapat membuat setiap plugin hanya melakukan satu fitur, seperti microservice, yang juga sama dengan desain proses di Linux. Oleh karena itu, kami telah mengusulkan konsep yang disebut micro-plugin.

Setiap plugin kami hanya melakukan satu fitur independen. Kemudian, kita membutuhkan desain yang mirip dengan pipa Linux untuk menghubungkan micro-plugin ini.

Misalnya, saya pertama-tama memanggil plugin uri block. Setelah panggilan selesai, saya akan menilai apakah uri benar-benar diblokir. Jika diblokir, maka lanjutkan untuk memanggil plugin Kafka.

Dengan menggunakan metode pipa ini, plugin-plugin ini dapat dihubungkan. Apache APISIX sekarang memiliki lebih dari 40 plugin. Permutasi dari lebih dari 40 plugin memiliki kemungkinan yang tidak terbatas, cukup untuk memenuhi kebutuhan pengguna.

Tetapi masalah sekarang adalah bahwa di semua API gateway yang telah di-open-source, plugin tidak berbagi konteks dan tidak dapat bekerja sama satu sama lain. Jadi kita perlu menghubungkan plugin-plugin itu bersama-sama. Hanya dengan melakukan ini, kita dapat menyelesaikan masalah penggunaan kembali plugin dengan micro-plugin.

Masalah kedua adalah, setelah kita memiliki micro-plugin, bagaimana kita dapat mengurangi biaya pengembangan plugin baru API gateway seminimal mungkin untuk memenuhi kebutuhan pengguna. Kami berharap bahwa untuk non-pengembang, yaitu manajer produk dan keamanan yang tidak memiliki latar belakang teknis dan tidak tahu cara memprogram, mereka dapat mewujudkan kebutuhan mereka tanpa pengembangan, karena mereka memahami kebutuhan kita dengan baik.

Pada saat yang sama, ini akan menurunkan batasan untuk pengembangan API gateway, memungkinkan semakin banyak orang berkontribusi pada gateway AP. Jika kita menggunakan slogan, yaitu "dari kreativitas ke kreasi", kita tidak hanya dapat menulis ide kita sendiri ke dalam dokumen untuk pengembang, tetapi juga langsung membuat plugin baru.

Ini terdengar seperti ide yang bagus, jadi bisakah itu diwujudkan? Sebenarnya, kita dapat melompat keluar dari pemikiran teknis untuk melihat bagaimana industri lain menyelesaikannya.

Misalnya, dalam mesin proses industri medis, mereka dibangun dengan cara GUI, karena pengguna mereka adalah dokter. Kemudian, Lego untuk anak-anak adalah sama. Anda dapat menggunakan sejumlah blok bangunan terbatas untuk membangun bentuk yang tidak terbatas.

Gabungkan ide GUI dan Lego, maka kita dapat melihat bahwa itu sebenarnya adalah Scratch, yang digunakan anak-anak untuk belajar pemrograman, sehingga batasannya akan sangat rendah.

Berdasarkan dua masalah yang telah kita selesaikan sebelumnya, APISIX secara unik mengusulkan konsep baru: plugin orchestration. Berikut adalah demo dari plugin orchestration, kita dapat melihat video singkat ini terlebih dahulu.

Dalam video ini, kita pertama-tama membuat plugin uri block, dan kemudian kita membuat penilaian kondisi. Jika uri block benar, maka kita akan menambahkannya ke plugin fault injection; jika hasil uri block adalah False, kita akan meneruskannya ke plugin Kafka untuk mencatat log.

Kemudian kita mengkonfigurasi setiap plugin dan kondisi penilaian. Terakhir, mari kita verifikasi dengan curl untuk melihat apakah plugin baru ini benar-benar berfungsi di node gateway. Ya, itu berfungsi.

Selanjutnya, saya akan menjelaskan kepada Anda bagaimana plugin orchestration ini diimplementasikan. Ini mungkin juga merupakan masalah teknis yang menjadi perhatian semua orang.

Untuk mengimplementasikan plugin orchestration, kita perlu mengambil tiga langkah.

Pada langkah 1, kita perlu menggunakan DAG untuk menggambarkan plugin baru ini. Kita dapat melihat bahwa grafik dengan panah di sebelah kiri sebenarnya adalah DAG (directed acyclic graph), yang sama dengan kode yang dijelaskan dalam video sebelumnya. Kemudian ini adalah metode deskripsi yang ramah bagi manusia. Untuk komputer, kita harus mengubahnya menjadi bahasa deskripsi dari struktur data di sebelah kanan. Misalnya, node nomor 1 diikuti oleh 2 4 6 berarti node 1, yang menunjuk ke node kedua, keempat, dan keenam; nilai nomor 3 adalah nil, berarti tidak ada node lain di belakang node nomor 3, dan yang lainnya serupa. Dengan cara ini, kita mengubah DAG menjadi deskripsi struktur data.

Setelah memiliki struktur data ini, kita kemudian mengubah struktur data ini menjadi string JSON, dan kemudian meneruskan string JSON ini ke server. String JSON di sebelah kanan dikonversi dari plugin yang kita lihat dalam demo.

Setelah langkah 1, kita sudah memiliki string yang dijelaskan oleh JSON, tetapi bagaimana kita mengubah string ini menjadi kode yang dapat dijalankan oleh APISIX?

Kita tahu bahwa di APISIX kita menjalankan kode Lua, jadi kita membutuhkan kompiler, untuk mengurai JSON menjadi AST (abstract syntax tree), dan akhirnya menghasilkan kode Lua. Pada saat ini, kita menggunakan jsonschema untuk melakukan langkah ini. Di bawah ini adalah repositori open source.

Setelah menghasilkan kode Lua, kita menggunakan control plane APISIX untuk menulis kode Lua ke etcd melalui admin API, dan kemudian node data plane APISIX mendapatkan kode Lua melalui watch etcd. APISIX memiliki kemampuan untuk menjalankan kode Lua secara dinamis, seperti plugin serverless APISIX.

Oleh karena itu, plugin baru yang dihasilkan oleh plugin orchestration, dari DAG hingga berjalannya node data, seluruh proses ini sepenuhnya dinamis, yang merupakan fitur yang sangat penting dari APISIX.

Jika Anda melihat ini, apakah Anda memiliki pertanyaan, di mana saya dapat mencobanya? Jangan khawatir, ada proyek open source di sini, dan kami juga memiliki demo online.

Di bagian terakhir, saya ingin berbicara tentang pemikiran kami tentang masa depan API gateway. API gateway telah ada untuk waktu yang lama. Sudah ada banyak perusahaan dan proyek open source yang melakukan API gateway lebih dari sepuluh tahun yang lalu. Kemudian di era cloud-native, API gateway menghadapi perubahan dalam kebutuhan pengguna, dan persyaratan yang lebih tinggi diajukan untuk gateway AP.

Salah satu tren adalah bahwa API gateway utara-selatan tradisional mulai memproses lalu lintas layanan mikro timur-barat. Misalnya, NGINX telah meluncurkan NGINX control dan NGINX unit. Kong dan APISIX juga bertindak sebagai API gateway layanan mikro.

Pada saat yang sama, proyek mash layanan timur-barat juga mencoba bertindak sebagai gateway akses utara-selatan. Jadi untuk proyek open source, semuanya ingin memproses lalu lintas penuh.

Proyek open source tentang pemrosesan lalu lintas sedang berkembang, kita dapat melihat BFE dari Baidu dan MOSN dari Alibaba. Mereka semua fokus pada lalu lintas.

Yang kedua adalah low code. Solusi terbaik adalah PM dapat langsung mengimplementasikan fitur melalui plugin orchestration, sehingga pengembang lebih fokus pada gateway itu sendiri.

Dengan cara ini, bisnis dan inti dari API gateway dipisahkan. Anda dapat membiarkan orang yang tidak memahami teknologi dan pengembangan plugin untuk berkontribusi plugin ke proyek open source. Ini sangat penting.

Poin ketiga adalah real-time. Dengan populernya 5G dan IoT, dan pendaratan Kubernetes di perusahaan, ini telah mengajukan persyaratan yang sangat tinggi untuk efek real-time dari konfigurasi, proses permintaan, dan analisis data real-time. Untuk gateway, jika Anda tidak dapat real-time, sangat tinggi kinerjanya, dan sangat rendah latensinya, maka itu tidak dapat bertahan dalam tiga hingga lima tahun ke depan.

Terakhir tetapi tidak kalah penting adalah open source. Kita dapat melihat perangkat lunak sedang memakan perangkat keras, dan perangkat lunak open source sedang memakan perangkat lunak. Pada akhirnya, semua perangkat lunak infra adalah open source.

Hal yang sama berlaku untuk API gateway. Open source memungkinkan perusahaan untuk menggunakannya dengan biaya lebih rendah tanpa khawatir tentang vendor lock-in. Selain itu, peluang komersial dari open source juga akan membawa lebih banyak keuntungan bagi pengembang open source. Ini adalah model yang baik untuk situasi win-win.