Pola Konvoi Berurutan

Memproses sekumpulan pesan terkait dalam urutan yang ditentukan, tanpa memblokir pemrosesan grup pesan lainnya.

Konteks dan masalah

Aplikasi sering kali perlu memproses urutan pesan sesuai urutan kedatangannya, sembari tetap dapat melakukan peluasan skala untuk menangani peningkatan beban. Dalam arsitektur terdistribusi, memproses pesan ini secara berurutan tidaklah mudah, karena pekerja dapat menskalakan secara mandiri dan sering kali menarik pesan secara mandiri, menggunakan pola Konsumen yang Bersaing.

Misalnya, sistem pelacakan pesanan menerima ledger yang berisi pesanan dan operasi yang relevan pada pesanan tersebut. Operasi ini bisa untuk membuat pesanan, menambahkan transaksi ke pesanan, mengubah transaksi sebelumnya, atau menghapus pesanan. Dalam sistem ini, operasi harus dilakukan dengan cara first-in-first-out (FIFO), tetapi hanya pada tingkat pesanan. Namun, antrean awal menerima ledger yang berisi transaksi untuk banyak pesanan, yang mungkin saling terkait.

Solusi

Dorong pesan terkait ke dalam kategori dalam sistem antrean, dan minta pendengar antrean mengunci dan menarik hanya dari satu kategori, satu pesan pada satu waktu.

Berikut ini pola umum Konvoi Berurutan:

Dalam antrean, pesan untuk kategori yang berbeda dapat saling terkait, seperti yang ditunjukkan pada diagram berikut:

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat memutuskan cara menerapkan pola ini:

• Unit skala/kategori. Properti apa dari pesan masuk Anda yang dapat diperluas skalanya? Dalam skenario pelacakan pesanan, properti ini adalah ID pesanan.
• Throughput. Apa throughput pesan target Anda? Jika sangat tinggi, Anda mungkin perlu mempertimbangkan kembali persyaratan FIFO Anda. Misalnya, dapatkah Anda menerapkan pesan awal/akhir, mengurutkan berdasarkan waktu, lalu mengirim batch untuk diproses?
• Kemampuan layanan. Apakah bus pesan pilihan Anda memungkinkan pemrosesan pesan satu per satu dalam antrean atau kategori antrean?
• Evolvabilitas. Bagaimana Anda akan menambahkan kategori pesan baru ke sistem? Sebagai contoh, misalkan sistem ledger yang dijelaskan di atas adalah satu pelanggan tertentu. Jika Anda perlu melakukan onboard pada pelanggan baru, dapatkah Anda memiliki satu set pemroses ledger yang mendistribusikan pekerjaan per ID pelanggan?
• Ada kemungkinan bahwa konsumen menerima pesan yang tidak berurutan, karena latensi jaringan yang bervariasi saat mengirim pesan. Pertimbangkan untuk menggunakan nomor urut untuk memverifikasi pemesanan. Anda mungkin juga menyertakan bendera "akhir urutan" khusus dalam pesan terakhir dari suatu transaksi. Teknologi pemrosesan aliran seperti Spark atau Azure Stream Analytics dapat memproses pesan secara berurutan dalam jangka waktu tertentu.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Anda memiliki pesan yang datang secara berurutan dan harus diproses dalam urutan yang sama.
• Pesan yang tiba atau dapat "dikategorikan" sedemikian rupa sehingga kategori tersebut menjadi unit skala bagi sistem.

Pola ini mungkin tidak cocok untuk:

• Skenario throughput yang sangat tinggi (jutaan pesan/menit atau detik), karena persyaratan FIFO membatasi penskalaan yang dapat dilakukan oleh sistem.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Konvoi Berurutan dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:

Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.

Contoh

Di Azure, pola ini dapat diterapkan menggunakan sesi pesan Azure Service Bus. Untuk konsumen, Anda dapat menggunakan logic Apps dengan konektor peek-lock Bus Layanan atau Azure Functions dengan pemicu Bus Layanan.

Untuk contoh pelacakan pesanan sebelumnya, proses setiap pesan ledger dalam urutan yang diterimanya, dan kirim setiap transaksi ke antrean lain di mana kategori diatur ke ID pesanan. Transaksi tidak akan pernah menjangkau banyak pesanan dalam skenario ini, sehingga konsumen memproses setiap kategori secara paralel tetapi FIFO dalam kategori tersebut.

Prosesor ledge menyebarkan pesan dengan melakukan de-batching konten setiap pesan di antrean pertama:

Prosesor ledger menangani:

1. Berjalan di ledger satu transaksi pada satu waktu.
2. Mengatur ID sesi pesan agar sesuai dengan ID pesanan.
3. Mengirim setiap transaksi ledger ke antrean sekunder dengan ID sesi diatur ke ID pesanan.

Konsumen mendengarkan antrean sekunder tempat mereka memproses semua pesan dengan ID pesanan yang cocok secara berurutan dari antrean. Konsumen menggunakan mode peek-lock.

Saat mempertimbangkan skalabilitas, antrean ledger menjadi hambatan utama. Transaksi berbeda yang diposting ke ledger dapat mengacu pada ID pesanan yang sama. Namun, pesan dapat menyebar setelah ledger ke jumlah pesanan di lingkungan tanpa server.

Langkah berikutnya

Informasi berikut mungkin relevan saat menerapkan pola ini:

• Sesi pesan: first in, first out (FIFO)
• Pesan Peek-Lock (Tindakan Baca Non-Destruktif)
• Agar pengiriman pesan terkait di Logic Apps menggunakan sesi Bus Layanan (blog MSDN)