APISIX Mendorong Peningkatan API Gateway di Tencent BlueKing

Studi kasus ini dibagikan oleh Lei Zhu, Direktur Teknis BlueKing PaaS Platform, IEG (Interactive Entertainment Group), Tencent

Tentang BlueKing

BlueKing adalah seperangkat PaaS penelitian dan operasi terintegrasi internal yang dikembangkan di dalam Tencent IEG (Interactive Entertainment Group), melayani berbagai unit bisnis dan platform internal. Perannya adalah menyediakan layanan siklus hidup penuh untuk proyek perusahaan dalam tahap CI (Continuous Integration), CD (Continuous Delivery), dan CO (Continuous Operation).

Ikhtisar

Tantangan

• Kinerja Rendah: Kinerja rendah dalam kondisi konkurensi tinggi dan algoritma routing, mengakibatkan pencocokan dan penerusan routing yang lambat
• Tekanan DB yang Besar: Kebijakan routing disimpan di MySQL. Oleh karena itu, database mengalami tekanan dengan banyak permintaan pengambilan data
• Biaya Tinggi: Redis banyak digunakan dalam berbagai skenario, menyebabkan biaya overhead yang tinggi
• Isolasi yang Tidak Cukup: Tidak dapat mencapai isolasi fisik; koneksi jangka panjang yang tidak stabil
• Dukungan Protokol Tunggal: Hanya mendukung protokol HTTP
• Tidak Mendukung Routing Dinamis: Tidak ramah untuk rilis canary dan tidak mampu mengkapsulasi skenario
• Kurangnya Kemampuan Penemuan Layanan: Tidak ramah terhadap arsitektur mikroservis

Tujuan

• Mengubah kemampuan platform menjadi mikroservis independen, dan melakukan transformasi mikroservis untuk membentuk arsitektur PaaS
• Menggunakan teknologi low-code untuk mengembangkan SaaS secara efisien dan memanfaatkan kemampuan mikroservis dari platform PaaS
• Merespons berbagai skenario layanan secara fleksibel melalui berbagai SaaS

Hasil

• Mencapai operasi dan ekspansi gateway yang terpadu menggunakan sumber daya kustom CRD yang disediakan oleh K8s
• Menyediakan fitur yang lebih kaya dengan mengintegrasikan APISIX: manajemen sumber daya, rilis versi, dokumen otomatis, manajemen izin, observabilitas, pemantauan, dan perlindungan keamanan
• Menurunkan biaya untuk mendukung skenario penemuan layanan dengan antarmuka dan regulasi pengembang yang terpadu

Keragaman dan Kompleksitas Game Mengharuskan BlueKing API Gateway

Di dalam Tencent, mungkin ada ribuan game. Kecuali beberapa game yang dikembangkan sendiri, yang lainnya milik agensi. Game-game ini berbeda dalam bahasa, penyimpanan yang mereka andalkan, dan gaya arsitektur yang menentukan bahwa BlueKing mengembangkan API gateway sendiri.

Menghadapi skenario bisnis yang kompleks ini yang melibatkan sejumlah besar arsitektur heterogen, BlueKing, sebagai platform internal, perlu mengubah API gateway-nya untuk mengembangkan arsitektur PaaS, kemudian menggunakan teknologi low-code untuk mengembangkan SaaS secara efisien dan memanfaatkan kemampuan mikroservis dari PaaS, serta menggunakan berbagai SaaS untuk menangani skenario layanan.

Untuk mengabstraksi arsitektur BlueKing, kita bisa mendapatkan diagram API.

• Di satu sisi, BlueKing adalah platform yang rumit dengan kebutuhan yang kompleks untuk gateway terpadu. Selain berfungsi sebagai proxy untuk memanggil API platform, BlueKing membutuhkan lebih banyak kemampuan gateway, misalnya, penemuan layanan, otorisasi dan autentikasi, routing dinamis, rilis canary, dan pembatasan laju, dll.

