Ringkasan pengelolaan traffic lanjutan untuk API load balancing

Catatan: Panduan ini hanya mendukung Cloud Service Mesh dengan Google Cloud API dan tidak mendukung Istio API. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Dokumen ini ditujukan bagi administrator platform atau mesh dan developer layanan yang memiliki pemahaman tingkat menengah hingga lanjutan terhadap konsep Cloud Service Mesh dan mesh layanan, serta untuk menentukan dan mengonfigurasi cara traffic dikelola dalam deployment Cloud Service Mesh. Dokumen ini hanya berlaku untuk API load balancing, bukan untuk API perutean layanan. Jika deployment Cloud Service Mesh Anda menggunakan API perutean layanan, lihat Ringkasan pengelolaan traffic lanjutan.

Cloud Service Mesh menyediakan kemampuan pengelolaan traffic lanjutan yang memberi Anda kontrol terperinci atas cara penanganan traffic. Cloud Service Mesh mendukung kasus penggunaan berikut:

• Perutean traffic permintaan yang mendetail ke satu atau beberapa layanan
• Pemisahan traffic berbasis bobot untuk mendistribusikan traffic di beberapa layanan
• Kebijakan pencerminan traffic yang mengirim permintaan ke satu layanan proses debug dan menyalin ke layanan lain
• Menyesuaikan distribusi traffic di seluruh backend layanan untuk meningkatkan load balancing

Kemampuan pengelolaan traffic lanjutan ini memungkinkan Anda memenuhi tujuan ketersediaan dan performa. Salah satu manfaat menggunakan Cloud Service Mesh untuk kasus penggunaan ini adalah Anda dapat memperbarui cara pengelolaan traffic tanpa perlu mengubah kode aplikasi.

• Saat Anda menggunakan proxy HTTP target untuk mengonfigurasi proxy Envoy guna mengirim permintaan HTTP, semua kemampuan dalam dokumen ini akan tersedia.

• Saat Anda menggunakan layanan atau aplikasi gRPC tanpa proxy dengan Cloud Service Mesh, beberapa kemampuan tersebut tidak akan tersedia.

• Jika Anda menggunakan proxy TCP target untuk mengonfigurasi proxy Envoy guna mengirim permintaan TCP, tidak ada kemampuan yang tersedia karena tidak ada peta URL dalam konfigurasi dengan proxy TCP target.

Untuk mengetahui detail selengkapnya, lihat halaman Fitur.

Untuk mengonfigurasi pengelolaan traffic lanjutan, gunakan peta aturan perutean dan resource layanan backend yang sama dengan yang Anda gunakan saat menyiapkan Cloud Service Mesh. Cloud Service Mesh kemudian akan mengonfigurasi proxy Envoy dan aplikasi gRPC tanpa proxy untuk menerapkan kebijakan pengelolaan traffic lanjutan yang Anda siapkan.

Pada intinya, Anda perlu melakukan tindakan berikut:

1. Konfigurasikan peta aturan perutean untuk melakukan hal berikut, berdasarkan karakteristik permintaan keluar:

   1. Pilih layanan backend yang permintaannya dirutekan.

   2. Jika ingin, lakukan tindakan tambahan.

2. Konfigurasi layanan backend untuk mengontrol cara traffic didistribusikan ke backend dan endpoint setelah layanan tujuan dipilih.

Konfigurasi pemfilteran

Salah satu tanggung jawab utama Cloud Service Mesh adalah menghasilkan informasi konfigurasi dari aturan penerusan, proxy target, dan peta URL, lalu mengirim informasi tersebut ke klien Cloud Service Mesh, misalnya, proxy Envoy dan aplikasi gRPC. Cloud Service Mesh mengontrol mesh layanan Anda dengan mengirimkan informasi konfigurasi ke kliennya yang memberi tahu mereka cara berperilaku dan cara merutekan traffic. Cloud Service Mesh adalah bidang kontrol.

