Fitur Intra-zone Provider First dari Microservices Engine (MSE) adalah kebijakan penyeimbangan beban yang secara dinamis mengidentifikasi zona tempat konsumen dan penyedia layanan berada serta mengarahkan permintaan secara preferensial ke node layanan di zona yang sama. Dibandingkan dengan algoritma round-robin tradisional, kebijakan ini mengurangi transfer traffic lintas zona, sehingga menurunkan latensi jaringan, meningkatkan kecepatan respons layanan, dan memperkuat kemampuan disaster recovery sistem. Topik ini menjelaskan cara mengonfigurasi fitur Intra-zone Provider First di MSE.
Cara kerja
Saat Anda mengaktifkan fitur Intra-zone Provider First untuk suatu aplikasi, aplikasi konsumen dari aplikasi tersebut secara preferensial memanggil instans di zona mereka sendiri. Misalnya, jika Anda mengaktifkan fitur ini untuk Aplikasi P, Aplikasi C1, C2, dan C3 secara preferensial memanggil instans Aplikasi P di zona masing-masing.
Fitur Intra-zone Provider First yang saat ini disediakan oleh MSE hanya berlaku untuk satu aplikasi penyedia. Artinya, setelah Anda mengaktifkan fitur ini untuk suatu aplikasi, semua konsumen aplikasi tersebut secara preferensial memanggil instans di zona mereka sendiri saat memanggil aplikasi tersebut.
Gambar berikut menunjukkan model pemanggilan aplikasi ketika pemanggilan Intra-zone Provider First tidak diaktifkan di MSE.

Gambar berikut menunjukkan model pemanggilan aplikasi ketika pemanggilan Intra-zone Provider First diaktifkan di MSE.