• Di sisi lain, dengan perkembangan teknologi cloud-native, banyak SaaS dan platform internal sekarang di-deploy di kluster K8s. Skenario ini menuntut persyaratan baru untuk gateway, seperti kontrol lalu lintas terpadu dari permintaan panggilan eksternal melalui gateway lalu lintas atau API gateway terpadu.

Pada saat yang sama, beberapa sistem bisnis internal menggunakan beberapa kemampuan infrastruktur dari platform BlueKing, seperti manajemen kontainer atau pemantauan. Mereka juga membutuhkan gateway layanan terpadu untuk mengelola semua lalu lintas panggilan.

Dengan perkembangan kebutuhan bisnis internal, API gateway BlueKing perlu mendukung skenario yang semakin beragam.

BlueKing API Gateway 1.0

BlueKing API Gateway 1.0 bertujuan untuk memungkinkan pemanggil platform (termasuk berbagai SaaS dan mesin proses) untuk langsung memanggil API gateway untuk menyelesaikan konversi protokol dan verifikasi otoritas melalui gateway.

Arsitekturnya juga relatif sederhana, yang dibagi menjadi dua bagian: sisi server dan sisi manajemen. Platform harus mengakses sisi manajemen, mengkonfigurasi alamat sumber daya API dan izin yang sesuai dari platform, dan akhirnya mendaftarkan layanannya ke API Gateway.

Setelah beberapa tahun, dengan meningkatnya permintaan dan skenario yang kompleks, kekurangan BlueKing API Gateway 1.0 mulai muncul secara bertahap. Misalnya:

• Kinerja kerangka kerja yang buruk: Kerangka kerja Django dipilih untuk implementasi. Kinerjanya rata-rata dalam skenario konkurensi tinggi dan menjadi terbebani saat memproses permintaan besar.

• Kinerja implementasi routing yang rata-rata: Kinerja algoritma yang digunakan dalam routing API rendah, memengaruhi kecepatan pencocokan dan penerusan rute.

• Database terbebani: Semua kebijakan routing disimpan di MySQL. Ketika ada banyak aturan, banyak permintaan pengambilan data perlu dilakukan dengan tekanan query yang berat.

• Biaya jaringan tinggi: Redis banyak digunakan dalam berbagai skenario, mengakibatkan biaya overhead jaringan yang terlalu besar.

BlueKing API Gateway 2.0

Untuk mengatasi masalah di atas, BlueKing melakukan iterasi berdasarkan versi 1.0 dan merancang serta mengimplementasikan versi 2.0. Dibandingkan dengan generasi sebelumnya, perubahan terbesar dari versi 2.0 adalah implementasi ulang kerangka kerja gateway dan lapisan penerusan dalam Golang karena Golang memiliki lebih banyak keunggulan daripada Python dalam menangani permintaan konkurensi besar.

Perubahan optimasi lainnya juga dilakukan. Misalnya, implementasi routing yang lebih efisien dipertahankan dalam memori; cache berbasis memori diperkenalkan di lapisan tengah untuk mengurangi ketergantungan pada Redis. Arsitektur baru juga menambahkan manajemen siklus hidup untuk gateway dengan banyak versi dan lingkungan, serta memperkenalkan mekanisme plugin yang diperluas untuk memudahkan pengembang memperluas kemampuan gateway melalui plugin.

Secara keseluruhan, BlueKing API Gateway 2.0 mengatasi masalah kinerja dan sebagian besar masalah yang dihadapi dalam versi 1.0. Namun seiring waktu, masalah baru mulai muncul secara perlahan.

• Isolasi yang tidak cukup: Tidak dapat mencapai isolasi fisik yang sebenarnya; proses rilis akan menyebabkan koneksi jangka panjang terputus

• Dukungan protokol tunggal: Hanya HTTP yang didukung, dan permintaan untuk protokol non-HTTP semakin meningkat dalam skenario aktual

• Tidak mendukung aturan routing dinamis: Tidak mendukung aturan routing dinamis yang dicocokkan dengan kondisi; tidak cukup ramah untuk skenario rilis canary; tidak mampu mengkapsulasi skenario berbasis kombinasi

