Pola Claim-Check memungkinkan beban kerja untuk mentransfer payload tanpa menyimpan payload dalam sistem olahpesan. Pola menyimpan payload di penyimpanan data eksternal dan menggunakan "pemeriksaan klaim" untuk mengambil payload. Pemeriksaan klaim adalah token atau kunci unik yang tidak jelas. Untuk mengambil payload, aplikasi perlu menyajikan token pemeriksaan klaim ke penyimpanan data eksternal.
Konteks dan masalah
Sistem olahpesan tradisional dioptimalkan untuk mengelola pesan kecil dalam volume tinggi dan sering memiliki batasan pada ukuran pesan yang dapat mereka tangani. Pesan besar tidak hanya berisiko melebihi batas ini tetapi juga dapat menurunkan performa seluruh sistem ketika sistem olahpesan menyimpannya.
Solusi
Gunakan pola Claim-Check, dan jangan mengirim pesan besar ke sistem olahpesan. Sebagai gantinya, kirim payload ke penyimpanan data eksternal dan hasilkan token pemeriksaan klaim untuk payload tersebut. Sistem olahpesan mengirim pesan dengan token pemeriksaan klaim untuk menerima aplikasi sehingga aplikasi ini dapat mengambil payload dari penyimpanan data. Sistem olahpesan tidak pernah melihat atau menyimpan payload.
- Payload
- Simpan payload di penyimpanan data.
- Buat token pemeriksaan klaim dan kirim pesan dengan token pemeriksaan klaim.
- Menerima pesan dan membaca token pemeriksaan klaim.
- Ambil payload.
- Proses payload.
Masalah dan pertimbangan dengan pola Claim-Check
Pertimbangkan rekomendasi berikut saat menerapkan pola Claim-Check:
Hapus pesan yang digunakan. Jika Anda tidak perlu mengarsipkan pesan, hapus pesan dan payload setelah aplikasi penerima menggunakannya. Gunakan strategi penghapusan sinkron atau asinkron:
Penghapusan sinkron: Aplikasi yang menggunakan menghapus pesan dan payload segera setelah konsumsi. Ini mengikat penghapusan ke alur kerja penanganan pesan dan menggunakan kapasitas komputasi alur kerja olahpesan.
Penghapusan asinkron: Proses di luar alur kerja pemrosesan pesan menghapus pesan dan payload. Ini memisahkan proses penghapusan dari alur kerja penanganan pesan dan meminimalkan penggunaan komputasi alur kerja olahpesan.
Terapkan pola secara kondisional. Masukkan logika dalam aplikasi pengirim yang menerapkan pola Claim-Check jika ukuran pesan melampaui batas sistem olahpesan. Untuk pesan yang lebih kecil, lewati pola dan kirim pesan yang lebih kecil ke sistem olahpesan. Pendekatan bersyarat ini mengurangi latensi, mengoptimalkan pemanfaatan sumber daya, dan meningkatkan throughput.
Kapan menggunakan pola Claim-Check
Skenario berikut adalah kasus penggunaan utama untuk pola Claim-Check:
Batasan sistem olahpesan: Gunakan pola Claim-Check saat ukuran pesan melampaui batas sistem olahpesan Anda. Offload payload ke penyimpanan eksternal. Kirim hanya pesan dengan token pemeriksaan klaimnya ke sistem olahpesan.
Performa sistem olahpesan: Gunakan pola Claim-Check saat pesan besar membatasi sistem olahpesan dan menurunkan performa sistem.
Skenario berikut adalah kasus penggunaan sekunder untuk pola Claim-Check:
Perlindungan data sensitif: Gunakan pola Claim-Check saat payload berisi data sensitif yang tidak ingin terlihat oleh sistem olahpesan. Terapkan pola ke semua atau bagian informasi sensitif dalam payload. Amankan data sensitif tanpa mengirimkannya langsung melalui sistem olahpesan.
Skenario perutean yang kompleks: Pesan yang melintas beberapa komponen dapat menyebabkan penyempitan performa karena tugas serialisasi, deserialisasi, enkripsi, dan dekripsi. Gunakan pola Claim-Check untuk mencegah pemrosesan pesan langsung oleh komponen perantara.
Desain beban kerja dengan pola Claim-Check
Arsitek harus mengevaluasi bagaimana pola Claim-Check dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Keputusan desain keandalan membantu beban kerja Anda menjadi tahan terhadap kerusakan dan memastikannya sepenuhnya pulih setelah kegagalan. | Sistem olahpesan tidak memberikan keandalan dan pemulihan bencana yang sama yang sering ada di penyimpanan data khusus. Memisahkan data dari pesan dapat memberikan peningkatan keandalan untuk payload. Pemisahan ini memfasilitasi redundansi data yang memungkinkan Anda memulihkan payload setelah bencana. - Analisis mode kegagalan RE:03 - RE:09 Pemulihan bencana |
| Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja. | Pola Claim-Check dapat mengekstrak data sensitif dari pesan dan menyimpannya di penyimpanan data yang aman. Penyiapan ini memungkinkan Anda menerapkan kontrol akses yang lebih ketat, memastikan bahwa hanya layanan yang dimaksudkan untuk menggunakan data sensitif yang dapat mengaksesnya. Pada saat yang sama, data ini disembunyikan dari layanan yang tidak terkait, seperti yang digunakan untuk pemantauan antrean. - Klasifikasi Data SE:03 - Segmentasi SE:04 |
| Pengoptimalan Biaya difokuskan untuk mempertahankan dan meningkatkan pengembalian beban kerja Anda pada investasi. | Sistem olahpesan sering memberlakukan batasan pada ukuran pesan, dan peningkatan batas ukuran sering kali merupakan fitur premium. Mengurangi ukuran badan pesan mungkin memungkinkan Anda menggunakan solusi olahpesan yang lebih murah. - Biaya komponen CO:07 - Biaya Alur CO:09 |
| Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien dengan mengoptimalkan penskalaan , transfer data, dan eksekusi kode. | Pola Claim-Check meningkatkan efisiensi pengiriman dan penerimaan aplikasi dan sistem olahpesan dengan mengelola pesan besar secara lebih efektif. Ini mengurangi ukuran pesan yang dikirim ke sistem olahpesan dan memastikan menerima aplikasi mengakses pesan besar hanya jika diperlukan. - PE:05 Penskalaan dan pemartisian - Pengoptimalan performa berkelanjutan PE:12 |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.
Contoh pola pemeriksaan klaim
Contoh berikut menunjukkan bagaimana Azure memfasilitasi implementasi Pola Pemeriksaan Klaim:
Sistem olahpesan Azure: Contoh mencakup empat skenario sistem olahpesan Azure yang berbeda: Azure Queue Storage, Azure Event Hubs (Standard API), Azure Bus Layanan, dan Azure Event Hubs (Kafka API).
Pembuatan token pemeriksaan klaim otomatis vs. manual: Contoh ini juga menunjukkan dua metode untuk menghasilkan token pemeriksaan klaim. Dalam contoh kode 1-3, Azure Event Grid secara otomatis menghasilkan token saat aplikasi pengiriman mentransfer payload ke Azure Blob Storage. Contoh kode 4 menunjukkan proses pembuatan token manual menggunakan klien baris perintah yang dapat dieksekusi.
Pilih contoh yang sesuai dengan kebutuhan Anda dan ikuti tautan yang disediakan untuk melihat kode di GitHub:
| Kode Sampel | Skenario sistem olahpesan | Generator token | Menerima aplikasi | Penyimpanan data |
|---|---|---|---|---|
| Contoh kode 1 | Azure Queue Storage | Kisi Aktivitas Azure | Fungsi | Azure Blob Storage |
| Contoh kode 2 | Azure Event Hubs (Standard API) | Kisi Aktivitas Azure | Klien baris perintah yang dapat dieksekusi | Azure Blob Storage |
| Contoh kode 3 | Azure Service Bus | Kisi Aktivitas Azure | Fungsi | Azure Blob Storage |
| Contoh kode 4 | Azure Event Hubs (Kafka API) | Klien baris perintah yang dapat dieksekusi | Fungsi | Azure Blob Storage |
Langkah berikutnya
- Situs Pola Integrasi Perusahaan memiliki deskripsi pola ini.
- Untuk contoh lain, lihat Menangani pesan Bus Layanan besar menggunakan pola Claim-Check (posting blog).
- Pola alternatif untuk menangani pesan besar adalah Terpisah dan Agregat.
- Pustaka seperti NServiceBus memberikan dukungan untuk pola ini secara langsung dengan fungsionalitas "bus data".