Migrasi kluster Apache RocketMQ yang dikelola sendiri ke instance ApsaraMQ for RocketMQ - ApsaraMQ for RocketMQ

Dibandingkan dengan Apache RocketMQ open source, ApsaraMQ for RocketMQ dari Alibaba Cloud lebih stabil, aman, dan menyediakan sistem O&M yang komprehensif. Anda dapat memigrasikan kluster Apache RocketMQ ke instance ApsaraMQ for RocketMQ untuk meningkatkan pengalaman layanan. Topik ini menjelaskan solusi migrasi yang disediakan oleh ApsaraMQ for RocketMQ serta mekanisme kerja solusi tersebut.

Perbandingan antara Apache RocketMQ dan ApsaraMQ for RocketMQ

Dibandingkan dengan Apache RocketMQ, ApsaraMQ for RocketMQ unggul dalam hal arsitektur teknis, skalabilitas, O&M, dan kemampuan tingkat perusahaan. Tabel berikut menunjukkan perbandingan antara Apache RocketMQ dan ApsaraMQ for RocketMQ.

Item	Kluster Apache RocketMQ yang Dikelola Sendiri	ApsaraMQ for RocketMQ instance 5.x
Storage scalability	Tidak ada kumpulan sumber daya yang disediakan. Arsitektur penyimpanan-komputasi terkopel digunakan.	Kumpulan sumber daya berskala besar disediakan berdasarkan infrastruktur cloud Alibaba Cloud. Penyimpanan dipisahkan dari komputasi.
API and SDK access	SDK Apache RocketMQ didukung.	SDK Apache RocketMQ didukung. SDK ONS Alibaba Cloud didukung.
Technical architecture	Teknologi diimplementasikan menggunakan disk lokal. Penyimpanan tidak dapat diskalakan. Jika ruang penyimpanan tidak mencukupi, sistem akan menghapus data secara dini. Beberapa replika menyebabkan biaya penyimpanan yang tinggi.	Teknologi diimplementasikan menggunakan penyimpanan cloud serverless. Ruang penyimpanan dapat digunakan sesuai kebutuhan bisnis Anda. Biaya penyimpanan dihitung berdasarkan metode penagihan bayar sesuai pemakaian. Jika jumlah replika dalam instance ApsaraMQ for RocketMQ dan kluster Apache RocketMQ sama, biaya untuk instance ApsaraMQ for RocketMQ hanya sepertiga dari biaya untuk kluster Apache RocketMQ.
Computing scalability	Jumlah mesin direncanakan berdasarkan penggunaan kluster. Anda harus memesan sumber daya komputasi terlebih dahulu. Sumber daya komputasi sulit untuk diskalakan. Skalabilitas komputasi tidak didukung untuk skenario yang memerlukan lalu lintas mendadak karena batasan pada kecepatan penskalaan.	Sumber daya komputasi dapat diskalakan berdasarkan kumpulan sumber daya yang disediakan oleh Alibaba Cloud. Penskalaan terencana: Anda dapat meningkatkan atau menurunkan edisi suatu instance berdasarkan kebutuhan bisnis Anda. Peningkatan atau penurunan tersebut mulai berlaku dalam beberapa menit. Penskalaan tak terencana: Fitur transaksi elastis per detik (TPS) disediakan. Fitur ini memungkinkan Anda menggunakan jumlah TPS tertentu ketika batas spesifikasi terlampaui, membantu Anda menghemat biaya karena tidak perlu memesan spesifikasi besar untuk menangani lalu lintas mendadak yang jarang terjadi.
O&M complexity	O&M dilakukan dengan menjalankan perintah, yang mengakibatkan biaya dan risiko yang lebih tinggi. Tidak ada sistem observabilitas dan pemantauan yang disediakan.	Platform sebagai Layanan (PaaS) yang dikelola sepenuhnya memungkinkan Anda menerapkan, mengoperasikan, dan mengelola sumber daya tanpa menggunakan mesin. Layanan disediakan untuk penggunaan segera. Layanan ini mendukung fitur seperti diagnostik dasbor, pelacakan, pemantauan, dan peringatan.
Stability guarantee	O&M dilakukan oleh pengguna dan memerlukan bantuan dari personel dukungan teknis senior.	Service Level Agreements (SLA) di mana kemampuan layanan dijamin disediakan. Keandalan data: hingga 10 sembilan. Ketersediaan layanan: hingga 99,99%.
Enterprise-level capabilities	Kemampuan tingkat perusahaan dikembangkan oleh pengguna dan memerlukan bantuan dari personel dukungan teknis senior.	Layanan dapat digunakan langsung dan menyediakan kemampuan seperti rilis canary ujung ke ujung, pengarahan pesan, replikasi pesan, ekstraksi, transformasi, pemuatan (ETL), integrasi acara, dan analisis acara.
Systematic disaster recovery	O&M dilakukan oleh pengguna dan memerlukan bantuan dari personel dukungan teknis senior.	Solusi pemulihan bencana berikut disediakan: Aktif-aktif zona Pemulihan bencana geografis Aktif-aktif jarak jauh

