Pertimbangan pengodean pesan

Banyak aplikasi cloud menggunakan pesan asinkron untuk bertukar informasi antarkomponen sistem. Aspek penting dari pesan adalah format yang digunakan untuk menyandikan data payload. Setelah Anda memilih teknologi perpesanan, langkah selanjutnya adalah menentukan cara 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 kebutuhan konsumen:

• Bentuk atau struktur yang mendefinisikan payload pesan.
• Format pengodean untuk mewakili payload.
• 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 diskrit atau terkait (bidang). Tentukan karakteristik nilai untuk bidang tersebut. Pertimbangkan: Apa jenis data yang paling efisien? Apakah payload akan selalu memiliki bidang tertentu? Apakah payload akan memiliki satu rekaman atau serangkaian nilai berulang?

Kemudian, pilih format pengodean tergantung pada kebutuhan Anda. Faktor- tertentu termasuk kemampuan untuk membuat data yang sangat terstruktur jika Anda membutuhkannya, waktu yang dibutuhkan untuk mengodekan dan mentransfer pesan, dan kemampuan untuk mengurai payload. Bergantung pada format pengodean, pilih pustaka serialisasi yang didukung dengan baik.

Seorang konsumen pesan harus menyadari keputusan tersebut sehingga tahu cara membaca pesan masuk.

Untuk mentransfer pesan, produser serial pesan ke format pengodean. Pada akhir penerima, konsumen menghapus serialisasi payload untuk menggunakan data. Dengan cara ini kedua entitas berbagi model dan selama bentuknya tidak berubah, pesan berlanjut tanpa masalah. Saat kontrak berubah, format pengodean harus mampu menangani perubahan tanpa melanggar konsumen.

Beberapa format pengodean seperti JSON menggambarkan diri sendiri, yang berarti dapat diuraikan tanpa merujuk 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 pengodean

Format pengodean mendefinisikan bagaimana satu set data terstruktur direpresentasikan sebagai byte. Jenis pesan dapat memengaruhi pilihan format. Pesan yang terkait dengan transaksi bisnis kemungkinan besar akan berisi data yang sangat terstruktur. Selain itu, Anda mungkin ingin mengambilnya nanti untuk tujuan audit. Untuk aliran peristiwa, Anda mungkin ingin membaca urutan catatan secepat mungkin dan menyimpannya untuk analisis statistik.

Berikut adalah beberapa poin yang perlu dipertimbangkan saat memilih format pengodean.

Keterbacaan manusia

Pengodean pesan dapat secara luas dibagi menjadi format berbasis teks dan biner.

Dengan pengodean berbasis teks, payload pesan dalam teks biasa dan oleh karena itu 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 untuk debug dan mengirim ke log untuk memecahkan masalah kesalahan.

Kelemahannya adalah payload cenderung lebih besar. Format berbasis teks yang umum adalah JSON.

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 Bus Layanan 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 pengodean

Ukuran pesan memengaruhi performa I/O jaringan di seluruh kabel. Format biner lebih ringkas daripada format berbasis teks. Format biner memerlukan perpustakaan serialisasi/deserialisasi. Payload tidak dapat dibaca kecuali diterjemahkan.

Gunakan format biner jika Anda ingin mengurangi jejak kawat dan mentransfer pesan lebih cepat. Kategori format ini direkomendasikan dalam skenario saat penyimpanan atau bandwidth jaringan menjadi perhatian. Pilihan untuk format biner termasuk Apache Avro, Google Protocol Buffers (protobuf), MessagePack, dan Concise Binary Object Representation (CBOR). Pro dan kontra dari format tersebut dijelaskan di bagian Ini.

Kerugiannya adalah payload tidak dapat dibaca manusia. Sebagian besar format biner menggunakan sistem kompleks yang bisa jadi mahal untuk dipertahankan. Selain itu, membutuhkan perpustakaan khusus untuk memecahkan kode, yang mungkin tidak didukung jika Anda ingin mengambil data arsip.

Memahami payload

Payload pesan tiba sebagai urutan byte. Untuk mengurai urutan ini, konsumen harus memiliki akses ke metadata yang menggambarkan bidang data dalam payload. Ada dua pendekatan utama untuk menyimpan dan mendistribusikan metadata:

Metadata yang ditandai. Dalam beberapa pengodean, terutama JSON, bidang ditandai dengan tipe data dan pengenal, di dalam badan pesan. Format ini menggambarkan diri sendiri karena dapat diuraikan menjadi kamus nilai tanpa mengacu pada skema. Salah satu cara bagi konsumen untuk memahami bidang adalah dengan meminta nilai yang diharapkan. Misalnya, produsen mengirimkan payload di JSON. Konsumen mengurai JSON ke dalam kamus dan memeriksa keberadaan bidang untuk memahami payload. Cara lain adalah bagi konsumen untuk menerapkan model data yang dibagikan oleh produsen. Misalnya, jika Anda menggunakan bahasa yang diketik secara statis, banyak pustaka serialisasi JSON dapat mengurai string JSON ke dalam kelas yang diketik.

Skema. Skema secara resmi mendefinisikan struktur dan bidang data pesan. Dalam model ini, produsen dan konsumen memiliki kontrak melalui skema yang terdefinisi dengan baik. Skema dapat menentukan tipe data, bidang yang diperlukan/opsional, informasi versi, dan struktur payload. Produsen mengirimkan payload sesuai skema penulis. Konsumen menerima payload dengan menerapkan skema pembaca. Pesan diserialkan/deserialisasi dengan menggunakan perpustakaan khusus pengodean. Ada dua cara untuk mendistribusikan skema:

• Simpan skema sebagai pembukaan 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 perpustakaan tersebut untuk melakukan serialisasi dan deserialisasi payload. Perpustakaan juga menyediakan pemeriksaan kompatibilitas antara penulis dan skema pembaca. Protobuf dan Apache Avro mengikuti pendekatan itu. Perbedaan utamanya adalah protobuf memiliki definisi skema agnostik bahasa tetapi Avro menggunakan JSON kompak. Perbedaan lain adalah cara keduanya memformat 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 mengirimkan pengidentifikasi skema dalam pesan dan konsumen mengambil skema dengan menentukan pengenal itu dari penyimpanan eksternal. Keduanya menggunakan pustaka khusus format untuk membaca dan menulis pesan. Selain menyimpan skema, registri dapat memberikan pemeriksaan kompatibilitas untuk memastikan kontrak antara produsen dan konsumen tidak rusak saat skema berkembang.

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 potongan byte yang lebih kecil sangat penting atau Anda mengharapkan urutan rekaman. Biaya pemeliharaan toko skema eksternal bisa tinggi.

Namun, jika dekode payload sesuai permintaan lebih penting daripada ukuran, termasuk skema dengan payload atau pendekatan metadata yang ditandai menjamin dekode setelahnya. Mungkin ada peningkatan ukuran pesan yang signifikan dan dapat memengaruhi biaya penyimpanan.

Versi skema

Saat persyaratan bisnis berubah, bentuknya diperkirakan akan berubah, dan skema akan berkembang. Pembuatan versi memungkinkan produsen menunjukkan pembaruan skema yang mungkin menyertakan fitur baru. Ada dua aspek untuk versi:

• Konsumen harus menyadari perubahan tersebut.

  Salah satu caranya adalah bagi konsumen untuk memeriksa semua bidang untuk menentukan apakah skema telah berubah. Cara lain adalah agar produser menerbitkan nomor versi skema dengan pesan. Saat skema berkembang, produser meningkatkan versi.

• Perubahan tidak boleh memengaruhi atau menghancurkan logika bisnis konsumen.

  Misalkan bidang ditambahkan ke skema yang ada. Jika konsumen yang menggunakan versi baru mendapatkan payload sesuai versi lama, logika mereka mungkin pecah jika mereka tidak dapat mengabaikan kurangnya bidang baru. Mempertimbangkan kasus sebaliknya, 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 akan diisi dengan nilai default. Format lain seperti protobuf menyediakan fungsi serupa melalui bidang yang diperlukan dan opsional.

Struktur payload

Pertimbangkan cara data diatur dalam payload. Apakah itu urutan catatan atau payload tunggal diskrit? Struktur payload dapat dikategorikan ke dalam salah satu model ini:

• Array/kamus/nilai: Mendefinisikan entri yang menyimpan nilai dalam satu atau array multidimensi. Entri memiliki pasangan nilai kunci yang unik. Entri dapat diperpanjang 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 terlalu berlebihan yang 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 serangkaian informasi berulang, seperti data deret waktu.

  CSV adalah salah satu format berbasis teks yang paling sederhana. CSV menyajikan data sebagai urutan rekaman dengan header umum. Untuk pengodean biner, Apache Avro memiliki pembukaan yang mirip dengan header CSV tetapi menghasilkan ukuran pengodean yang ringkas.

