Skema Pengembangan: Melakukan Isolasi Lingkungan Berdasarkan Message Queue untuk Apache RocketMQ - Serverless App Engine

Topik ini menjelaskan cara melakukan isolasi lingkungan di Serverless App Engine (SAE) berdasarkan Message Queue untuk Apache RocketMQ. Anda dapat mengontrol lalu lintas secara asinkron tanpa perlu memodifikasi kode bisnis.

Informasi latar belakang

dg_rocket_mq_workflow

Message Queue untuk Apache RocketMQ versi 4.2.0 dan yang lebih baru didukung.
Mode pull dan push didukung.
Anda harus mengonfigurasi pengaturan enablePropertyFilter=true pada server Anda dan kemudian memulai ulang server.

Persiapan

Deploy SAE demo applications

Unduh paket demo.
Deploy aplikasi tulang punggung.
Deploy aplikasi tulang punggung berikut: Aplikasi A, Aplikasi B, dan Aplikasi C. Untuk informasi lebih lanjut, lihat Modifikasi registrasi layanan dan penemuan aplikasi ke Nacos.
Deploy aplikasi rilis canary berikut: Aplikasi A-gray, Aplikasi B-gray, dan Aplikasi C-gray. Tambahkan -Dalicloud.service.tag=gray ke perintah startup untuk membedakan aplikasi rilis canary dengan aplikasi tulang punggung.

Catatan

Jika Anda ingin menggunakan registri layanan non-bawaan SAE saat menerapkan aplikasi, Anda harus menambahkan parameter startup berikut: -Dnacos.use.endpoint.parsing.rule=false -Dnacos.use.cloud.namespace.parsing=false.

Deploy RocketMQ

Rilis canary hanya berlaku untuk pesan ketika Anda mengaktifkan fitur rilis canary berbasis RocketMQ untuk produsen dan konsumen pesan tersebut. Hanya pesan RocketMQ yang mendukung fitur rilis canary. Pesan RocketMQ mencakup pesan Apache RocketMQ dan Message Queue untuk Apache RocketMQ.
- Jika Anda menggunakan pesan Apache RocketMQ, versi RocketMQ Server dan RocketMQ Client harus 4.5.0 atau yang lebih baru. Untuk informasi lebih lanjut, lihat Apache RocketMQ.
- Jika Anda menggunakan pesan Message Queue untuk Apache RocketMQ, Anda harus menggunakan Edisi Platinum Perusahaan dan ons-client 1.8.0.Final atau yang lebih baru. Untuk informasi lebih lanjut, lihat Ikhtisar.
Setelah Anda mengaktifkan fitur rilis canary berbasis RocketMQ, SAE memodifikasi grup konsumen pesan. Sebagai contoh, nama grup konsumen pesan adalah group1 dan tag lingkungan adalah gray. Setelah Anda mengaktifkan fitur rilis canary berbasis RocketMQ, nama grup konsumen berubah menjadi group1_gray. Jika Anda menggunakan pesan Message Queue untuk Apache RocketMQ, Anda harus membuat grup konsumen terlebih dahulu.
Secara default, SAE menggunakan SQL-92 untuk menyaring pesan. Jika Anda menggunakan Apache RocketMQ, Anda harus mengaktifkan penyaringan SQL-92 di sisi server dengan mengatur enablePropertyFilter menjadi true dalam file broker.conf.

Langkah 1: Aktifkan fitur rilis canary berbasis RocketMQ untuk aplikasi

Aplikasi spring-cloud-c dan spring-cloud-a dalam demo adalah produsen dan konsumen pesan. Anda dapat menambahkan parameter startup (-Dprofiler.micro.service.mq.gray.enable=true) di SAE untuk mengaktifkan fitur rilis canary berbasis RocketMQ untuk aplikasi tersebut.

Catatan

Setelah Anda mengaktifkan atau menonaktifkan fitur rilis canary berbasis RocketMQ untuk aplikasi, Anda harus menerapkan ulang aplikasi di Konsol SAE untuk memvalidasi perubahan.

Langkah 2: Ingest lalu lintas dan lakukan verifikasi

Gambar berikut menunjukkan struktur dari demo ini. Panggilan aplikasi melibatkan panggilan layanan Spring Cloud dan panggilan layanan Dubbo. Spring Cloud dan Dubbo adalah dua kerangka mikro layanan yang paling umum digunakan di pasar. spring-cloud-c memproduksi pesan RocketMQ untuk spring-cloud-a. Ketika pesan dikonsumsi oleh spring-cloud-a, panggilan baru dimulai. Gambar berikut menunjukkan penggunaan dasar dan standar dari Spring Cloud, Dubbo, dan RocketMQ.

dg_implement_end_to_end_canary_release_via_rocket_mq

Sebelum Anda menerapkan aplikasi, kami sarankan Anda memahami proses pemanggilan dalam demo. Dalam proses pemanggilan, spring-cloud-zuul menerima permintaan dari /A/dubbo dan meneruskan permintaan ke spring-cloud-a. Kemudian, spring-cloud-a mengakses spring-cloud-b menggunakan protokol Dubbo, dan spring-cloud-b mengakses spring-cloud-c dengan cara yang sama. Setelah spring-cloud-c menerima permintaan, sebuah pesan diproduksi dan tag lingkungan serta alamat IP dari spring-cloud-c dikembalikan. spring-cloud-a mengonsumsi pesan yang diproduksi dan memanggil spring-cloud-b menggunakan protokol Spring Cloud pada saat yang sama. Kemudian, spring-cloud-b memanggil spring-cloud-c dengan cara yang sama dan menampilkan hasilnya di log.

# Saat Anda mengakses /A/dubbo,
# Nilai yang dikembalikan adalah A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx].
# Pada saat yang sama, spring-cloud-a menerima pesan dan mengembalikan log berikut:
c.a.mse.demo.service.MqConsumer: topic:TEST_MQ,producer:C[10.25.xx.xx],hasil pemanggilan:A[10.25.xx.xx] -> B[10.25.xx.xx] -> C[10.25.xx.xx]

Masuk ke Konsol SAE untuk melihat log spring-cloud-a dan memverifikasi konfigurasi. Lingkungan dasar dapat mengonsumsi pesan yang diproduksi dari lingkungan rilis canary dan lingkungan dasar. Panggilan Spring Cloud dari lingkungan rilis canary atau lingkungan dasar diarahkan ke lingkungan hilir rilis canary atau lingkungan dasar.