Praktik API Gateway di Tencent dengan Apache APISIX

Apa itu API Gateway?

Arsitektur tradisional

Sebelum mengintegrasikan dengan API Gateway, ada beberapa cara untuk menggunakan kembali beberapa fungsionalitas umum, seperti:

• Keamanan: autentikasi, otorisasi, anti-replay, anti-tampering, anti-DDoS, dll.
• Keandalan: degradasi layanan, fusing, pembatasan lalu lintas, dan sebagainya.

Dalam arsitektur tradisional, cara paling umum untuk menangani kasus ini adalah dengan memasukkannya ke dalam kerangka layanan dan mengimplementasikannya melalui AOP, seperti yang terlihat pada diagram arsitektur berikut:

Diagram arsitektur tradisional memiliki modul-modul berikut.

• Backend: Layanan backend
• AOP: Lapisan AOP yang dibawa oleh kerangka kerja;
• SD: Pusat Layanan, digunakan untuk penemuan layanan internal. Dalam teknologi cloud-native, kita sering menggunakan Service untuk menggantikan komponen ini;
• LB: Load balancer, kita menggunakannya di batas jaringan sebagai titik masuk untuk lalu lintas eksternal.

Arsitektur semacam ini sangat umum dalam desain tahun-tahun awal, yang melahirkan banyak kerangka layanan yang luas dan komprehensif, seperti Dubbo, SpringCloud, dll., dan kita akan menemukan bahwa sebagian besar memiliki banyak fitur yang serupa.

Keuntungan dari arsitektur ini adalah hubungan antara upstream dan downstream lebih mudah dan lebih jelas, serta mengurangi satu kali penerusan dalam transmisi jaringan. Namun, kekurangannya juga jelas:

• Fitur standar memaksa pembaruan layanan bisnis: karena menggunakan referensi kode, kita harus mengkompilasi ulang layanan bisnis untuk membuat fitur tersebut efektif. Beberapa tim yang tidak mencapai rilis bergulir harus merilis selama waktu senggang bisnis.
• Sulit mengelola versi: Karena kita tidak dapat meningkatkan semua layanan ke versi terbaru setiap kali merilis, setelah beberapa waktu, kinerja berbagai layanan akan tidak konsisten.

Mengapa tidak menempatkan fungsi-fungsi yang sama tersebut dalam layanan mandiri, yang dapat ditingkatkan atau dipelihara secara terpisah?

Mode Gateway

Dibandingkan dengan arsitektur tradisional, kita dapat melihat komponen tambahan antara layanan backend dan LB: Gateway.

Sebuah gateway biasanya mengandung banyak fitur standar dan dapat digunakan kembali, seperti Autentikasi, Manajemen Lalu Lintas, dll. Berikut adalah manfaat yang bisa kita dapatkan:

• Gateway adalah komponen dependen pada sistem, dan kita bisa mendapatkan pengalaman pemeliharaan yang lebih baik.
• Gateway tidak bergantung pada bahasa.

Namun, mode gateway juga memiliki kekurangannya:

• Karena kita memproksi lalu lintas ke gateway terlebih dahulu, kita memiliki satu kali penerusan tambahan dan latensi yang lebih tinggi. Ini akan menyebabkan kompleksitas yang lebih tinggi dalam memecahkan masalah.
• Jika gateway tidak berfungsi dengan benar, ia bisa menjadi bottleneck untuk seluruh sistem.

Bagaimana menyeimbangkan manfaat dan kekurangan dari model gateway adalah tantangan bagi tim teknis. Mari kita lihat bagaimana Tencent OTeam bekerja dengan Apache APISIX.

Pengenalan

OTeam

OTeam Tencent adalah sekelompok tim, dan setiap tim memelihara satu atau beberapa produk teknis. Tujuan mereka adalah membangun mid-platform yang stabil tetapi kuat untuk sistem internal. Salah satu OTeam mendukung distribusi kustomisasi Apache APISIX internal Tencent.

