Cloud-native API Gateway mendukung berbagai mode perutean, termasuk perutean layanan tunggal, perutean berbasis persentase, perutean berbasis tag, perutean mock, dan pengalihan.
Perutean layanan tunggal
Gateway cloud-native meneruskan permintaan ke layanan backend sesuai aturan perutean. Untuk informasi lebih lanjut tentang pengaturan layanan di Cloud-native API Gateway, lihat Kelola layanan.
Gateway mencocokkan permintaan berdasarkan aturan perutean yang telah dikonfigurasi. Contohnya:
Gateway meneruskan semua permintaan yang cocok dengan aturan perutean /user ke layanan pengguna.
Gateway meneruskan semua permintaan yang cocok dengan aturan perutean /order ke layanan pesanan.
Perutean berbasis persentase
Gateway cloud-native meneruskan permintaan ke beberapa layanan backend. Trafik didistribusikan ke layanan backend berdasarkan bobot yang dikonfigurasikan untuk setiap layanan. Mode ini dapat digunakan dalam skenario berikut:
Registry change
Seiring pertumbuhan bisnis, teknologi baru terus diintegrasikan, sehingga perubahan registri mungkin diperlukan. Untuk memastikan kelangsungan bisnis selama perubahan registri, replika layanan diterapkan menggunakan registri baru, sementara layanan asli dipertahankan. Trafik secara bertahap dialihkan dari layanan asli ke layanan baru. Setelah stabilitas layanan baru diverifikasi, gateway dapat meneruskan semua trafik masuk ke layanan baru. Proses migrasi ini mendukung rollback, sehingga trafik dapat dikembalikan ke layanan asli jika diperlukan.
Gambar berikut menunjukkan contoh perubahan registri layanan. Dalam contoh ini, layanan pengguna di sistem aplikasi beralih dari Nacos ke CoreDNS bawaan Kubernetes. Anda harus menggunakan CoreDNS bersama dengan sumber daya layanan.
O&M system change
Secara tradisional, sebagian besar layanan ditempatkan pada mesin virtual seperti Instance ECS (Elastic Compute Service) Alibaba Cloud. Dalam beberapa tahun terakhir, Kubernetes muncul sebagai solusi penyebaran alternatif yang menawarkan penyederhanaan O&M dan elastisitas tinggi. Semakin banyak perusahaan memindahkan layanan mereka ke platform manajemen berbasis Kubernetes, seperti Container Service for Kubernetes (ACK) Alibaba Cloud. Untuk memastikan migrasi layanan tanpa hambatan, replika layanan dapat ditempatkan di kluster Kubernetes dan didaftarkan dengan nama baru di registri. Dalam hal ini, dua layanan dengan fitur identik ada di registri: satu ditempatkan pada instance ECS, dan yang lainnya pada kluster Kubernetes. Trafik dialihkan dari layanan pada instance ECS ke layanan pada kluster Kubernetes. Selama migrasi, Anda dapat menyesuaikan persentase trafik yang dialihkan dan bahkan mengembalikan semua trafik ke layanan pada instance ECS.
Gambar berikut menunjukkan contoh perubahan sistem O&M. Di sistem aplikasi dengan Nacos sebagai registri, layanan pengguna dipindahkan dari instance ECS ke platform ACK.
Perutean berbasis tag
Gateway cloud-native meneruskan permintaan ke versi berbeda dari layanan yang sama atau berbeda. Trafik didistribusikan berdasarkan bobot yang dikonfigurasikan untuk setiap versi layanan. Untuk informasi lebih lanjut tentang pengaturan versi layanan di Cloud-native API Gateway, lihat Kelola versi layanan. Mode ini dapat digunakan dalam skenario berikut:
Canary release
Versi baru layanan dirilis secara berkala selama siklus hidup pengembangan. Anda dapat menggunakan kebijakan rilis canary untuk meluncurkan pembaruan layanan sambil memastikan stabilitas dan kelangsungan layanan. Dalam rilis canary, sejumlah kecil trafik pertama-tama dialihkan ke layanan versi baru untuk verifikasi. Jika hasilnya sesuai harapan, sisanya kemudian secara bertahap dialihkan ke layanan versi baru.
Sebagai contoh, penemuan layanan dilakukan pada layanan pengguna yang ditempatkan pada kluster ACK di sistem aplikasi berikut. Layanan saat ini menjalankan versi v1, dan versi baru v2 direncanakan untuk dirilis dan diluncurkan. Anda dapat melakukan rilis canary berdasarkan salah satu item berikut:
Percentages
Perutean berbasis tag digunakan untuk meneruskan permintaan /user ke layanan pengguna v1. Anda dapat menambahkan layanan pengguna v2 pada halaman manajemen layanan di konsol Microservices Engine (MSE), lalu menambahkan layanan pengguna v2 ke layanan tujuan untuk perutean berbasis tag. Anda dapat mengonfigurasi bobot untuk menentukan persentase trafik yang diteruskan ke layanan pengguna v2.
Tags
Perutean berbasis tag digunakan untuk meneruskan permintaan /user ke Layanan Pengguna v1. Anda dapat menambahkan rute /user dan mengonfigurasi tag yang menunjukkan bahwa rute ini digunakan untuk rilis canary. Sebagai contoh, tag bisa menjadi header stage dengan nilai gray. Rute ini digunakan untuk meneruskan permintaan dengan header tersebut ke layanan pengguna v2.
Label-based routing
Dalam lingkungan produksi, beberapa versi layanan mungkin ada secara paralel untuk jangka waktu yang lama, dan fitur layanan serta permintaan yang berlaku bervariasi menurut versi. Sebagai contoh, ketika operasi API yang sama dipanggil, permintaan dengan nilai header yang berbeda diteruskan ke versi layanan yang berbeda. Perutean berbasis tag juga digunakan dalam skenario di mana beberapa lingkungan pengembangan (pengujian, staging, dan produksi) berada bersamaan. Tag digunakan untuk membedakan permintaan yang ditujukan untuk layanan di lingkungan yang berbeda.
Sebagai contoh, dalam sistem aplikasi berikut, penemuan layanan dilakukan pada tiga versi layanan pengguna yang ditempatkan pada kluster ACK. Versi layanan sesuai dengan lingkungan pengujian, staging, dan produksi, masing-masing. Untuk permintaan /user:
Jika nilai header stage adalah test, trafik diteruskan ke layanan pengguna di lingkungan pengujian.
Jika nilai header stage adalah pre, trafik diteruskan ke layanan pengguna di lingkungan staging.
Jika nilai header stage adalah online, trafik diteruskan ke layanan pengguna di lingkungan produksi.
High-availability deployment
Untuk memastikan ketersediaan layanan, layanan identik mungkin ditempatkan di beberapa kluster Kubernetes. Anda dapat mengelola semua instance layanan berdasarkan kluster menggunakan metadata kluster pada node. Anda juga dapat menyesuaikan bobot untuk mendistribusikan trafik ke kluster. Saat sebuah kluster gagal, Anda dapat mengatur bobot distribusi trafik menjadi 0 untuk kluster tersebut, dan semua trafik kemudian diteruskan ke kluster lain.
Sebagai contoh, dalam sistem aplikasi berikut, penemuan layanan dilakukan pada layanan pengguna yang ditempatkan pada kluster ACK A dan B. Untuk permintaan /user, 80% trafik diteruskan ke layanan pengguna yang ditempatkan pada kluster A, dan 20% trafik diteruskan ke layanan pengguna yang ditempatkan pada kluster B.
Perutean Mock
Perutean mock biasanya digunakan untuk debugging. Anda dapat mengonfigurasi respons tetap untuk suatu rute untuk memverifikasi apakah permintaan diteruskan dengan benar. Ini membantu pengembangan frontend dan backend berjalan secara paralel dan mempercepat iterasi pengembangan.
Sebagai contoh, dalam sistem aplikasi berikut, ketika layanan backend pengguna belum selesai, respons tetap dikonfigurasi untuk operasi API layanan pengguna. Pengembang frontend kemudian dapat menguji dan men-debug proses perutean. Ketika layanan backend pengguna selesai, Anda dapat mengubah nilai parameter Type dari Mock ke layanan pengguna, lalu personel frontend dan backend dapat melakukan debugging bersama.
Pengalihan
Gateway cloud-native dapat mengarahkan ulang permintaan ke nama domain atau jalur lain. Pengalihan sering digunakan dalam skenario transfer nama domain dan perubahan API.
Sebagai contoh, nama domain layanan saat ini adalah old.example.com dan jalurnya saat ini adalah /test. Gateway cloud-native mengarahkan ulang permintaan dari old.example.com/test ke new.example.com/dev.