API Gateway:Routing

Routing layanan tunggal

Dalam mode routing layanan tunggal, gerbang mencocokkan permintaan masuk dengan aturan routing yang dikonfigurasi dan meneruskannya ke satu layanan backend. Contohnya:

• Permintaan yang sesuai dengan aturan /user diteruskan ke layanan user.

• Permintaan yang sesuai dengan aturan /order diteruskan ke layanan order.

Untuk informasi tentang mengonfigurasi layanan, lihat Manage services.

Routing berbasis persentase

Dalam mode routing berbasis persentase, gerbang membagi lalu lintas ke beberapa layanan backend berdasarkan bobot yang dikonfigurasi. Gunakan mode ini saat melakukan migrasi layanan antar registri atau sistem operasi dan maintenance (O&M) tanpa menghentikan lalu lintas.

• Different registries

  Saat meningkatkan registri layanan, deploy replika layanan menggunakan registri baru bersamaan dengan layanan yang sudah ada. Secara bertahap alihkan lalu lintas dari layanan lama ke layanan baru dengan menyesuaikan bobot. Setelah layanan baru stabil, arahkan seluruh lalu lintas ke layanan tersebut. Jika layanan baru mengalami masalah, kembalikan lalu lintas ke layanan lama kapan saja.

  Sebagai contoh, layanan user awalnya menggunakan Nacos sebagai registri. Untuk beralih ke solusi CoreDNS bawaan di Kubernetes (K8s), yang memerlukan sumber daya Service, migrasikan lalu lintas secara bertahap menggunakan routing berbasis persentase.

• Different O&M systems

  Saat memigrasikan layanan dari mesin virtual ke Kubernetes, deploy replika di kluster K8s dan daftarkan dengan nama layanan baru. Registri layanan kemudian berisi dua layanan dengan fungsionalitas yang sama: satu di instans Elastic Compute Service (ECS) dan satu di kluster Alibaba Cloud Container Service for Kubernetes (ACK). Secara bertahap alihkan lalu lintas ke layanan K8s, serta sesuaikan bobot atau kembalikan lalu lintas kapan saja selama proses migrasi.

  Sebagai contoh, layanan user yang menggunakan Nacos sebagai registri dimigrasikan dari instans ECS ke ACK.

Routing berbasis tag

Dalam mode routing berbasis tag, gerbang meneruskan permintaan ke berbagai versi layanan yang sama atau berbeda berdasarkan bobot yang dikonfigurasi atau atribut permintaan. Gunakan mode ini untuk rilis canary, routing multi-lingkungan, dan penerapan berkelanjutan (high-availability). Untuk informasi tentang mengonfigurasi versi layanan, lihat Manage service versions.

• Canary release

  Selama rilis canary, sebagian kecil lalu lintas dialihkan ke versi baru untuk validasi. Jika versi baru berfungsi sesuai harapan, lalu lintas dialihkan secara bertahap hingga versi lama tidak lagi menerima lalu lintas. Routing berbasis tag mendukung dua pendekatan untuk rilis canary:

  Sebagai contoh, layanan user menggunakan layanan kontainer K8s untuk penemuan layanan. Versi saat ini adalah v1, dan versi baru v2 siap dirilis.

  • By percentage

    Entri rute /user menggunakan routing berbasis tag untuk meneruskan permintaan ke layanan user v1. Tambahkan v2 sebagai versi layanan dalam manajemen layanan, lalu tambahkan layanan user v2 sebagai tujuan dalam aturan routing dan konfigurasikan bobot untuk mengatur persentase lalu lintas yang diterimanya.

  • By tag

    Entri rute /user yang ada meneruskan permintaan ke layanan user v1. Buat entri rute /user kedua dengan tag rilis canary—misalnya, header bernama stage dengan nilai gray. Permintaan yang mengandung header ini akan diteruskan ke layanan user v2.

• Tag-based routing

  Satu layanan dapat memiliki beberapa versi jangka panjang, masing-masing melayani permintaan yang sesuai dengan atribut tertentu. Sebagai contoh, permintaan dengan nilai header tertentu dapat diarahkan ke versi layanan spesifik. Pendekatan ini berguna untuk mengelola beberapa lingkungan—seperti test, pre-release, dan production—dalam satu gerbang.

  Sebagai contoh, layanan user menggunakan layanan kontainer K8s untuk penemuan layanan dan memiliki tiga lingkungan: test, pre-release, dan production. Permintaan ke entri rute /user diarahkan sebagai berikut:

  • Jika nilai header stage adalah test, lalu lintas diteruskan ke versi test layanan user.

  • Jika nilai header stage adalah pre, lalu lintas diteruskan ke versi pre-release layanan user.

  • Jika nilai header stage adalah online, lalu lintas diteruskan ke versi production layanan user.

• High-availability deployment

  Untuk meningkatkan ketersediaan layanan, deploy layanan di beberapa kluster K8s dan kelola instans per kluster menggunakan metadata node terkait kluster. Setiap kluster dipetakan ke versi layanan dengan bobot lalu lintas yang dapat dikonfigurasi. Jika suatu kluster gagal, atur bobotnya menjadi 0 untuk mengalihkan seluruh lalu lintas ke kluster lainnya.

  Sebagai contoh, layanan user menggunakan layanan kontainer K8s untuk penemuan layanan dan dideploy di dua kluster ACK, yaitu Kluster A dan Kluster B. Untuk permintaan ke entri rute /user, 80% lalu lintas diteruskan ke Kluster A dan 20% ke Kluster B.

Routing mock

Routing mock mengembalikan respons tetap untuk suatu entri rute tanpa meneruskan permintaan ke layanan backend. Gunakan fitur ini untuk membuka blokir pengembangan antarmuka depan sebelum backend siap, atau untuk memverifikasi bahwa aturan pencocokan permintaan berfungsi dengan benar.

Sebagai contoh, konfigurasikan respons tetap untuk API layanan user sebelum backend dikembangkan agar pengembang antarmuka depan dapat menguji dan men-debug secara mandiri. Setelah backend siap, ubah entri rute dari mock menjadi mengarah ke layanan aktual untuk pengujian end-to-end.

Routing pengalihan (redirection)

Routing pengalihan mengirim klien ke nama domain atau path yang berbeda. Gunakan fitur ini untuk migrasi nama domain atau perubahan path API.

Sebagai contoh, permintaan ke old.example.com/test tiba di gerbang, yang kemudian mengalihkannya ke new.example.com/dev.