Untuk mengintegrasikan roda yang sama di dalam perusahaan dan menenggelamkan dasar teknis. Tencent menempatkan beberapa produk teknis yang sama sifatnya ke dalam Oteam yang sama, mengintegrasikan staf pemeliharaan dan mengerahkan mereka bersama-sama, sehingga mereka bisa secara bertahap bergabung menjadi satu produk besar dan komprehensif, yaitu Oteam.

Beberapa Oteam memiliki belasan produk di bawahnya, sementara yang lain hanya memiliki satu. Misalnya, Oteam tempat Apache APISIX berada hanya memiliki satu produk, Apache APISIX. Tujuan awal Oteam ini adalah untuk memelihara fitur kustomisasi Apache APISIX di dalam Tencent.

Apache APISIX

Apache APISIX adalah Proyek Tingkat Atas dari Apache Software Foundation, dan berikut adalah beberapa poin penting:

• Apache APISIX adalah API gateway berbasis cloud-native dan dinamis yang dibangun di atas OpenResty, dengan kinerja routing yang lebih tinggi daripada Kong.
• Apache APISIX menyediakan fitur manajemen lalu lintas yang kaya seperti load balancing, upstream dinamis, rilis canary, circuit breaking, autentikasi, observabilitas, dan banyak lagi.
• Apache APISIX pandai menangani lalu lintas utara-selatan tradisional, serta lalu lintas timur-barat antara layanan. Ia juga dapat digunakan sebagai k8s ingress controller.
• Apache APISIX secara default menggunakan ETCD sebagai pusat konfigurasi, yang dapat memperbarui konfigurasi dalam hitungan detik.
• Apache APISIX lulus dari Apache Software Foundation dan hanya membutuhkan beberapa bulan.

Strategi operasional OTeam Tencent

Diagram di atas menunjukkan bagaimana OTeam bekerja dengan komunitas Apache APISIX:

• Pengguna memberikan umpan balik atau permintaan melalui GitHub Issue.
• Anggota OTeam mendiskusikan solusi dalam rapat mingguan atau membalas langsung di Issue.
• Mengimplementasikan fitur atau memperbaiki bug sesuai dengan diskusi.
• Code Review dan pemeriksaan CI, kemudian merilis jika diperlukan.

Proses ini sama seperti proyek Open Source lainnya. Berikut adalah beberapa poin penting:

• Setelah menyelesaikan Issue, insinyur Tencent akan menentukan apakah masalah tersebut juga merupakan masalah umum bagi komunitas. Jika ya, mereka akan mengajukan PR ke komunitas.
• OTeam Tencent akan secara teratur meninjau fitur baru Apache APISIX untuk menentukan apakah itu stabil dan apakah itu juga merupakan titik sakit bagi Tencent. Jika jawabannya ya, ambil kode yang relevan.

Pada awalnya, OTeam akan menyinkronkan kode dengan Apache APISIX setiap 12 jam sehingga kita bisa mengikuti Apache APISIX dengan cepat, tetapi pendekatan ini membawa beberapa masalah:

• Setelah menyinkronkan kode dengan Apache APISIX, kita bisa memastikan peraturan benar tetapi tidak bisa memastikan kode tersebut stabil. Beberapa kesalahan sesekali terjadi dalam kasus konkurensi.
• Kode yang digabungkan terkadang menyebabkan beberapa konflik PR upstream secara logis, tetapi CI Apache APISIX dan OTeam tidak dapat mendeteksi kasus ini. Hanya ketika kita menggabungkan PR ke cabang master kita bisa menemukan sesuatu yang salah terjadi.

Untuk alasan ini, OTeam sekarang beralih ke memilih kode untuk fitur yang diperlukan setelah tinjauan internal.

Tren OTeam

Hingga Mei 2021, OTeam telah menerapkan Apache APISIX untuk lebih dari sepuluh tim di dalam Tencent, dengan lalu lintas permintaan bisnis harian yang sangat besar melebihi satu miliar. Pada saat yang sama, OTeam juga telah mengembangkan lebih dari sepuluh fitur untuk Apache APISIX, termasuk Service Discovery, Konversi Protokol RPC, dan terhubung dengan platform pemantauan.

