Microservices Engine：Mode routing

Routing layanan tunggal

Gateway cloud-native meneruskan permintaan ke layanan backend berdasarkan aturan routing. Untuk informasi lebih lanjut tentang cara mengonfigurasi layanan untuk gateway cloud-native, lihat Tambahkan Layanan.

Gateway mencocokkan permintaan berdasarkan aturan routing yang telah dikonfigurasikan. Sebagai contoh:

• Gateway meneruskan semua permintaan yang cocok dengan aturan routing /user ke layanan pengguna.

• Gateway meneruskan semua permintaan yang cocok dengan aturan routing /order ke layanan pesanan.

Routing berbasis persentase

Gateway cloud-native meneruskan permintaan ke beberapa layanan backend. Trafik didistribusikan ke layanan backend berdasarkan bobot yang dikonfigurasikan untuk setiap layanan. Anda dapat menggunakan routing multi-layanan dalam skenario berikut:

• Registry change

  Saat bisnis berkembang, teknologi baru terus diintegrasikan dan Anda mungkin perlu melakukan perubahan registri. Untuk memastikan kelangsungan bisnis saat melakukan perubahan registri, replika layanan diterapkan. Replika tersebut menggunakan registri baru. Layanan asli dan registri asli tetap dipertahankan. Trafik secara bertahap dialihkan dari layanan asli ke layanan baru. Setelah memverifikasi stabilitas layanan baru, gateway dapat meneruskan semua trafik masuk ke layanan baru. Proses migrasi layanan ini mendukung rollback. Anda dapat mengembalikan trafik ke layanan asli jika layanan baru tidak memenuhi persyaratan.

  Gambar berikut menunjukkan contoh perubahan registri layanan. Dalam contoh ini, layanan pengguna dalam sistem aplikasi beralih dari Nacos ke CoreDNS bawaan untuk Kubernetes. Anda harus menggunakan CoreDNS bersama dengan sumber daya layanan.

  

• O&M system change

  Secara tradisional, sebagian besar layanan diterapkan pada mesin virtual seperti Instance ECS Alibaba Cloud. Dalam beberapa tahun terakhir, Kubernetes muncul sebagai solusi penyebaran alternatif yang menawarkan penyederhanaan O&M dan elastisitas tinggi. Semakin banyak perusahaan yang memigrasikan layanan mereka ke platform manajemen berbasis Kubernetes, seperti Container Service for Kubernetes (ACK) dari Alibaba Cloud. Untuk memastikan migrasi layanan tanpa hambatan, replika layanan dapat diterapkan pada kluster Kubernetes dan didaftarkan dengan nama baru di registri. Dalam hal ini, dua layanan dengan fitur identik ada di registri: satu diterapkan dan berjalan 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. Dalam sistem aplikasi dengan Nacos sebagai registri, layanan pengguna dimigrasikan dari instance ECS ke platform ACK.

  

Routing 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 cara mengonfigurasi versi layanan untuk gateway cloud-native, lihat Kelola Versi Layanan. Anda dapat menggunakan routing berbasis tag dalam skenario berikut:

• Canary release

  Versi baru layanan dirilis secara sering selama siklus 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 trafik kemudian secara bertahap dialihkan ke layanan versi baru.

  Sebagai contoh, penemuan layanan dilakukan pada layanan pengguna yang diterapkan pada kluster ACK dalam 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

    Routing 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 routing berbasis tag. Anda dapat mengonfigurasi bobot untuk menentukan persentase trafik yang diteruskan ke layanan pengguna v2.

    

  • Tags

    Routing 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 berupa header stage dengan nilai gray. Rute ini digunakan untuk meneruskan permintaan dengan header tersebut ke layanan pengguna v2.

    

• Tag-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 berbeda diteruskan ke versi layanan yang berbeda. Routing berbasis tag juga digunakan dalam skenario di mana beberapa lingkungan pengembangan (pengujian, staging, dan produksi) berdampingan. Tag digunakan untuk membedakan permintaan yang ditujukan untuk layanan di lingkungan berbeda.

  Sebagai contoh, dalam sistem aplikasi berikut, penemuan layanan dilakukan pada tiga versi layanan pengguna yang diterapkan pada kluster ACK. Versi layanan tersebut 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 diterapkan pada beberapa kluster Kubernetes. Anda dapat mengelola semua instance layanan berdasarkan kluster berdasarkan 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 lainnya.

  Sebagai contoh, dalam sistem aplikasi berikut, penemuan layanan dilakukan pada layanan pengguna yang diterapkan pada kluster ACK A dan B. Untuk permintaan /user, 80% trafik diteruskan ke layanan pengguna yang diterapkan pada kluster A, dan 20% trafik diteruskan ke layanan pengguna yang diterapkan pada kluster B.

  

Routing mock

Routing mock biasanya digunakan untuk debugging. Anda dapat mengonfigurasi respons tetap untuk 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 pengguna backend belum selesai, respons tetap dikonfigurasikan untuk operasi API layanan pengguna. Pengembang frontend kemudian dapat menguji dan men-debug proses routing. Ketika layanan pengguna backend 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 adalah /test. Gateway cloud-native mengarahkan ulang permintaan dari old.example.com/test ke new.example.com/dev.