Mekanisme kerja

Persyaratan dasar

Apache RocketMQ sering digunakan dalam sistem inti seperti pesanan dan pembayaran online. Aplikasi hulu dan hilir layanan pesan memiliki persyaratan tinggi terhadap stabilitas layanan. Kami menyarankan Anda mengambil tindakan pencegahan saat memigrasi dan mengganti kluster Apache RocketMQ. Berikut adalah persyaratan dasar untuk merancang solusi migrasi:

Layanan pesan tanpa gangguan
Pastikan aplikasi pesan lapisan atas tidak terpengaruh, dan tidak ada sejumlah besar kesalahan dan kegagalan yang dilaporkan selama migrasi.
Tidak ada sejumlah besar pesan duplikat
Pastikan tidak ada sejumlah besar pesan duplikat selama migrasi sehingga pengguna tidak perlu memproses pesan duplikat dalam sistem.
Tidak ada latensi pesan yang signifikan
Pastikan tidak ada perubahan signifikan dalam latensi pesan ujung ke ujung selama migrasi sehingga Anda tetap dapat menerima pesan bahkan selama migrasi.

Desain solusi

Untuk memenuhi persyaratan migrasi sebelumnya, ApsaraMQ for RocketMQ menyediakan alat migrasi yang memungkinkan Anda memigrasikan kluster Apache RocketMQ yang dikelola sendiri ke instance ApsaraMQ for RocketMQ secara efisien tanpa memengaruhi bisnis Anda. Anda dapat menggunakan alat ini untuk memigrasikan pesan dan metadata seperti topik, grup, dan kemajuan konsumsi.

Migrasi metadata: Alat migrasi membaca metadata dalam kluster Apache RocketMQ yang dikelola sendiri dan menyalin metadata ke instance ApsaraMQ for RocketMQ. Dengan cara ini, metadata dibuat dan disinkronkan.
Migrasi pesan: Alat migrasi dapat mengontrol informasi perutean tentang topik di backend untuk secara dinamis beralih antara lalu lintas baca dan tulis klien menggunakan komponen kontrol perutean bawaan dari ApsaraMQ for RocketMQ. Saklar lalu lintas tidak memengaruhi bisnis Anda.
Anggaplah bahwa Topic A dalam kluster sumber pada gambar sebelumnya memiliki delapan partisi baca dan delapan partisi tulis.
Setelah Anda membuat tugas migrasi metadata, sebuah topik bernama Topic A juga dibuat dalam instance tujuan. Topic A dalam instance tujuan memiliki jumlah partisi baca dan tulis yang sama dengan Topic A dalam kluster sumber.
Selama migrasi pesan, komponen kontrol perutean dari ApsaraMQ for RocketMQ dapat mengontrol informasi perutean tentang kluster sumber dan instance tujuan serta mengembalikan informasi baca dan tulis tentang partisi ke klien berdasarkan tahap migrasi. Contoh:
- Operasi baca dalam kluster sumber dan instance tujuan: Informasi tentang 16 partisi baca dalam kluster sumber dan instance tujuan dikembalikan.
- Operasi tulis saja dalam kluster tujuan: Informasi tentang delapan partisi tulis dalam kluster tujuan dikembalikan.

Manfaat

Solusi migrasi yang disediakan oleh ApsaraMQ for RocketMQ diimplementasikan berdasarkan komponen proxy metadata untuk perutean pesan. Komponen ini dikembangkan oleh Alibaba Cloud dan mendukung perutean pesan spesifik topik, penjadwalan pesan, dan manajemen saklar lalu lintas. Solusi migrasi ini memberikan manfaat berikut:

Layanan pesan tanpa gangguan
Solusi migrasi mendukung saklar lalu lintas tanpa memengaruhi bisnis Anda. Selama saklar lalu lintas, pesan dapat dikirim dan diterima. Dalam kasus langka, latensi dan duplikasi pesan terjadi.
Tidak diperlukan sumber daya tambahan
Anda tidak perlu menambah kapasitas kluster atau menerapkan beberapa kluster. Anda hanya perlu mengonfigurasi parameter untuk melakukan pembaruan atau perubahan.
Dampak sangat rendah terhadap bisnis dan implementasi mudah
Anda hanya perlu secara manual mengubah titik akhir aplikasi dan memulai ulang aplikasi sekali. Saklar lalu lintas berikutnya mulai berlaku berdasarkan konfigurasi dinamis pada broker ApsaraMQ for RocketMQ. Anda dapat meningkatkan aplikasi hulu dan hilir dari layanan pesan tanpa menyortir dependensi pesan. Operasi ini memiliki dampak sangat rendah terhadap bisnis Anda, sehingga aplikasi hulu dan hilir dapat dengan mudah menghadapi migrasi.
Dukungan untuk rilis canary dan rollback
Tugas migrasi akurat hingga tingkat topik. Anda dapat melakukan rilis canary spesifik topik. Jika risiko bisnis muncul selama migrasi, Anda dapat melakukan rollback.