Dukungan perpustakaan

Pertimbangkan untuk menggunakan format terkenal melalui model berpemilik.

Format terkenal didukung melalui pustaka yang didukung secara universal oleh masyarakat. Dengan format khusus, Anda memerlukan pustaka tertentu. Logika bisnis Anda mungkin harus bekerja di sekitar beberapa pilihan desain API yang disediakan oleh pustaka.

Untuk format berbasis skema, pilih pustaka pengodean yang melakukan pemeriksaan kompatibilitas antara skema pembaca dan penulis. Pustaka pengodean tertentu, seperti Apache Avro, mengharapkan konsumen menentukan skema penulis dan pembaca sebelum membatalkan kebijakan pesan. Pemeriksaan ini memastikan bahwa konsumen mengetahui versi skema.

Interoperabilitas

Pilihan format Anda mungkin tergantung pada beban kerja atau ekosistem teknologi tertentu.

Contohnya:

• Azure Stream Analytics memiliki dukungan asli untuk JSON, CSV, dan Avro. Saat menggunakan Stream Analytics, masuk akal untuk memilih salah satu format ini jika memungkinkan. Jika tidak, Anda dapat memberikan deserializer kustom, tetapi ini menambahkan beberapa kompleksitas tambahan pada solusi Anda.

• JSON adalah format pertukaran standar untuk HTTP REST API. 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 format yang berbeda.

Ini hanya dua contoh pertimbangan interoperabilitas. Secara umum, format standar akan lebih dapat dioperasikan daripada format khusus. Dalam opsi berbasis teks, JSON adalah salah satu yang paling dapat dioperasikan.

Pilihan untuk format pengodean

Berikut adalah beberapa format pengodean yang populer. Faktor dalam pertimbangan 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 tersedia secara universal. Ini paling dapat dioperasikan dan merupakan format pengodean default untuk banyak layanan pesan.

Menjadi format berbasis teks, tidak efisien melalui kawat dan bukan pilihan ideal dalam kasus saat penyimpanan menjadi perhatian. Jika Anda mengembalikan item cache langsung ke klien melalui HTTP, menyimpan JSON dapat menghemat biaya deserialisasi dari format lain dan kemudian serialisasi ke JSON.

Gunakan JSON untuk pesan rekaman tunggal atau untuk urutan pesan, yaitu setiap pesan memiliki skema yang berbeda. Hindari menggunakan JSON untuk urutan rekaman, seperti untuk data deret waktu.

Ada variasi lain dari JSON seperti JSON biner (BSON), yang merupakan pengodean biner yang selaras untuk bekerja dengan MongoDB.

Nilai yang Dipisahkan Koma (CSV)

CSV adalah format tabular berbasis teks. Header tabel menunjukkan bidang. Ini adalah pilihan yang lebih disukai saat pesan berisi serangkaian rekaman.

Kerugiannya adalah kurangnya standardisasi. Ada banyak cara untuk mengekspresikan pemisah, header, dan bidang kosong.

Protocol Buffers (protobuf)

Buffer Protokol (atau protobuf) adalah format serialisasi yang menggunakan file definisi yang sangat diketik untuk menentukan skema dalam pasangan kunci/nilai. File definisi ini kemudian dikompilasi ke kelas khusus bahasa yang digunakan untuk serialisasi dan deserialisasi pesan.

Pesan berisi payload kecil biner terkompresi, yang hasilnya adalah transfer yang lebih cepat. Kelemahannya adalah payload tidak dapat dibaca manusia. Juga, karena skema eksternal, tidak dianjurkan untuk kasus saat 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. Sebaliknya, data serial selalu menyertakan pembukaan skema.

Pembukaan dapat menahan header atau pengidentifikasi skema. Karena ukuran pengodean yang lebih kecil, Avro direkomendasikan untuk streaming data. Selain itu, karena memiliki header yang berlaku untuk satu set rekaman, ini adalah pilihan yang baik untuk data tabular.

MessagePack

MessagePack adalah format serialisasi biner yang dirancang agar ringkas untuk transmisi melalui kawat. Tidak ada skema pesan atau pemeriksaan 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 atas MessagePack adalah sesuai dengan IETF di RFC7049.

Langkah berikutnya

• Memahami pola desain pesan untuk aplikasi cloud.