• Kurangnya kemampuan penemuan layanan: Kurangnya kemampuan penemuan layanan otomatis, tidak ramah terhadap arsitektur mikroservis

APISIX Menonjol dalam Pemilihan Teknologi BlueKing API Gateway

Ada banyak sistem produk di perusahaan yang perlu menggunakan API gateway. Sangat sulit untuk mengintegrasikan semua persyaratan yang beragam untuk gateway ke dalam satu set gateway yang sama.

Oleh karena itu, kami memiliki ide untuk merancang gateway terdistribusi. Artinya, gateway besar dibagi menjadi banyak microgateway, yang digunakan untuk menyeimbangkan perbedaan dalam persyaratan sistem yang berbeda untuk gateway." kata Zhu.

Komponen arsitektur gateway terdistribusi terutama dibagi menjadi dua kategori: sisi manajemen dan instance microgateway.

Sisi manajemen secara seragam mengelola dan mengontrol setiap microgateway, dan administrator setiap gateway mengkonfigurasi dan mengelola gateway. Instance microgateway adalah layanan gateway individu yang di-deploy secara independen, yang menangani lalu lintas akses dari setiap kelompok layanan tertentu dan melakukan kontrol akses terkait sesuai dengan pengaturan sisi manajemen. Semua instance microgateway dikontrol oleh satu set sisi manajemen yang sama.

"Dalam hal pemilihan teknologi microgateway, kami merujuk pada beberapa gateway open-source populer di pasar, seperti Kong dan Tyk. Setelah membandingkan popularitas, tumpukan teknologi, dukungan protokol, dan tingkat lainnya, kami akhirnya memilih APISIX sebagai teknologi backend terpenting dari microgateway kami." kata Zhu.

Zhu mengatakan BlueKing memilih APISIX karena diimplementasikan berdasarkan NGINX + Lua, sehingga kinerja keseluruhannya memiliki keunggulan dibandingkan dengan yang berbasis Golang. Selain itu, APISIX sangat menonjol dalam skalabilitas, dan juga mendukung perluasan kemampuan melalui plugin multi-bahasa pemrograman. Banyak kasus penggunaan tipikal telah disaksikan.

Selain itu, berkat kompatibilitas yang hebat, APISIX dapat disesuaikan sesuai kebutuhan BlueKing. Misalnya, berdasarkan APISIX, BlueKing menyesuaikan permukaan kontrol APISIX sesuai dengan persyaratan internal.

BlueKing API Gateway 3.0 Berbasis APISIX

Dalam lingkungan cloud-native, K8s adalah komponen dasar yang paling penting yang perlu diperhatikan. Karena seluruh microgateway dirancang untuk lingkungan cloud-native, versi 3.0 memiliki desain arsitektur baru berdasarkan K8s.

Bagian intinya adalah menggunakan sumber daya kustom CRD yang disediakan oleh K8s untuk mencapai seluruh operasi dan ekspansi API gateway.

Seperti yang ditunjukkan pada gambar di atas, gateway memperkenalkan satu set sumber daya CRD K8s, termasuk BkGatewayStage (lingkungan gateway), BkGatewayService (layanan backend), dll. Melalui CRD ini, BlueKing dapat mengontrol perilaku spesifik dari setiap instance microgateway.

Beberapa "Operator" dalam gambar adalah bagian inti dari arsitektur ini. Di atas adalah layanan Plugin Operators, yang berisi serangkaian operator plugin. Misalnya, Operator yang bertanggung jawab untuk penemuan layanan akan menulis alamat layanan backend yang terdaftar di pusat penemuan layanan ke dalam kluster K8s.

Operator inti di tengah memantau semua sumber daya CRD yang terkait dengan gateway. Reconciler sumber daya bertanggung jawab untuk mengubah konfigurasi gateway menjadi format yang dapat dipahami oleh instance microgateway APISIX, sehingga mencapai manajemen siklus hidup penuh dari microgateway.

Satu set microgateway ini dibagi menjadi dua jenis deployment:

• Gateway bersama: Jenis default, yang di-deploy di platform, dan alamat akses API dihasilkan dan dikelola secara seragam oleh platform.

