Pertimbangan pengodean pesan
Banyak aplikasi cloud menggunakan pesan asinkron untuk bertukar informasi antar komponen sistem. Aspek penting dari olahpesan adalah format yang digunakan untuk mengodekan data payload. Setelah Anda memilih teknologi olahpesan, langkah selanjutnya adalah menentukan bagaimana pesan akan dikodekan. Ada banyak opsi yang tersedia, tetapi pilihan yang tepat tergantung pada kasus penggunaan Anda.
Artikel ini menjelaskan beberapa pertimbangan.
Kebutuhan pertukaran pesan
Pertukaran pesan antara produsen dan konsumen membutuhkan:
- Bentuk atau struktur yang menentukan payload pesan.
- Format pengkodean untuk mewakili muatan data.
- Pustaka serialisasi untuk membaca dan menulis payload yang dikodekan.
Produsen pesan mendefinisikan bentuk pesan berdasarkan logika bisnis dan informasi yang ingin dikirimnya kepada konsumen. Untuk menyusun bentuk, bagi informasi menjadi subjek (bidang) diskrit atau terkait. Tentukan karakteristik nilai untuk bidang tersebut. Anda perlu mempertimbangkan pertanyaan-pertanyaan berikut.
- Apa jenis data yang paling efisien?
- Apakah payload selalu memiliki bidang tertentu?
- Apakah payload memiliki satu rekaman atau sekumpulan nilai berulang?
Kemudian, pilih format pengodean sesuai kebutuhan Anda. Faktor-faktor tertentu termasuk kemampuan untuk membuat data yang sangat terstruktur jika Anda membutuhkannya, waktu yang diperlukan untuk mengodekan dan mentransfer pesan, dan kemampuan untuk mengurai payload. Bergantung pada format pengodean, pilih pustaka serialisasi yang didukung dengan baik.
Konsumen pesan harus mengetahui keputusan tersebut sehingga tahu cara membaca pesan masuk.
Untuk mentransfer pesan, produsen menserialisasikan pesan ke format pengodean. Di sisi penerima, konsumen mendeserialisasi payload untuk menggunakan data. Dengan cara ini kedua entitas berbagi model dan selama bentuk tidak berubah, olahpesan berlanjut tanpa masalah. Ketika kontrak berubah, format pengodean harus mampu menangani perubahan tanpa merusak konsumen.
Beberapa format pengodean seperti JSON dijelaskan sendiri, yang berarti mereka dapat diurai tanpa mereferensikan skema. Namun, format tersebut cenderung menghasilkan pesan yang lebih besar. Dengan format lain, data mungkin tidak diurai dengan mudah tetapi pesannya ringkas. Artikel ini menyoroti beberapa faktor yang dapat membantu Anda memilih format.
Pertimbangan format pengkodean
Format pengodean menentukan bagaimana sekumpulan data terstruktur diwakili sebagai byte. Jenis pesan dapat memengaruhi pilihan format. Pesan yang terkait dengan transaksi bisnis kemungkinan besar berisi data yang sangat terstruktur. Selain itu, Anda mungkin ingin mengambilnya nanti untuk tujuan audit. Untuk aliran peristiwa, Anda mungkin ingin membaca urutan rekaman secepat mungkin dan menyimpannya untuk analisis statistik.
Berikut adalah beberapa poin yang perlu dipertimbangkan saat memilih format pengodean.
Keterbacaan manusia
Pengodean pesan dapat dibagi secara luas menjadi format berbasis teks dan biner.
Dengan pengodean berbasis teks, payload pesan berbentuk teks biasa sehingga dapat diperiksa oleh seseorang tanpa menggunakan pustaka kode apa pun. Format yang dapat dibaca manusia cocok untuk data arsip. Selain itu, karena manusia dapat membaca payload, format berbasis teks lebih mudah di-debug dan dikirim ke log untuk memecahkan masalah kesalahan.
Kelemahannya adalah muatan cenderung lebih besar. Ukuran payload sering dapat dikurangi melalui proses minifikasi, selama dapat dibalik untuk dibaca oleh manusia ketika diperlukan. Format berbasis teks umum adalah JSON dan YAML.
Enkripsi
Jika ada data sensitif dalam pesan, pertimbangkan apakah pesan tersebut harus dienkripsi secara keseluruhan seperti yang dijelaskan dalam panduan ini tentang mengenkripsi data Azure Service Bus saat tidak aktif. Atau, jika hanya bidang tertentu yang perlu dienkripsi dan Anda lebih suka mengurangi biaya cloud, pertimbangkan untuk menggunakan pustaka seperti NServiceBus untuk itu.
Ukuran pengkodean
Ukuran pesan berdampak pada performa I/O jaringan di seluruh kabel. Format biner lebih ringkas daripada format berbasis teks. Format biner memerlukan pustaka serialisasi/deserialisasi. Payload tidak dapat dibaca kecuali didekodekan.
Gunakan format biner jika Anda ingin mengurangi jejak kabel dan mentransfer pesan lebih cepat. Kategori format ini direkomendasikan dalam skenario di mana penyimpanan atau bandwidth jaringan menjadi perhatian. Opsi untuk format biner termasuk Apache Avro, Buffer Protokol Google (protobuf), MessagePack, dan Concise Binary Object Representation (CBOR). Pro dan kontra dari format tersebut dijelaskan selanjutnya dalam Pilihan untuk format pengodean.
Kerugiannya adalah bahwa payload tidak dapat dibaca manusia. Sebagian besar format biner menggunakan sistem kompleks yang dapat mahal untuk dipertahankan. Selain itu, mereka memerlukan pustaka khusus untuk mendekode, yang mungkin tidak didukung jika Anda ingin mengambil data arsip.
Untuk format nonbiner, penggunaan proses minifikasi untuk menghapus spasi dan karakter yang tidak diperlukan dalam hal teknis, sambil tetap mempertahankan keselarasan dengan spesifikasi format, dapat membantu mengurangi ukuran pengkodean. Evaluasi kemampuan encoder Anda untuk menjadikan minifikasi sebagai default. Misalnya, JsonSerializerOptions.WriteIndented dari . System.Text.Json.JsonSerializer NET mengontrol minifikasi otomatis saat membuat teks JSON.
Memahami muatan (payload)
Muatan pesan tiba sebagai rangkaian byte. Untuk mengurai urutan ini, konsumen harus memiliki akses ke metadata yang menjelaskan bidang data dalam payload. Ada dua pendekatan utama untuk menyimpan dan mendistribusikan metadata:
Metadata yang ditandai. Dalam beberapa pengodean, terutama JSON, bidang diberi tanda berdasarkan jenis data dan pengidentifikasinya, yang terdapat dalam isi pesan. Format ini menggambarkan sendiri karena dapat diuraikan ke dalam kamus nilai tanpa mengacu pada skema. Salah satu cara bagi konsumen untuk memahami bidang adalah dengan mengkueri nilai yang diharapkan. Misalnya, produsen mengirim payload di JSON. Konsumen menguraikan JSON ke dalam kamus dan memeriksa keberadaan bidang untuk memahami payload. Cara lain adalah agar konsumen menerapkan model data yang dibagikan oleh produsen. Misalnya, jika Anda menggunakan bahasa yang ditik secara statis, banyak pustaka serialisasi JSON dapat mengurai string JSON ke dalam kelas yang ditik.
Skema
Simpan skema sebagai preamble atau header dalam pesan tetapi terpisah dari payload.
Simpan skema secara eksternal.
Beberapa format pengodean menentukan skema dan menggunakan alat yang menghasilkan kelas dari skema. Produsen dan konsumen menggunakan kelas dan pustaka tersebut untuk menserialisasikan dan mendeserialisasi payload. Pustaka juga memberikan pemeriksaan kompatibilitas antara skema penulis dan pembaca. Baik protobuf maupun Apache Avro mengikuti pendekatan tersebut. Perbedaan utamanya adalah bahwa protobuf memiliki definisi skema bahasa-agnostik tetapi Avro menggunakan JSON yang ringkas. Perbedaan lain adalah dalam cara kedua format memberikan pemeriksaan kompatibilitas antara skema pembaca dan penulis.
Cara lain untuk menyimpan skema secara eksternal dalam registri skema. Pesan berisi referensi ke skema dan payload. Produsen mengirim pengidentifikasi skema dalam pesan dan konsumen mengambil skema dengan menentukan pengidentifikasi tersebut dari penyimpanan eksternal. Kedua belah pihak menggunakan pustaka berformat khusus untuk membaca dan menulis pesan. Selain menyimpan skema, registri dapat memberikan pemeriksaan kompatibilitas untuk memastikan kontrak antara produsen dan konsumen tidak rusak saat skema berevolusi.
Sebelum memilih pendekatan, putuskan apa yang lebih penting: ukuran data transfer atau kemampuan untuk mengurai data yang diarsipkan nanti.
Menyimpan skema bersama dengan payload menghasilkan ukuran pengodean yang lebih besar dan lebih disukai untuk pesan terputus-putus. Pilih pendekatan ini jika mentransfer pecahan byte yang lebih kecil sangat penting atau Anda mengharapkan rangkaian data. Biaya mempertahankan penyimpanan skema eksternal bisa tinggi.
Namun, jika decoding sesuai permintaan dari payload lebih penting daripada ukuran, dengan menyertakan skema dalam payload atau menggunakan pendekatan metadata bertanda menjamin dapat didekodekan setelahnya. Mungkin ada peningkatan ukuran pesan yang signifikan dan memengaruhi biaya penyimpanan.
Pengelolaan versi skema
Ketika persyaratan bisnis berubah, bentuknya diharapkan berubah, dan skema akan berkembang. Penerapan versi memungkinkan produsen untuk menunjukkan pembaruan skema yang mungkin menyertakan fitur baru. Ada dua aspek untuk penerapan versi:
Konsumen harus mengetahui perubahan tersebut.
Salah satu caranya adalah agar konsumen memeriksa semua bidang untuk menentukan apakah skema telah berubah. Cara lain adalah bagi produsen untuk menerbitkan nomor versi skema bersama pesan. Ketika skema berevolusi, produsen meningkatkan versi.
Perubahan tidak boleh memengaruhi atau memutus logika bisnis konsumen.
Misalkan bidang ditambahkan ke skema yang ada. Jika konsumen yang menggunakan versi baru mendapatkan payload seperti pada versi lama, logika mereka mungkin rusak jika mereka tidak dapat mengatasi ketiadaan bidang baru. Mempertimbangkan kasus terbalik, misalkan bidang dihapus dalam skema baru. Konsumen yang menggunakan skema lama mungkin tidak dapat membaca data.
Format pengodean seperti Avro menawarkan kemampuan untuk menentukan nilai default. Dalam contoh sebelumnya, jika bidang ditambahkan dengan nilai default, bidang yang hilang diisi dengan nilai default. Format lain seperti protobuf menyediakan fungsionalitas serupa melalui bidang yang diperlukan dan opsional.
Struktur payload
Pertimbangkan cara penyusunan data dalam muatan. Apakah itu urutan rekaman atau payload tunggal diskrit? Struktur payload dapat dikategorikan ke dalam salah satu model ini:
Array/dictionary/value: Mendefinisikan entri yang menyimpan nilai dalam array satu atau multi-dimensi. Entri memiliki pasangan kunci-nilai yang unik. Ini dapat diperluas untuk mewakili struktur yang kompleks. Beberapa contohnya termasuk, JSON, Apache Avro, dan MessagePack.
Tata letak ini cocok jika pesan dikodekan secara individual dengan skema yang berbeda. Jika Anda memiliki beberapa rekaman, payload bisa menjadi terlalu berlebih dan menyebabkan payload membengkak.
Data tabular: Informasi dibagi menjadi baris dan kolom. Setiap kolom menunjukkan bidang, atau subjek informasi dan setiap baris berisi nilai untuk bidang tersebut. Tata letak ini efisien untuk kumpulan informasi berulang, seperti data rangkaian waktu.
CSV adalah salah satu format berbasis teks paling sederhana. Ini menyajikan data sebagai urutan rekaman dengan header umum. Untuk pengodean biner, Apache Avro memiliki pendahuluan yang mirip dengan header CSV, namun menghasilkan ukuran pengodean yang lebih ringkas.
Dukungan perpustakaan
Anda harus menggunakan format terkenal daripada model eksklusif. Format terkenal didukung melalui pustaka yang didukung secara universal oleh komunitas. Dengan format khusus, Anda memerlukan pustaka tertentu. Logika bisnis Anda mungkin perlu menyesuaikan diri dengan beberapa pilihan desain API yang dirancang oleh perpustakaan.
Untuk format berbasis skema, pilih pustaka pengodean yang membuat pemeriksaan kompatibilitas antara skema pembaca dan penulis. Perpustakaan pengodean tertentu, seperti Apache Avro, memerlukan konsumen menentukan skema penulis dan pembaca sebelum mendeserialisasi pesan. Pemeriksaan ini memastikan bahwa konsumen mengetahui versi skema.
Interoperabilitas
Pilihan format Anda mungkin bergantung pada beban kerja atau ekosistem teknologi tertentu.
Misalnya:
Azure Stream Analytics memiliki dukungan asli untuk JSON, CSV, dan Avro. Saat beban kerja Anda menggunakan Azure Stream Analytics, masuk akal untuk memilih salah satu format ini.
JSON adalah format pertukaran standar untuk API HTTP REST. Jika aplikasi Anda menerima payload JSON dari klien dan kemudian menempatkannya ke antrean pesan untuk pemrosesan asinkron, mungkin masuk akal untuk menggunakan JSON untuk olahpesan, daripada mengodekan ulang ke dalam format yang berbeda.
Ini hanya dua contoh pertimbangan interoperabilitas. Secara umum, format standar lebih dapat dioperasikan daripada format kustom. Dalam opsi berbasis teks, JSON adalah salah satu yang paling dapat dioperasikan.
Pilihan untuk format pengodean
Berikut adalah beberapa format pengodean populer. Pertimbangkan faktor-faktor sebelum Anda memilih format.
JSON
JSON adalah standar terbuka (IETF RFC8259). Ini adalah format berbasis teks yang mengikuti model array/kamus/nilai.
JSON dapat digunakan untuk menandai metadata dan Anda dapat mengurai payload tanpa skema. JSON mendukung opsi untuk menentukan bidang opsional, yang membantu kompatibilitas maju dan mundur.
Keuntungan terbesar adalah bahwa ia tersedia secara universal. Ini adalah yang paling kompatibel dan merupakan format pengodean default untuk banyak layanan olahpesan.
Menjadi format berbasis teks, ini tidak efisien melalui kawat dan bukan pilihan ideal dalam kasus di mana penyimpanan menjadi perhatian. Gunakan teknik minifikasi jika memungkinkan. Jika Anda mengembalikan item yang di-cache langsung ke klien melalui HTTP, menyimpan JSON dapat menghemat biaya deserialisasi dari format lain dan kemudian membuat serialisasi ke JSON.
Gunakan JSON untuk pesan rekaman tunggal atau untuk urutan pesan di mana setiap pesan memiliki skema yang berbeda. Hindari menggunakan JSON untuk urutan rekaman, seperti untuk data rangkaian waktu.
Ada variasi lain dari JSON seperti biner JSON (BSON), yang merupakan pengodean biner yang selaras untuk bekerja dengan MongoDB.
Nilai Comma-Separated (CSV)
CSV adalah format tabular berbasis teks. Tajuk tabel mengindikasikan bidang-bidang tersebut. Ini adalah pilihan pilihan di mana pesan berisi sekumpulan rekaman.
Kerugiannya adalah kurangnya standarisasi. Ada banyak cara untuk mengekspresikan pemisah, header, dan bidang kosong.
Protocol Buffers (protobuf)
Protocol Buffers (atau protobuf) adalah format serialisasi yang menggunakan file definisi bertipedata kuat untuk mendefinisikan skema dalam pasangan kunci/nilai. File definisi ini kemudian dikompilasi ke kelas khusus bahasa yang digunakan untuk menserialisasikan dan mendeserialisasi pesan.
Pesan berisi payload kecil biner terkompresi, yang hasilnya lebih cepat ditransfer. Kelemahannya adalah payload tidak dapat dibaca manusia. Selain itu, karena skemanya eksternal, tidak disarankan untuk kasus di mana Anda harus mengambil data yang diarsipkan.
Apache Avro
Apache Avro adalah format serialisasi biner yang menggunakan file definisi yang mirip dengan protobuf tetapi tidak ada langkah kompilasi. Sebagai gantinya, data berseri selalu menyertakan pendahuluan skema.
Preamble dapat memuat header atau pengidentifikasi skema. Karena ukuran pengodean yang lebih kecil, Avro direkomendasikan untuk data streaming. Selain itu, karena memiliki header yang berlaku untuk sekumpulan rekaman, ini adalah pilihan yang baik untuk data tabular.
Apache Parquet
Apache Parquet adalah format file penyimpanan kolom yang biasanya terkait dengan Apache Hadoop dan kerangka kerja pemrosesan data terkait.
Format ini mendukung kompresi data dan memiliki beberapa kemampuan terbatas untuk mendukung evolusi skema. Ini adalah contoh format yang mungkin hanya Anda gunakan jika ada pilihan teknologi big data lainnya dalam beban kerja Anda yang bertanggung jawab untuk membuat atau menggunakan data ini.
MessagePack
MessagePack adalah format serialisasi biner yang dirancang agar ringkas untuk transmisi melalui kawat. Tidak ada pemeriksaan skema pesan atau jenis pesan. Format ini tidak disarankan untuk penyimpanan massal.
CBOR
Concise Binary Object Representation (CBOR) (Spesifikasi) adalah format biner yang menawarkan ukuran pengodean kecil. Keuntungan dari CBOR daripada MessagePack adalah bahwa ia mematuhi IETF dalam RFC7049.