Saat Anda membuat atau memperbarui informasi konfigurasi di Cloud Service Mesh, Cloud Service Mesh akan menerjemahkan konfigurasi ini ke dalam bahasa yang dapat dipahami kliennya. Secara default, Cloud Service Mesh membagikan konfigurasi ini dengan semua kliennya. Dalam beberapa kasus, Anda mungkin perlu menyesuaikan klien Mesh Layanan Cloud mana yang menerima informasi konfigurasi tertentu, dengan kata lain, memfilter konfigurasi ke klien tertentu.

Meskipun ini adalah kemampuan lanjutan, contoh berikut menggambarkan kapan konfigurasi pemfilteran dapat membantu Anda:

• Organisasi Anda menggunakan model jaringan VPC Bersama, dan beberapa tim menggunakan Cloud Service Mesh di berbagai project layanan. Jika ingin mengisolasi konfigurasi dari project layanan lain, Anda dapat memfilter konfigurasi sehingga klien Cloud Service Mesh tertentu hanya menerima subset konfigurasi.
• Anda memiliki sangat banyak aturan rute dan layanan yang dikonfigurasi di Cloud Service Mesh dan Anda ingin menghindari pengiriman konfigurasi dalam jumlah yang sangat besar ke setiap klien Cloud Service Mesh. Perlu diingat bahwa klien yang perlu mengevaluasi permintaan keluar menggunakan konfigurasi yang besar dan kompleks mungkin berperforma kurang baik dibandingkan klien yang hanya perlu mengevaluasi permintaan dengan menggunakan konfigurasi yang disederhanakan.

Pemfilteran konfigurasi didasarkan pada konsep filter metadata:

1. Saat klien Cloud Service Mesh terhubung, klien tersebut akan menampilkan informasi dari file bootstrap-nya ke Cloud Service Mesh.
2. Informasi ini berisi konten kolom metadata, dalam bentuk key-value pair, yang Anda tentukan dalam file bootstrap saat men-deploy proxy Envoy dan aplikasi gRPC.
3. Anda dapat menambahkan filter metadata pada aturan penerusan. Seluruh konfigurasi yang tertaut ke aturan penerusan akan difilter.
4. Anda dapat menambahkan filter metadata pada peta URL. Filter metadata diterapkan berdasarkan setiap jalur.
5. Cloud Service Mesh hanya membagikan konfigurasi dengan klien yang menyajikan metadata yang cocok dengan kondisi filter metadata.

Guna mengetahui informasi cara mengonfigurasi filter metadata untuk Envoy, lihat Menyiapkan pemfilteran konfigurasi berdasarkan pencocokan MetadataFilter.

Tindakan dan pemilihan rute traffic

Di Cloud Service Mesh, peta aturan perutean mengacu pada kombinasi resource aturan penerusan, proxy target, dan peta URL. Semua kemampuan pengelolaan traffic lanjutan yang terkait dengan perutean dan tindakan dikonfigurasi menggunakan peta URL.

Bagian berikut menjelaskan fitur pengelolaan traffic lanjutan yang dapat Anda siapkan di peta aturan perutean.

Penanganan permintaan

Saat klien mengirim permintaan, permintaan tersebut akan ditangani seperti yang dijelaskan dalam langkah-langkah berikut:

1. Permintaan tersebut dicocokkan dengan peta aturan perutean tertentu seperti berikut:

   • Jika Anda menggunakan Envoy:

     • Alamat IP dan port tujuan permintaan dibandingkan dengan alamat IP dan port aturan penerusan di semua peta aturan perutean. Hanya peta aturan pemilihan rute dengan aturan penerusan yang memiliki skema load balancing INTERNAL_SELF_MANAGED yang dipertimbangkan.
     • Aturan penerusan yang cocok dengan permintaan tersebut mereferensikan proxy HTTP atau gRPC target, yang merujuk ke peta URL. Peta URL ini berisi informasi yang digunakan untuk pemilihan rute dan tindakan.

   • Jika Anda menggunakan gRPC tanpa proxy:

     • Klien gRPC yang menggunakan skema resolusi nama xds tidak melakukan pencarian DNS untuk me-resolve nama host di URI saluran. Sebagai gantinya, klien tersebut menyelesaikan hostname[:port] dalam URI target dengan mengirimkan permintaan LDS ke Cloud Service Mesh.
     • Hanya port aturan penerusan dengan skema load balancing INTERNAL_SELF_MANAGED yang dibandingkan dengan port di URI target (misalnya, xds:///example.hostname:8080). Alamat IP aturan penerusan tidak digunakan. Nilai default port adalah 80 jika tidak ada port yang ditentukan dalam URI target.
     • Aturan penerusan yang cocok dengan permintaan merujuk ke proxy gRPC target, yang mereferensikan peta URL. Peta URL ini berisi informasi yang digunakan untuk pemilihan rute dan tindakan.
     • Jika lebih dari satu aturan penerusan cocok dengan permintaan, peta URL yang berisi aturan host yang cocok dengan hostname[:port] dalam URI target akan digunakan untuk pemilihan rute dan tindakan.

2. Jika peta URL yang sesuai ditentukan, peta URL akan dievaluasi untuk menentukan layanan backend tujuan dan, jika perlu, menerapkan tindakan.

3. Setelah layanan backend tujuan dipilih, traffic didistribusikan di antara backend atau endpoint untuk layanan backend tujuan tersebut, berdasarkan konfigurasi di resource layanan backend.

Langkah kedua dijelaskan di bagian berikut, Pemilihan rute sederhana berdasarkan host dan jalur. Langkah ketiga dibahas di Pemilihan rute dan tindakan lanjutan.

Perutean sederhana berdasarkan host dan jalur

Cloud Service Mesh mendukung skema perutean yang disederhanakan dan skema yang lebih canggih. Dalam skema sederhana, Anda menentukan host dan, secara opsional, jalur. Host dan jalur permintaan dievaluasi untuk menentukan layanan yang akan menjadi tujuan rute permintaan:

• Host permintaan adalah bagian nama domain dari URL—misalnya, bagian host URL http://example.com/video/ adalah example.com.
• Jalur permintaan adalah bagian dari URL yang mengikuti nama host. Misalnya, bagian jalur URL http://example.com/video/ adalah /video.

Anda dapat menyiapkan perutean sederhana berdasarkan host dan jalur di peta aturan perutean, yang terdiri dari berikut ini:

• Aturan penerusan global
• Proxy HTTP target, proxy HTTPS target, atau proxy gRPC target
• Peta URL

Sebagian besar konfigurasi dilakukan di peta URL. Setelah membuat peta aturan perutean awal, Anda hanya perlu mengubah bagian peta URL dari peta aturan perutean. Dalam diagram berikut, aturan jalur memiliki tindakan yang mirip dengan tindakan dalam diagram berikutnya.

Pemilihan rute berdasarkan host dan resource jalur (klik untuk memperbesar)

Aturan yang paling sederhana adalah aturan default, yang mengharuskan Anda hanya menentukan aturan host karakter pengganti (*) dan pencocok jalur dengan layanan default. Setelah membuat aturan default, Anda dapat menambahkan aturan lain yang menentukan host dan jalur yang berbeda. Permintaan keluar dievaluasi berdasarkan aturan berikut:

• Jika host permintaan (seperti example.com) cocok dengan aturan host:

  1. Berikutnya, pencocok jalur akan dievaluasi.
  2. Setiap pencocok jalur berisi satu atau beberapa aturan jalur yang dievaluasi berdasarkan jalur permintaan.
  3. Jika ditemukan kecocokan, permintaan akan dirutekan ke layanan yang ditentukan dalam aturan jalur.
  4. Jika aturan host cocok, tetapi tidak ada aturan jalur yang cocok, permintaan akan diarahkan ke layanan default yang dimuat oleh setiap pencocok jalur.

• Jika permintaan tidak cocok dengan aturan host mana pun yang Anda tentukan, permintaan akan dirutekan ke layanan yang ditentukan dalam aturan default.

Untuk mengetahui informasi selengkapnya tentang kolom resource peta URL dan cara kerjanya, lihat halaman urlMaps REST API.

Tindakan dan pemilihan rute lanjutan

Jika Anda ingin melakukan lebih dari sekadar merutekan permintaan berdasarkan host dan jalur permintaan, Anda dapat menyiapkan aturan lanjutan untuk merutekan permintaan dan melakukan tindakan.

Pemilihan rute lanjutan (klik untuk memperbesar)

Pada tingkat tinggi, pemilihan rute dan tindakan lanjutan berfungsi sebagai berikut:

1. Seperti pada pemilihan rute sederhana, host permintaan dibandingkan dengan aturan host yang Anda konfigurasi di peta URL. Jika host permintaan cocok dengan aturan host, pencocok jalur aturan host akan dievaluasi.
2. Pencocok jalur berisi satu atau beberapa aturan rute yang dievaluasi berdasarkan permintaan. Aturan rute ini dievaluasi berdasarkan urutan prioritas dengan mencocokkan atribut permintaan (parameter host, jalur, header, dan kueri) sesuai dengan kondisi pencocokan tertentu—misalnya, pencocokan awalan.
3. Setelah aturan rute dipilih, Anda dapat menerapkan tindakan. Tindakan default-nya adalah mengarahkan permintaan ke satu layanan tujuan, tetapi Anda juga dapat mengonfigurasi tindakan lainnya.

Pemilihan rute lanjutan

Perutean lanjutan mirip dengan perutean sederhana yang dijelaskan sebelumnya, kecuali bahwa Anda dapat menentukan prioritas aturan dan kondisi kecocokan tambahan.

Dengan pemilihan rute lanjutan, Anda harus menentukan prioritas unik untuk setiap aturan. Prioritas ini menentukan urutan evaluasi aturan rute, dengan nilai prioritas yang lebih rendah lebih diutamakan daripada nilai prioritas yang lebih tinggi. Setelah permintaan cocok dengan aturan, aturan akan diterapkan dan aturan lainnya akan diabaikan.

Perutean lanjutan juga mendukung kondisi pencocokan tambahan. Misalnya, Anda dapat menentukan bahwa aturan cocok dengan header permintaan jika nama header sama persis atau hanya sebagian—misalnya, berdasarkan awalan atau akhiran. Aturan dapat mencocokkan berdasarkan evaluasi nama header terhadap ekspresi reguler atau berdasarkan kriteria lain seperti memeriksa keberadaan header.

Guna mengetahui detail dan kondisi pencocokan tambahan untuk headerMatches dan queryParameterMatches, lihat halaman REST API urlMaps.

Dengan menggabungkan parameter host, jalur, header, dan kueri dengan prioritas dan kondisi pencocokan, Anda dapat membuat aturan yang sangat ekspresif yang sesuai dengan persyaratan pengelolaan traffic yang tepat. Untuk mengetahui detailnya, lihat tabel berikut.

	Aplikasi berbasis HTTP	Aplikasi berbasis gRPC
Host HTTP versus host gRPC	Host adalah bagian nama domain dari URL yang menjadi tujuan panggilan aplikasi. Misalnya, bagian host dari URL http://example.com/video/ adalah example.com.	Host adalah nama yang digunakan klien dalam URI saluran untuk terhubung ke layanan tertentu. Misalnya, bagian host URI saluran xds:///example.com adalah example.com.
Jalur HTTP versus jalur gRPC	Jalur adalah bagian dari URL yang mengikuti nama host. Misalnya, bagian jalur URL http://example.com/video adalah /video.	Jalur ini ada di header :path dari permintaan HTTP/2 dan terlihat seperti /SERVICE_NAME/METHOD_NAME. Misalnya, jika Anda memanggil metode Download pada layanan gRPC Example, isi header :path akan terlihat seperti /Example/Download.
Header gRPC (metadata) lainnya		gRPC mendukung pengiriman metadata antara klien gRPC dan server gRPC untuk memberikan informasi tambahan tentang panggilan RPC. Metadata ini berbentuk key-value pair yang dibawa sebagai header dalam permintaan HTTP/2.

Tindakan

Cloud Service Mesh dapat Anda gunakan untuk menentukan tindakan yang dilakukan dengan proxy Envoy atau aplikasi gRPC tanpa proxy saat menangani permintaan. Tindakan berikut dapat dikonfigurasi menggunakan Cloud Service Mesh.

Catatan: Semua kemampuan berikut tersedia saat Anda menggunakan Envoy dengan Cloud Service Mesh. Beberapa kemampuan belum tersedia saat Anda menggunakan aplikasi gRPC tanpa proxy dengan Cloud Service Mesh. Untuk mengetahui detail selengkapnya, lihat halaman Fitur dan halaman Batasan dengan gRPC tanpa proxy.

Tindakan	Nama kolom API	Deskripsi
Pengalihan	urlRedirect	Menampilkan kode respons 3xx yang dapat dikonfigurasi. Kode ini juga menetapkan header respons Location dengan URI yang sesuai, menggantikan host dan jalur seperti yang ditentukan dalam tindakan pengalihan.
Penulisan ulang URL	urlRewrite	Menulis ulang bagian nama host URL, bagian jalur URL, atau keduanya, sebelum mengirim permintaan ke layanan backend yang dipilih.
Transformasi header	headerAction	Menambahkan atau menghapus header permintaan sebelum mengirim permintaan ke layanan backend. Juga dapat menambahkan atau menghapus header respons setelah menerima respons dari layanan backend.
Pencerminan traffic	requestMirrorPolicy	Selain meneruskan permintaan ke layanan backend yang dipilih, kirimkan permintaan yang identik ke layanan backend duplikasi yang dikonfigurasi secara aktifkan dan lupakan. Load balancer tidak menunggu respons dari backend yang akan dikirimi permintaan yang dicerminkan. Pencerminan berguna untuk menguji versi baru layanan backend. Anda juga dapat menggunakannya untuk men-debug error produksi pada versi debug layanan backend, bukan pada versi produksi.
Pemisahan traffic berbasis bobot	weightedBackendServices	Mengizinkan traffic untuk aturan yang cocok didistribusikan ke beberapa layanan backend, sebanding dengan bobot yang ditentukan pengguna yang ditetapkan ke masing-masing layanan backend. Kemampuan ini berguna untuk mengonfigurasi deployment bertahap atau pengujian A/B. Misalnya, tindakan rute dapat dikonfigurasi sedemikian rupa sehingga 99% traffic dikirim ke layanan yang menjalankan versi stabil dari sebuah aplikasi, sementara 1% traffic dikirim ke layanan terpisah yang menjalankan versi lebih baru dari aplikasi tersebut.
Upaya coba lagi	retryPolicy	Mengonfigurasi kondisi saat load balancer mencoba ulang permintaan yang gagal, lama waktu load balancer menunggu sebelum mencoba ulang, dan jumlah maksimum percobaan ulang yang diizinkan.
Timeout	timeout	Menentukan waktu tunggu untuk rute yang dipilih. Waktu tunggu dihitung sejak permintaan diproses sepenuhnya hingga respons diproses sepenuhnya. Waktu tunggu mencakup semua percobaan ulang.
Injeksi kesalahan	faultInjectionPolicy	Memberikan error saat melayani permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, overload layanan, kegagalan layanan, dan partisi jaringan. Fitur ini berguna untuk menguji ketahanan layanan terhadap kesalahan yang disimulasikan.
Kebijakan keamanan	corsPolicy	Kebijakan cross-origin resource sharing (CORS) menangani setelan untuk menerapkan permintaan CORS.

Untuk mengetahui informasi selengkapnya tentang tindakan dan cara kerjanya, lihat halaman urlMaps REST API.

Di setiap aturan rute, Anda dapat menentukan salah satu tindakan rute berikut (disebut sebagai Primary actions di Konsol Google Cloud):

• Rutekan traffic ke satu layanan (service)
• Memisahkan traffic di antara beberapa layanan (weightedBackendServices)
• URL Pengalihan (urlRedirect)

Selain itu, Anda dapat menggabungkan salah satu tindakan rute yang disebutkan sebelumnya dengan satu atau beberapa tindakan rute berikut (disebut sebagai Tindakan add-on di Konsol Google Cloud):

• Memanipulasi header permintaan/respons (headerAction)
• Duplikasi traffic (requestMirrorPolicy)
• Menulis ulang host URL, jalur, atau keduanya (urlRewrite)
• Coba lagi permintaan yang gagal (retryPolicy)
• Setel waktu tunggu (timeout)
• Membuat kesalahan pada persentase traffic (faultInjectionPolicy)
• Tambahkan kebijakan CORS (corsPolicy)

Karena tindakan dikaitkan dengan aturan rute tertentu, proxy Envoy atau aplikasi gRPC tanpa proxy dapat menerapkan tindakan yang berbeda berdasarkan permintaan yang ditanganinya.

Mendistribusikan traffic di antara backend layanan

Seperti yang dibahas dalam Penanganan permintaan, saat klien menangani permintaan keluar, klien akan memilih layanan tujuan terlebih dahulu. Setelah memilih layanan tujuan, layanan perlu mencari tahu backend atau endpoint yang harus menerima permintaan.

Mendistribusikan traffic di antara backend (klik untuk memperbesar)

Dalam diagram sebelumnya, Aturan telah disederhanakan. Aturan biasanya berupa aturan host, pencocok jalur, dan satu atau beberapa aturan jalur atau rute. Layanan tujuan adalah Layanan(Backend). Backend 1, ..., dan Backend n menerima dan menangani permintaan. Backend ini dapat berupa, misalnya, instance virtual machine (VM) Compute Engine yang menghosting kode aplikasi sisi server Anda.

Secara default, klien yang menangani permintaan akan mengirim permintaan ke backend responsif terdekat yang memiliki kapasitas. Untuk menghindari kelebihan beban pada backend tertentu, pengujian ini menggunakan algoritma load-balancing round robin untuk melakukan load balancing pada permintaan berikutnya di backend lain dari layanan tujuan. Namun, dalam beberapa kasus, Anda mungkin menginginkan kontrol yang lebih mendetail atas perilaku ini.

Load balancing, afinitas sesi, dan perlindungan backend

Anda dapat menetapkan kebijakan distribusi traffic berikut di setiap layanan.

Kebijakan	Nama kolom API	Deskripsi
Mode load balancing	balancingMode	Mengontrol cara grup endpoint jaringan (NEG) atau grup instance terkelola (MIG) dipilih setelah layanan tujuan dipilih. Anda dapat mengonfigurasi mode penyeimbangan untuk mendistribusikan beban berdasarkan koneksi serentak dan rasio permintaan.
Kebijakan load balancing	localityLbPolicy	Menetapkan algoritma load balancing yang digunakan untuk mendistribusikan traffic di antara backend dalam NEG atau MIG. Untuk mengoptimalkan performa, Anda dapat memilih dari berbagai algoritma (seperti round robin atau permintaan paling sedikit).
Afinitas sesi	sessionAffinity	Memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama backend responsif dan memiliki kapasitas. Cloud Service Mesh mendukung empat opsi afinitas sesi: alamat IP klien, berbasis cookie HTTP, berbasis header HTTP, dan afinitas cookie yang dihasilkan (yang dihasilkan oleh Cloud Service Mesh sendiri).
Hash konsisten	consistentHash	Memberikan afinitas sesi ringan berdasarkan header HTTP, cookie, atau properti lainnya.
Pemutus rangkaian	circuitBreakers	Menetapkan batas atas volume koneksi dan permintaan per koneksi ke layanan backend.
Deteksi outlier	outlierDetection	Menentukan kriteria untuk (1) menghapus backend atau endpoint yang tidak responsif dari MIG atau NEG, dan (2) menambahkan kembali backend atau endpoint jika dianggap cukup sehat untuk menerima traffic lagi. Health check yang terkait dengan layanan menentukan apakah backend atau endpoint dianggap responsif.

Untuk informasi selengkapnya tentang berbagai opsi distribusi traffic dan cara kerjanya, lihat halaman REST API backendServices.

Contoh kasus penggunaan

Pengelolaan traffic lanjutan menangani banyak kasus penggunaan. Bagian ini memberikan beberapa contoh tingkat tinggi.

Anda dapat menemukan contoh lainnya, termasuk kode contoh, di panduan Mengonfigurasi pengelolaan traffic lanjutan dan Menyiapkan layanan gRPC tanpa proxy dengan pengelolaan traffic lanjutan.

Pemilihan rute traffic yang mendetail untuk personalisasi

Anda dapat mengarahkan traffic ke layanan berdasarkan parameter permintaan. Misalnya, Anda dapat menggunakan layanan ini untuk memberikan pengalaman yang lebih dipersonalisasi bagi pengguna Android. Dalam diagram berikut, Cloud Service Mesh mengonfigurasi mesh layanan Anda untuk mengirim permintaan dengan header user-agent:Android ke layanan Android Anda, bukan ke layanan generik.

Pemilihan rute berdasarkan header user-agent yang ditetapkan ke Android (klik untuk memperbesar)

Pemisahan traffic berbasis bobot untuk deployment yang lebih aman

Men-deploy versi baru dari layanan produksi yang ada dapat berisiko. Meskipun pengujian telah lulus di lingkungan pengujian, Anda mungkin tidak ingin langsung mengarahkan semua pengguna ke versi baru.

Cloud Service Mesh dapat Anda gunakan untuk menentukan pemisahan traffic berbasis bobot untuk mendistribusikan traffic di beberapa layanan. Misalnya, Anda dapat mengirim 1% traffic ke versi baru layanan, memantau bahwa semuanya berfungsi, lalu secara bertahap meningkatkan proporsi traffic yang menuju ke layanan baru.

Pemisahan traffic berbasis bobot Cloud Service Mesh (klik untuk memperbesar)

Pencerminan traffic untuk proses debug

Saat Anda men-debug masalah, sebaiknya kirim salinan traffic produksi ke layanan proses debug. Dengan Cloud Service Mesh, Anda dapat menyiapkan kebijakan pencerminan permintaan sehingga permintaan dikirim ke satu layanan dan salinan permintaan tersebut dikirim ke layanan lain.

Pencerminan traffic Cloud Service Mesh (klik untuk memperbesar)

Load balancing yang disesuaikan untuk performa

Bergantung pada karakteristik aplikasi, Anda mungkin dapat meningkatkan performa dan ketersediaan dengan menyesuaikan cara traffic didistribusikan di seluruh backend layanan. Dengan Cloud Service Mesh, Anda dapat menerapkan algoritma load balancing lanjutan sehingga traffic didistribusikan sesuai dengan kebutuhan Anda.

Diagram berikut, berbeda dengan diagram sebelumnya, menampilkan layanan backend tujuan (Layanan Produksi) dan backend untuk layanan backend tersebut (Virtual Machine 1, Virtual Machine 2, Virtual Machine 3). Dengan pengelolaan traffic lanjutan, Anda dapat mengonfigurasi cara layanan backend tujuan dipilih dan cara traffic didistribusikan di antara backend untuk layanan tujuan tersebut.

Load balancing Cloud Service Mesh(klik untuk memperbesar)

Langkah selanjutnya

• Untuk membaca info selengkapnya tentang peta URL, lihat Ringkasan peta URL dan Menggunakan peta URL.
• Untuk mengarahkan traffic dari luar mesh ke mesh, lihat Traffic masuk untuk mesh Anda.
• Untuk menyiapkan fitur dengan deployment proxy file bantuan, lihat Mengonfigurasi pengelolaan traffic lanjutan dengan Envoy.
• Untuk menyiapkan fitur dengan deployment gRPC tanpa proxy, lihat Mengonfigurasi pengelolaan traffic lanjutan dengan layanan gRPC tanpa proxy.