• Gateway khusus: Pengguna meng-deploy instance "microgateway", yang menjadi "gateway khusus" setelah mengakses platform. Alamat akses API perlu dikelola secara manual, dan lalu lintas mengalir langsung dari "gateway khusus" ke layanan backend.

Hanya ada satu sisi manajemen terpadu, yang kemampuannya, seperti manajemen multi-lingkungan dan kontrol akses, dibagikan oleh semua gateway. Namun, di antara berbagai jenis instance microgateway yang dikelolanya, set fitur yang didukung berbeda satu sama lain.

Mengambil instance gateway bersama sebagai contoh, set fitur yang didukung relatif dasar, yang terutama mencakup autentikasi login terpadu, pembatasan laju, dan dukungan multi-protokol. Tetapi instance gateway khusus independen memiliki kemampuan personalisasi yang unik. Karena gateway khusus dan bisnis berada dalam kluster yang sama, ia dapat dengan cepat mencapai routing dinamis, penemuan layanan kustom, dll., dan menggunakan skalabilitas kuat APISIX untuk menyesuaikan lebih banyak kemampuan.

Berdasarkan arsitektur dan mode di atas, BlueKing API Gateway 3.0 menyediakan fungsi yang lebih kaya dengan dukungan APISIX. Misalnya, manajemen sumber daya, rilis versi, dokumen otomatis, SDK, manajemen izin, observabilitas, pemantauan dan peringatan, serta perlindungan keamanan.

Skenario Praktis BlueKing Gateway 3.0 Menggunakan APISIX

Ada empat skenario praktis tipikal di dalam Tencent: penemuan layanan, autentikasi terpadu, routing dinamis, dan manajemen lisensi klien.

Penemuan Layanan

Penemuan layanan adalah kemampuan dasar yang diperlukan oleh arsitektur mikroservis. Secara internal, ini dapat diimplementasikan melalui sumber daya kustom CRD. Definisi YAML penemuan layanan yang valid ditunjukkan dalam kode di sisi kanan gambar di bawah ini.

Setelah sumber daya CRD di atas ditulis ke dalam kluster K8s, ini akan memicu tindakan terkait dari kontroler yang terkait dengan penemuan layanan. Setelah itu, reconciler dapat menangkap konfigurasi penemuan layanan yang sesuai dan membuat objek program yang terkait dengan penemuan layanan.

Kemudian reconciler membaca informasi alamat yang relevan dari pusat penemuan layanan melalui antarmuka penemuan layanan bawaan seperti Watcher dan Lister dan menulis ulang alamat yang diperoleh kembali ke dalam kluster K8s melalui sumber daya CRD BkGatewayEndpoints.

Setelah beberapa pemrosesan kompleks oleh Operator inti di sebelah kanan, endpoint ini akhirnya disinkronkan ke upstream yang sesuai dengan APISIX. Proses penemuan layanan yang lengkap selesai.

Untuk memudahkan pengembangan, BlueKing mengimplementasikan kerangka kerja penemuan layanan umum, yang menyediakan antarmuka dan spesifikasi pengembangan yang terpadu dan dapat digunakan untuk mendukung jenis skenario penemuan layanan lainnya dengan biaya rendah.

Autentikasi Terpadu

Bagian autentikasi terpadu relatif sederhana. Dalam praktik sehari-hari, ada permintaan dari tiga sumber: browser, platform, dan pengguna individu. Berdasarkan APISIX, BlueKing menyesuaikan plugin autentikasi, BK-Auth, untuk mencapai autentikasi terpadu.

Proses implementasi spesifik ditunjukkan pada gambar di atas. Setelah permintaan, plugin akan membaca informasi kredensial yang relevan dari header dan kemudian secara seragam memanggil layanan autentikasi BK-Auth untuk memverifikasi kredensial dan membaca informasi SaaS yang sesuai. Kemudian plugin akan menggunakan kunci privat yang disepakati dengan backend untuk menerbitkan token JWT dan menuliskannya ke dalam header permintaan, dan akhirnya, menuliskannya ke dalam variabel APISIX.