Pada saat yang sama, OTeam juga telah berkontribusi beberapa fitur standar ke komunitas Apache APISIX. Saat ini, dua anggota tim OTeam juga merupakan PMC dari Apache APISIX, dan OTeam telah berkontribusi lebih dari 50 PR ke komunitas. Kami percaya bahwa OTeam akan terus bekerja sama dengan komunitas Apache APISIX di masa depan.

Fitur Internal OTeam

Titik sakit internal

Tanggung jawab utama OTeam adalah memelihara fitur Apache APISIX untuk Tencent. Mari kita lihat titik sakit apa yang ditemui OTeam.

• Kerangka kerja RPC tidak ramah ke frontend: ada banyak proyek warisan di dalam Tencent yang menggunakan kerangka kerja TARS, ia tidak langsung mendukung protokol HTTP seperti TRPC, ia hanya mendukung protokol TCP paling tradisional dari kerangka kerja RPC, dan konten transport menggunakan protokol biner tertentu. Kita perlu memelihara layanan perantara untuk mengubah antarmuka ini menjadi bentuk HTTP + JSON yang ramah frontend.
• Diversifikasi pusat layanan: Ada banyak Pusat Layanan di layanan internal Tencent, seperti CL5, L5, Polaris, dll. Meskipun kita akan secara bertahap menggunakan Pusat Layanan yang sama, kita akan menggunakan beberapa pusat layanan secara bersamaan selama periode yang diperpanjang ini. Apache APISIX awal tidak mendukung ini.
• Alarm: Sebagai gateway, alarm bukanlah arah yang harus diperhatikannya, tetapi sebagai komponen dasar, alarm harus menjadi komponen yang diperlukan untuk tim. Bagaimana menyelesaikan masalah alarm juga merupakan titik sakit.
• Keamanan: Tencent memiliki jumlah lalu lintas dan persyaratan keamanan yang besar. Banyak produk toC menggunakan OTeam, dan mereka harus menghadapi banyak penyalahgunaan pengguna dan serangan dari jaringan. Kasus paling khas adalah DDos, replay, permintaan yang dimanipulasi, dll. Bisakah kita menyelesaikan masalah ini di lapisan gateway?

Penyelesaian masalah

Diagram di atas berasal dari penyederhanaan kasus penerapan di dalam Tencent. Kita dapat melihat beberapa masalah yang baru saja diajukan telah diselesaikan di OTeam:

• Konversi Protokol: berdasarkan Apache APISIX, OTeam mencapai konversi protokol TRPC dan TARS. Mereka yang tidak melakukan layanan warisan HTTP dapat langsung menggunakan plugin konversi di gateway untuk memenuhi kebutuhan transfer HTTP dan RPC tanpa menulis layanan perantara.
• Beberapa Pusat Layanan: Kami telah berkontribusi fitur ini ke komunitas. Laporan ke platform pemantauan: OTeam Tencent menggunakan plugin untuk terhubung dengan platform pemantauan. Pengguna hanya perlu melakukan beberapa konfigurasi, dan kemudian sistem akan secara otomatis melaporkan metrik, log. Selain itu, pengguna dapat mengonfigurasi kebijakan alarm di platform pemantauan.
• Anti-replay dan anti-tampering: OTeam mengimplementasikan plugin anti-replay dan anti-tampering, memungkinkan bisnis eksternal yang membutuhkan kemampuan ini untuk menggunakannya langsung tanpa perlu penyesuaian untuk melindungi keamanan API mereka.

Kami berharap contoh-contoh ini dapat membantu Anda menjelajahi lebih banyak skenario penggunaan Apache APISIX dan lebih baik menggunakannya sebagai platform yang bermanfaat. Misalnya, seseorang menggunakan gateway untuk mengimplementasikan beberapa spesifikasi API yang wajib sesuai dengan kebijakan Tencent Cloud.

Ringkasan

OTeam membantu tim bisnis menyelesaikan titik sakit mereka dan terus meningkatkan fitur Apache APISIX di dalam Tencent, serta bergerak maju dengan pengembangan komunitas.

Jika tim Anda tidak memiliki gateway, Anda dapat mencari dan mempelajari lebih lanjut tentang Apache APISIX dan dipersilakan untuk berpartisipasi dalam komunitas Apache APISIX.