Manfaat
Fitur Intra-zone Provider First adalah kebijakan penjadwalan traffic untuk arsitektur microservices. Dalam arsitektur multi-zona, pemanggilan intra-zona memberikan manfaat berikut:
Latensi sistem lebih rendah — Pemanggilan lintas zona berubah menjadi pemanggilan intra-zona, sehingga mengurangi RT seluruh sistem.
Ruang cakupan kegagalan lebih kecil — Pemanggilan microservice dibatasi dalam zona yang sama. Jika satu zona mengalami kegagalan, dampaknya terbatas pada zona tersebut.
Istilah
Zone — Zona adalah area fisik dalam suatu region yang memiliki catu daya dan jaringan independen. Satu region berisi beberapa zona. Latensi jaringan antar instans dalam zona yang sama lebih rendah daripada latensi lintas zona.
Konsumen dan penyedia — Dalam skenario microservices, pihak yang memulai pemanggilan adalah konsumen layanan, sedangkan pihak yang menyediakan layanan adalah penyedia layanan. Dalam kebanyakan kasus, suatu aplikasi sekaligus berperan sebagai penyedia maupun konsumen.
RT — Waktu round-trip suatu permintaan. RT adalah total waktu mulai dari klien mengirim permintaan hingga klien menerima respons dari server.
Instance — Instans memiliki konsep yang sama dengan node dalam penggunaan sehari-hari. Dalam skenario Kubernetes, sebuah pod di bawah workload aplikasi merupakan instans aplikasi. Dalam skenario Elastic Compute Service (ECS), proses aplikasi tunggal pada Instance ECS merupakan instans aplikasi.
Ambang batas keamanan
Setelah Anda mengaktifkan fitur Intra-zone Provider First untuk suatu aplikasi, semua konsumen memanggil penyedia di zona mereka sendiri. Tidak semua aplikasi dideploy secara ketat dan merata di seluruh zona. Suatu aplikasi mungkin hanya memiliki sangat sedikit node penyedia di suatu zona, sehingga node tersebut tidak mampu menangani traffic yang dikirim oleh konsumen di zona tersebut.
Misalnya, jumlah instans aplikasi Anda yang dideploy di Zona A, B, dan C masing-masing adalah 3, 3, dan 1. Jika fitur Intra-zone Provider First diaktifkan dan jumlah konsumen di tiap zona seimbang, masing-masing zona menerima sepertiga traffic. Namun, Zona C hanya memiliki satu instans. Instans tersebut harus menangani traffic tiga kali lipat dibandingkan instans di zona lain, yang dapat menimbulkan risiko stabilitas.
Untuk mencegah konsumen di zona seperti Zona C secara preferensial memanggil aplikasi di zona mereka sendiri, fitur Intra-zone Provider First MSE menyediakan pengaturan ambang batas keamanan. Saat pemanggilan Intra-zone Provider First diaktifkan untuk suatu aplikasi dan persentase instans yang dideploy aplikasi di suatu zona kurang dari ambang batas keamanan, konsumen di zona tersebut tidak menggunakan kebijakan Intra-zone Provider First saat memanggil aplikasi. Sebagai gantinya, pemanggilan dialihkan kembali ke kebijakan acak atau round-robin bawaan framework microservices.
Misalnya, jumlah instans aplikasi Anda yang dideploy di Zona A, B, dan C masing-masing adalah 2, 2, dan 1, yang masing-masing menyumbang 40%, 40%, dan 20% dari total instans. Jika Anda mengaktifkan fitur Intra-zone Provider First untuk aplikasi tersebut dan menetapkan ambang batas keamanan sebesar 30%, konsumen di Zona C tidak melakukan pemanggilan intra-zona-first, sedangkan konsumen di Zona A dan B tetap melakukan pemanggilan intra-zona-first seperti yang diharapkan.
Kapan menggunakan fitur ini
Fitur Intra-zone Provider First terutama ditujukan untuk pemanggilan antar aplikasi yang dideploy lintas zona. Fitur ini mendukung layanan Dubbo dan layanan Spring Cloud. Layanan Kubernetes belum didukung.
Fitur Intra-zone Provider First bersifat opsional. Aktifkan fitur ini jika Anda ingin mengurangi latensi permintaan keseluruhan sistem dan lebih lanjut meningkatkan ketersediaan sistem secara keseluruhan.
Aplikasi yang dideploy secara merata di seluruh zona — Gunakan fitur Intra-zone Provider First.
Aplikasi yang tidak dideploy secara ketat merata di seluruh zona — Gunakan fitur Intra-zone Provider First, tetapi evaluasi dan konfigurasikan ambang batas keamanan yang mencegah traffic konsumen mengalir ke zona dengan terlalu sedikit instans. Untuk petunjuknya, lihat Konfigurasikan ambang batas keamanan.
Prasyarat
Microservices Governance MSE telah diaktifkan. Untuk petunjuknya, lihat Aktifkan Microservices Governance.
Aplikasi target dan aplikasi konsumennya telah terhubung ke Microservices Governance MSE. Untuk petunjuknya, lihat Aktifkan Microservices Governance untuk aplikasi microservice Java di kluster ACK atau ACS dan Hubungkan microservice ECS ke Microservices Governance.
Lingkungan tempat Anda mendeploy resource berisi beberapa zona, dan aplikasi Anda dideploy di zona-zona tersebut.
Jika Anda menggunakan Edisi Profesional atau namespace Anda adalah namespace Edisi Profesional, Anda tidak dapat melihat distribusi instans dan traffic lintas zona. Untuk jalur peningkatan, lihat Distribusi node dan traffic lintas zona.
Deploy aplikasi Anda lintas zona
Jika Anda menggunakan Alibaba Cloud Container Service for Kubernetes (ACK) untuk mengelola dan mendeploy aplikasi, pastikan konfigurasi jaringan kelompok node Anda berisi vSwitch di beberapa zona. Konfigurasi ini memungkinkan workload Anda berjalan di node di zona berbeda. Deploy aplikasi Anda lintas beberapa zona dengan menambahkan topology spread constraint ke workload Anda di bawah
spec > template > spec, seperti pada contoh berikut. Untuk informasi tentang cara mengonfigurasi workload untuk deployment lintas zona, lihat Konfigurasi arsitektur ketersediaan tinggi yang direkomendasikan untuk kluster.topologySpreadConstraints: - maxSkew: 1 topologyKey: "topology.kubernetes.io/zone" whenUnsatisfiable: ScheduleAnywayJika aplikasi Anda dideploy pada Instance ECS Alibaba Cloud, pilih vSwitch di zona berbeda untuk Instance ECS saat membuat instans tersebut. Kemudian, saat mendeploy aplikasi, distribusikan secara manual instans aplikasi tersebut ke Instance ECS tersebut.
Konfigurasikan ambang batas keamanan
Ambang batas keamanan menentukan apakah konsumen di suatu zona melakukan pemanggilan intra-zona-first ke suatu aplikasi. Untuk informasi lebih lanjut tentang cara mengevaluasi ambang batas ini, lihat Ambang batas keamanan.
Sebelum menetapkan nilai, lihat persentase instans tiap zona di tampilan Overall Data pada tab Intra-zone Provider First. Data ini tersedia bahkan saat fitur Intra-zone Provider First belum diaktifkan untuk aplikasi tersebut. Kemudian, konfigurasikan ambang batas keamanan berdasarkan deployment aplikasi bisnis Anda saat ini. Tujuan utamanya adalah melindungi instans di zona dengan sedikit instans agar tidak kewalahan oleh traffic. Gunakan dua skenario berikut sebagai referensi.
Skenario 1 (umum): aplikasi dideploy secara merata di seluruh zona. Tidak ada zona yang memiliki jumlah instans jauh lebih sedikit. Tetapkan ambang batas keamanan ke nilai yang lebih rendah dari persentase rata-rata instans per zona, yaitu kebalikan dari jumlah zona. Misalnya, suatu aplikasi memiliki 2, 2, dan 2 instans yang dideploy di Zona A, B, dan C. Instans di tiap zona menyumbang 33,33% dari total instans, sehingga Anda dapat menetapkan ambang batas keamanan sebesar 33%.
Skenario 2: aplikasi tidak dideploy secara merata di seluruh zona. Pertimbangkan jumlah aktual instans di zona yang memiliki lebih sedikit instans. Misalnya, suatu aplikasi memiliki 2, 2, dan 1 instans yang dideploy di Zona A, B, dan C. Karena Zona C memiliki lebih sedikit instans, Anda ingin konsumen di Zona C tidak melakukan pemanggilan intra-zona-first. Dalam hal ini, tetapkan ambang batas keamanan sebesar 30%. Instans di Zona A dan B masing-masing menyumbang 40% dari total instans, sehingga pemanggilan intra-zona-first berlaku. Instans di Zona C menyumbang 20%, sehingga pemanggilan dialihkan kembali ke kebijakan pemanggilan acak atau round-robin bawaan.
Ambang batas keamanan bawaan adalah 20%. Nilai ini sangat kecil dan terutama ditujukan untuk verifikasi dan uji coba di lingkungan pengujian. Tetapkan nilai yang sesuai berdasarkan cara aplikasi Anda saat ini dideploy lintas zona.
Prosedur
Sebelum mengaktifkan fitur Intra-zone Provider First untuk suatu aplikasi, tetapkan ambang batas keamanan yang tepat untuk aplikasi tersebut.
Masuk ke Konsol MSE, lalu pilih region di bilah navigasi atas.
Di panel navigasi kiri, pilih . Di halaman yang muncul, klik kartu resource aplikasi yang ingin Anda kelola.
Di panel navigasi kiri, klik Traffic management.
Di bagian atas halaman, klik tab Intra-zone Provider First.
Klik {key, select, RAM {RAM} Overview {Overview} Identities {Identities} Users {Users} Groups {Groups} Roles {Roles} Settings {Settings} Permissions {Permissions} Grants {Grants} Troubleshoot {Troubleshooting} Policies {Policies} Integrations {Integrations} Providers {SSO} Applications {OAuth (Preview)} CloudSSO {CloudSSO} AccessAnalyzing {Access Analysis} Analyzers {Analyzers} Findings {Findings} Beta {Beta} Governance {Cloud Governance} AgentControl {Agent Management} other {{key}} } di samping Configuration Information.
Ubah Enable Status menjadi Enabled, masukkan Security Threshold, lalu klik OK.
Setelah Anda mengklik OK, konfigurasi langsung berlaku tanpa perlu me-restart aplikasi apa pun. Saat konsumen aplikasi memulai pemanggilan ke aplikasi tersebut, konsumen secara otomatis dan preferensial memilih instans di zona yang sama.
Untuk memverifikasi hasilnya, lakukan pemeriksaan berikut:
Verifikasi bahwa bagian Configuration Information menampilkan nilai Enable Status dan Security Threshold yang telah Anda konfigurasi.
Di tampilan Overall Data pada tab Intra-zone Provider First, bandingkan persentase traffic tiap zona dengan persentase instans di zona tersebut. Untuk detail tentang tampilan dan metrik yang tersedia, lihat Distribusi node dan traffic lintas zona.
Untuk berhenti menggunakan fitur Intra-zone Provider First untuk aplikasi tersebut, ubah Enable Status di bagian Configuration Information yang sama.
Catatan penggunaan
Keseimbangan deployment — Idealnya, aplikasi penyedia dan konsumen dideploy secara merata. Tidak ada aplikasi yang seharusnya memiliki jumlah instans sangat tinggi di zona tertentu. Jika tidak, beban traffic dapat menjadi sangat tidak seimbang setelah Anda mengaktifkan fitur Intra-zone Provider First.
Rilis layanan — Saat Anda merilis layanan, terutama selama rolling update di Kubernetes, jumlah instans di tiap zona dapat berubah dalam periode singkat. Beberapa zona mungkin kemudian memiliki persentase instans yang tidak memenuhi ambang batas keamanan, sehingga dapat mengakibatkan pemanggilan lintas zona dalam periode singkat.
Cakupan isolasi — Gunakan fitur Intra-zone Provider First hanya untuk isolasi di tingkat traffic, bukan untuk isolasi di tingkat bisnis. Saat menggunakan fitur ini, pastikan pemanggilan lintas zona masih dapat ditoleransi.
Peluncuran kanari ujung ke ujung — Saat ambang batas keamanan berlaku, sistem menghitung apakah instans yang tersedia di suatu zona menyumbang persentase dari total node yang memenuhi ambang batas keamanan. Jumlah instans yang tersedia dan jumlah total instans dihitung dari instans yang tersisa setelah penyaringan peluncuran kanari ujung ke ujung. Dalam kebanyakan kasus, sistem bisnis hanya menggunakan peluncuran kanari ujung ke ujung saat merilis versi bisnis, sehingga Anda dapat mengabaikan poin ini. Jika sistem Anda menggunakan peluncuran kanari ujung ke ujung untuk penyaringan rute rutin—yaitu di luar jendela rilis—perhatikan poin ini.
Misalnya, suatu aplikasi memiliki 2, 2, dan 1 node yang dideploy di Zona A, B, dan C, dan salah satu dari dua node di Zona A serta salah satu dari dua node di Zona B adalah node kanari. Untuk aplikasi konsumen yang menggunakan versi resmi di Zona A, jumlah efektif node di Zona A, B, dan C masing-masing adalah 1, 1, dan 1, sehingga tiap zona menyumbang 33,33% dari total node efektif. Jika ambang batas keamanan ditetapkan sebesar 35%, fitur Intra-zone Provider First tidak berlaku di Zona A dan B untuk konsumen yang menggunakan versi resmi. Untuk konsumen yang menggunakan versi kanari di Zona A, jumlah efektif node di Zona A, B, dan C masing-masing adalah 1, 1, dan 0, sehingga fitur Intra-zone Provider First berlaku untuk konsumen kanari.
Observabilitas traffic tingkat zona
Distribusi node dan traffic lintas zona
Fitur Intra-zone Provider First menyediakan tingkat observabilitas tertentu. Setelah Anda menghubungkan aplikasi ke Microservices Governance MSE, Anda dapat melihat distribusi deployment instans aplikasi dan traffic yang ditangani tiap zona di tab Intra-zone Provider First. Data ini tersedia baik saat fitur Intra-zone Provider First diaktifkan maupun tidak diaktifkan untuk aplikasi tersebut.
Tab Intra-zone Provider First berisi bagian-bagian berikut:
Configuration Information — Menampilkan Enable Status dan Security Threshold.
Tampilan Overall Data — Menunjukkan persentase instans, persentase traffic, jumlah total permintaan, RT, tingkat keberhasilan, dan grafik tren yang sesuai untuk tiap zona.
Tampilan Availability Zone — Menunjukkan jumlah permintaan, RT, dan tingkat keberhasilan untuk tiap zona.
Saat fitur Intra-zone Provider First tidak diaktifkan, traffic didistribusikan secara merata di seluruh zona.