Selain autentikasi terpadu, ada juga beberapa skenario autentikasi kompleks dalam proyek internal. Fungsi utamanya adalah menilai apakah SaaS memiliki izin ketika SaaS memanggil sumber daya tertentu dari suatu platform. Autentikasi sumber daya terpadu juga diimplementasikan oleh Golang melalui plugin APISIX, seperti yang ditunjukkan pada gambar di bawah ini.

Permintaan klien dapat terlebih dahulu mengambil informasi aplikasi SaaS melalui tautan autentikasi, kemudian berinteraksi dengan plugin autentikasi berbasis RPC saat melewati ext-plugin. Pada saat ini, plugin autentikasi akan langsung mengkueri data yang terkait dengan autentikasi dalam cache, yang disinkronkan oleh sisi manajemen melalui mekanisme penuh dan inkremental, dan kemudian menyelesaikan autentikasi.

Routing Dinamis

Skenario aplikasi routing dinamis tipikal berasal dari platform manajemen kontainer BlueKing. Platform kontainer BlueKing mengelola banyak kluster K8s, beberapa di antaranya adalah kluster layanan dan beberapa adalah kluster data.

Sebagai pengguna, Anda sering perlu meminta APIServers dari kluster ini. Ketika permintaan pengguna masuk ke microgateway, gateway menentukan ke APIServer kluster mana permintaan tersebut akan diteruskan berdasarkan jalur permintaan.

Setelah permintaan masuk, plugin routing dinamis pertama-tama mengekstrak informasi ID kluster, kemudian menulis ulang rute, dan kemudian menentukan apakah kluster terhubung langsung.

Untuk kluster yang tidak terhubung langsung, upstream manajer kluster BCS pertama kali dihasilkan dan kemudian berinteraksi dengan Agen BCS melalui itu, dan akhirnya meneruskan permintaan ke APIServer kluster.

Untuk kluster yang terhubung langsung, prosesnya mirip dengan plugin autentikasi terpadu di atas, dan plugin akan secara berkala menyinkronkan beberapa informasi dasar yang terkait dengan kluster. Setelah menemukan informasi kluster, menghasilkan upstream yang relevan, mendefinisikan ulang logika koneksi melalui plugin APISIX, dan akhirnya mengirim permintaan ke APIServer kluster.

Manajemen Sertifikat Klien

Dalam skenario praktis BlueKing, ada kelas sistem yang menggunakan mode verifikasi sertifikat klien yang lebih kompleks saat mendaftarkan sumber daya ke gateway. Oleh karena itu, jika pengguna ingin meminta sumber dayanya, ia harus menyediakan sertifikat klien yang valid.

Implementasi spesifik ditunjukkan pada gambar di atas. Manajer gateway perlu mengkonfigurasi sertifikat klien yang digunakan oleh gateway untuk lingkungan yang berbeda di sisi manajemen. Setelah konfigurasi, sertifikat akan dipublikasikan ke kluster K8s, di mana microgateway yang sesuai berada.

Proses ini menggunakan beberapa sumber daya CRD dan sumber daya Secret resmi K8s dan akan terus direkonsiliasi oleh layanan Operator inti, seperti menemukan sertifikat yang sesuai berdasarkan nama domain. Konfigurasi sertifikat klien yang efektif akhirnya akan tercermin dalam konfigurasi terkait dari Layanan APISIX. (Seperti yang ditunjukkan dalam kotak merah di kanan atas gambar di atas)

Ringkasan

Apache APISIX adalah gateway API cloud-native open-source, dinamis, skalabel, dan berkinerja tinggi untuk semua API dan mikroservis Anda. Disumbangkan ke Apache Software Foundation oleh API7.ai, APISIX telah berkembang menjadi proyek open-source Apache tingkat atas.

Dengan perkembangan arsitektur mikroservis dan proyek bisnis internal, API gateway sebelumnya tidak lagi memenuhi kebutuhan. Tencent BlueKing tidak hanya menyelesaikan masalah tersebut, tetapi juga menyediakan fitur yang lebih kaya dengan memanfaatkan APISIX.