Jika Anda menggunakan Edisi Profesional atau namespace Anda adalah namespace Edisi Profesional, Anda tidak dapat melihat data ini.
Untuk meningkatkan namespace Edisi Profesional ke namespace Edisi Perusahaan, lihat Manajemen namespace microservice.
Pemeriksaan deployment dan traffic
Di halaman pengamatan fitur Intra-zone Provider First, bagian Overall Data menunjukkan jumlah instans yang dideploy aplikasi di tiap zona. Jika suatu aplikasi sangat tidak merata dideploy di seluruh zona, grafik akan mencerminkan hal tersebut. Deploy aplikasi Anda lintas zona untuk meningkatkan ketersediaan sistem secara keseluruhan.
Selain itu, setelah Anda mengaktifkan fitur Intra-zone Provider First untuk aplikasi Anda, periksa apakah traffic di zona mana pun terlalu tinggi atau terlalu rendah dan apakah traffic yang ditangani tiap zona sesuai dengan jumlah node yang dideploy di zona tersebut. Misalnya, suatu zona mungkin memiliki banyak node tetapi menangani sedikit traffic, atau memiliki sedikit node tetapi menangani traffic besar. Dalam kasus seperti ini, sesuaikan ambang batas keamanan untuk menghindari risiko stabilitas akibat distribusi traffic yang tidak seimbang.
Contoh perbandingan RT
Jika fitur Intra-zone Provider First tidak diaktifkan, pemanggilan microservice menggunakan kebijakan acak atau round-robin bawaan, sehingga menghasilkan banyak pemanggilan layanan lintas zona. Dalam contoh yang dijelaskan di bagian ini, fitur ini tidak diaktifkan untuk aplikasi tersebut, dan RT rata-rata keseluruhan selama 5 menit terakhir adalah 7,88 ms.
Setelah Anda mengaktifkan fitur Intra-zone Provider First untuk semua aplikasi sepanjang rantaian pemanggilan lengkap, RT rata-rata keseluruhan aplikasi berubah menjadi 6,85 ms.
Setelah fitur diaktifkan, traffic didistribusikan secara merata di lima zona (cn-hangzhou-k, cn-hangzhou-j, cn-hangzhou-i, cn-hangzhou-h, dan cn-hangzhou-g), dan tiap zona menangani sekitar 20% traffic. Tingkat keberhasilan permintaan keseluruhan adalah 100,00%, dan ambang batas keamanan ditetapkan sebesar 10,00%.