İleti kodlama konusunda dikkat edilmesi gerekenler

Birçok bulut uygulaması, sistemin bileşenleri arasında bilgi alışverişi yapmak için zaman uyumsuz iletiler kullanır. Mesajlaşmanın önemli bir yönü, yük verilerini kodlamak için kullanılan biçimdir. Bir mesajlaşma teknolojisi seçtikten sonra, sonraki adım iletilerin nasıl kodlanacağını tanımlamaktır. Birçok seçenek vardır, ancak doğru seçim kullanım örneğine bağlıdır.

Bu makalede dikkat edilmesi gereken bazı noktalar açıklanmaktadır.

İleti değişimi gereksinimleri

Üretici ve tüketici gereksinimleri arasında ileti alışverişi:

• İletinin yükünü tanımlayan bir şekil veya yapı.
• Yükü temsil eden bir kodlama biçimi.
• Kodlanmış yükü okumak ve yazmak için serileştirme kitaplıkları.

İletinin üreticisi, ileti şeklini iş mantığına ve tüketicilere göndermek istediği bilgilere göre tanımlar. Şekli yapılandırmak için, bilgileri ayrık veya ilgili konulara (alanlar) bölün. Bu alanların değerlerinin özelliklerine karar verin. Göz önünde bulundurun: En verimli veri türü nedir? Yükte her zaman belirli alanlar olacak mı? Yükün tek bir kaydı mı yoksa yinelenen bir değer kümesi mi olacak?

Ardından, ihtiyacınıza bağlı olarak bir kodlama biçimi seçin. Belirli faktörler arasında ihtiyacınız olduğunda yüksek oranda yapılandırılmış veriler oluşturma, iletiyi kodlamak ve aktarmak için geçen süre ve yükü ayrıştırma olanağı yer alır. Kodlama biçimine bağlı olarak, iyi desteklenen bir serileştirme kitaplığı seçin.

İletinin tüketicisi, gelen iletilerin nasıl okunduğunu bilmesi için bu kararların farkında olmalıdır.

İletileri aktarmak için, üretici iletiyi bir kodlama biçimine serileştirir. Alıcı sonunda, tüketici verileri kullanmak için yükü seri durumdan çıkartır. Bu şekilde her iki varlık da modeli paylaşır ve şekil değişmediği sürece mesajlaşma sorunsuz devam eder. Sözleşme değiştiğinde, kodlama biçimi tüketiciyi bozmadan değişikliği işleyebilecek şekilde olmalıdır.

JSON gibi bazı kodlama biçimleri kendi kendine açıklayıcıdır; başka bir deyişle şemaya başvurmadan ayrıştırılabilirler. Ancak, bu tür biçimler daha büyük iletiler verme eğilimindedir. Diğer biçimlerde, veriler kolayca ayrıştırılamayabilir, ancak iletiler sıkıştırılır. Bu makalede, biçim seçmenize yardımcı olabilecek bazı faktörler vurgulanmaktadır.

Kodlama biçimiyle ilgili dikkat edilmesi gerekenler

Kodlama biçimi, yapılandırılmış bir veri kümesinin bayt olarak nasıl temsil edilir tanımlar. İleti türü biçim seçimini etkileyebilir. İş işlemleriyle ilgili iletiler büyük olasılıkla yüksek oranda yapılandırılmış veriler içerir. Ayrıca, denetim amacıyla daha sonra almak isteyebilirsiniz. Bir olay akışı için, bir kayıt dizisini mümkün olan en kısa sürede okumak ve istatistiksel analiz için depolamak isteyebilirsiniz.

Kodlama biçimi seçerken göz önünde bulundurmanız gereken bazı noktalar aşağıdadır.

İnsan okunabilirliği

İleti kodlaması geniş ölçüde metin tabanlı ve ikili biçimlere ayrılabilir.

Metin tabanlı kodlama ile ileti yükü düz metin biçimindedir ve bu nedenle herhangi bir kod kitaplığı kullanmadan bir kişi tarafından denetlenebilir. İnsan tarafından okunabilir biçimler arşiv verileri için uygundur. Ayrıca, bir insan yükü okuyabildiğinden, metin tabanlı biçimlerin hata ayıklaması ve sorun giderme için günlüklere gönderilmesi daha kolaydır.

Dezavantajı, yükün daha büyük olma eğiliminde olmasıdır. Yaygın bir metin tabanlı biçim JSON'dır.

Şifreleme

İletilerde hassas veriler varsa, bekleyen Azure Service Bus verilerini şifrelemeye ilişkin bu kılavuzda açıklandığı gibi bu iletilerin tamamen şifrelenip şifrelenmemesi gerektiğini göz önünde bulundurun. Alternatif olarak, yalnızca belirli alanların şifrelenmesini gerekiyorsa ve bulut maliyetlerini azaltmayı tercih ediyorsanız bunun için NServiceBus gibi bir kitaplık kullanmayı göz önünde bulundurun.

Kodlama boyutu

İleti boyutu, ağ G/Ç performansını kablo üzerinde etkiler. İkili biçimler, metin tabanlı biçimlerden daha küçüktür. İkili biçimler serileştirme/seri durumdan çıkarma kitaplıkları gerektirir. Şifresi çözülmedikçe yük okunamaz.

Kablo ayak izini azaltmak ve iletileri daha hızlı aktarmak istiyorsanız ikili biçim kullanın. Bu biçim kategorisi, depolama veya ağ bant genişliğinin sorun olduğu senaryolarda önerilir. İkili biçimler için seçenekler Apache Avro, Google Protokol Arabellekleri (protobuf), MessagePack ve Kısa İkili Nesne Gösterimi (CBOR) içerir. Bu biçimlerin avantajları ve dezavantajları bu bölümde açıklanmıştır.

Dezavantajı, yükün insan tarafından okunamıyor olmasıdır. Çoğu ikili biçim, bakımı maliyetli olabilecek karmaşık sistemler kullanır. Ayrıca, arşiv verilerini almak istiyorsanız desteklenmeyen özel kitaplıkların kodunu çözmeleri gerekir.

Yükü anlama

İleti yükü bayt dizisi olarak gelir. Bu sırayı ayrıştırmak için tüketicinin yükteki veri alanlarını açıklayan meta verilere erişimi olmalıdır. Meta verileri depolamak ve dağıtmak için iki ana yaklaşım vardır:

Etiketli meta veriler. Özellikle JSON gibi bazı kodlamalarda alanlar, iletinin gövdesindeki veri türü ve tanımlayıcıyla etiketlenir. Bu biçimler , bir şemaya başvurmadan bir değer sözlüğüne ayrıştırılabildiği için kendi kendini açıklar . Tüketicinin alanları anlamasının bir yolu, beklenen değerleri sorgulamaktır. Örneğin, üretici JSON'da bir yük gönderir. Tüketici JSON'ı bir sözlüğe ayrıştırarak yükü anlamak için alanların varlığını denetler. Bir diğer yol da tüketicinin üretici tarafından paylaşılan bir veri modelini uygulamasıdır. Örneğin, statik olarak yazılan bir dil kullanıyorsanız, birçok JSON serileştirme kitaplığı bir JSON dizesini türlenmiş bir sınıfa ayrıştırabilir.

Şema. Şema, iletinin yapısını ve veri alanlarını resmi olarak tanımlar. Bu modelde, üretici ve tüketicinin iyi tanımlanmış bir şema aracılığıyla bir sözleşmesi vardır. Şema veri türlerini, gerekli/isteğe bağlı alanları, sürüm bilgilerini ve yükün yapısını tanımlayabilir. Üretici, yazıcı şemasına göre yükü gönderir. Tüketici, bir okuyucu şeması uygulayarak yükü alır. İleti, kodlamaya özgü kitaplıklar kullanılarak serileştirilir/seri durumdan çıkarılır. Şemaları dağıtmanın iki yolu vardır:

• Şemayı iletide önceden oluşturulmuş veya üst bilgi olarak depolayın ancak yükten ayırın.

• Şemayı harici olarak depolayın.

Bazı kodlama biçimleri şemayı tanımlar ve şemadan sınıf oluşturan araçları kullanır. Üretici ve tüketici yükü seri hale getirmek ve seri durumdan çıkarmak için bu sınıfları ve kitaplıkları kullanır. Kitaplıklar, yazıcı ve okuyucu şeması arasında uyumluluk denetimleri de sağlar. Hem protobuf hem de Apache Avro bu yaklaşımı izler. Önemli fark, protobuf'un dilden bağımsız bir şema tanımına sahip olması, ancak Avro'nun küçük JSON kullanmasıdır. Diğer bir fark, her iki biçimin de okuyucu ve yazıcı şemaları arasında uyumluluk denetimleri sağlamasıdır.

Şemayı bir şema kayıt defterinde harici olarak depolamanın başka bir yolu. İleti, şemaya ve yüke bir başvuru içerir. Üretici iletide şema tanımlayıcısını gönderir ve tüketici bu tanımlayıcıyı bir dış depodan belirterek şemayı alır. her iki taraf da iletileri okumak ve yazmak için biçime özgü kitaplığı kullanır. Şemayı depolamanın yanı sıra, bir kayıt defteri üretici ve tüketici arasındaki sözleşmenin şema geliştikçe bozulmadığından emin olmak için uyumluluk denetimleri sağlayabilir.

Bir yaklaşım seçmeden önce neyin daha önemli olduğuna karar verin: veri aktarımı boyutu veya arşivlenen verileri daha sonra ayrıştırma olanağı.

Şemanın yükle birlikte depolanması daha büyük bir kodlama boyutu sağlar ve aralıklı iletiler için tercih edilir. Daha küçük bayt öbeklerinin aktarılması çok önemliyse veya bir kayıt dizisi bekliyorsanız bu yaklaşımı seçin. Dış şema deposunun bakımının maliyeti yüksek olabilir.

Ancak yükün isteğe bağlı kod çözmesi, yükü içeren şema veya etiketli meta veri yaklaşımı da dahil olmak üzere boyuttan daha önemliyse, daha sonra kod çözmeyi garanti eder. İleti boyutunda önemli bir artış olabilir ve depolama maliyetini etkileyebilir.

Şema sürümü oluşturma

İş gereksinimleri değiştikçe şeklin değişmesi beklenir ve şema gelişir. Sürüm oluşturma, üreticinin yeni özellikler içerebilecek şema güncelleştirmelerini belirtmesine olanak tanır. Sürüm oluşturmanın iki yönü vardır:

• Tüketici değişikliklerin farkında olmalıdır.

  Bunun bir yolu, tüketicinin şemanın değişip değişmediğini belirlemek için tüm alanları denetlemesidir. Başka bir yol, üreticinin iletiyle birlikte bir şema sürüm numarası yayımlamasıdır. Şema geliştikçe üretici sürümü artırır.

• Değişiklikler tüketicilerin iş mantığını etkilememeli veya bozmamalıdır.

  Mevcut şemaya bir alan eklendiğini varsayalım. Yeni sürümü kullanan tüketiciler eski sürüme göre bir yük alırsa, yeni alanın eksikliğini atlayamazlarsa mantığı bozulabilir. Ters durumu göz önünde bulundurarak, yeni şemada bir alanın kaldırıldığını varsayalım. Eski şemayı kullanan tüketiciler verileri okuyamayabilir.

  Avro gibi kodlama biçimleri, varsayılan değerleri tanımlama olanağı sunar. Yukarıdaki örnekte, alan varsayılan bir değerle eklenirse, eksik alan varsayılan değerle doldurulur. Protobuf gibi diğer biçimler, gerekli ve isteğe bağlı alanlar aracılığıyla benzer işlevler sağlar.

Yük yapısı

Verilerin yükte nasıl düzenlendiğini göz önünde bulundurun. Bu bir kayıt dizisi mi yoksa ayrık tek bir yük mü? Yük yapısı şu modellerden birinde kategorilere ayırılabilir:

• Dizi/sözlük/değer: Bir veya çok boyutlu dizilerdeki değerleri tutan girdileri tanımlar. Girdilerin benzersiz anahtar-değer çiftleri vardır. Karmaşık yapıları temsil etmek için genişletilebilir. Bazı örnekler şunlardır: JSON, Apache Avro ve MessagePack.

  İletiler farklı şemalarla ayrı ayrı kodlanmışsa bu düzen uygundur. Birden çok kaydınız varsa, yük aşırı yedekli hale gelebilir ve bu da yükün kabarmasına neden olabilir.

• Tablo verileri: Bilgiler satırlara ve sütunlara ayrılır. Her sütun bir alanı veya bilgilerin konusunu belirtir ve her satır bu alanların değerlerini içerir. Bu düzen, zaman serisi verileri gibi yinelenen bir bilgi kümesi için verimlidir.

  CSV, en basit metin tabanlı biçimlerden biridir. Verileri ortak üst bilgi içeren bir kayıt dizisi olarak sunar. İkili kodlama için Apache Avro'nun ön derlemesi CSV üst bilgisine benzer ancak küçük kodlama boyutu oluşturur.

Kitaplık desteği

Özel bir model üzerinde iyi bilinen biçimler kullanmayı göz önünde bulundurun.

İyi bilinen biçimler, topluluk tarafından evrensel olarak desteklenen kitaplıklar aracılığıyla desteklenir. Özelleştirilmiş biçimlerle, belirli kitaplıklara ihtiyacınız vardır. İş mantığınızın kitaplıklar tarafından sağlanan BAZı API tasarım seçeneklerine geçici bir çözüm olması gerekebilir.

Şema tabanlı biçim için, okuyucu ve yazıcı şeması arasında uyumluluk denetimleri yapan bir kodlama kitaplığı seçin. Apache Avro gibi bazı kodlama kitaplıkları, tüketicinin iletiyi seri durumdan çıkarmadan önce hem yazıcı hem de okuyucu şeması belirtmesini bekler. Bu denetim, tüketicinin şema sürümlerinin farkında olmasını sağlar.

Birlikte çalışabilirlik

Biçim seçiminiz belirli iş yüküne veya teknoloji ekosisteminize bağlı olabilir.

Örneğin:

• Azure Stream Analytics JSON, CSV ve Avro için yerel desteğe sahiptir. Stream Analytics kullanırken mümkünse bu biçimlerden birini seçmek mantıklıdır. Aksi takdirde, özel bir seri durumdan çıkarıcı sağlayabilirsiniz, ancak bu, çözümünüze biraz daha karmaşıklık ekler.

• JSON, HTTP REST API'leri için standart bir değişim biçimidir. Uygulamanız istemcilerden JSON yükleri alır ve bunları zaman uyumsuz işleme için bir ileti kuyruğuna yerleştirirse, farklı bir biçimde yeniden kodlamak yerine mesajlaşma için JSON kullanmak mantıklı olabilir.

Bunlar birlikte çalışabilirlik konusunda dikkat edilmesi gereken iki örnektir. Genel olarak, standart biçimler özel biçimlerden daha birlikte çalışabilir olacaktır. Metin tabanlı seçeneklerde JSON en çok birlikte çalışabilen seçeneklerden biridir.

Kodlama biçimleri için seçenekler

Bazı popüler kodlama biçimleri aşağıdadır. Bir biçim seçmeden önce dikkat edilmesi gerekenleri dikkate alın.

JSON

JSON açık bir standarttır (IETF RFC8259). Dizi/sözlük/değer modelini izleyen metin tabanlı bir biçimdir.

JSON, meta verileri etiketlemek için kullanılabilir ve yükü şema olmadan ayrıştırabilirsiniz. JSON, ileri ve geri uyumluluğun yardımcı olduğu isteğe bağlı alanları belirtme seçeneğini destekler.

En büyük avantajı, evrensel olarak kullanılabilir olmasıdır. Birçok mesajlaşma hizmeti için en çok birlikte çalışabilir ve varsayılan kodlama biçimidir.

Metin tabanlı bir biçim olarak, kablo üzerinde verimli değildir ve depolamanın önemli olduğu durumlarda ideal bir seçim değildir. Önbelleğe alınmış öğeleri HTTP aracılığıyla doğrudan bir istemciye döndürdüyseniz, JSON depolamak başka bir biçimden seri durumdan çıkarma ve ardından JSON'a seri hale getirme maliyetinden tasarruf edebilir.

Tek kayıtlı iletiler veya her iletinin farklı bir şemaya sahip olduğu bir ileti dizisi için JSON kullanın. Zaman serisi verileri gibi bir kayıt dizisi için JSON kullanmaktan kaçının.

MongoDB ile çalışmak üzere hizalanmış bir ikili kodlama olan ikili JSON (BSON) gibi başka JSON varyasyonları da vardır.

Virgülle Ayrılmış Değerler (CSV)

CSV, metin tabanlı bir tablosal biçimdir. Tablonun üst bilgisi alanları gösterir. bu, iletinin bir kayıt kümesi içerdiği tercih edilen bir seçimdir.

Dezavantajı standardizasyon eksikliğidir. Ayırıcıları, üst bilgileri ve boş alanları ifade etmenin birçok yolu vardır.

Protokol Arabellekleri (protobuf)

Protokol Arabellekleri (veya protobuf), anahtar/değer çiftlerinde şemaları tanımlamak için kesin olarak yazılan tanım dosyalarını kullanan bir serileştirme biçimidir. Bu tanım dosyaları daha sonra iletileri seri hale getirmek ve seri durumdan çıkarma için kullanılan dile özgü sınıflara derlenir.

İleti, daha hızlı aktarıma neden olan sıkıştırılmış bir ikili küçük yük içerir. Dezavantajı, yükün insan tarafından okunamaz olmasıdır. Ayrıca şema dış olduğundan, arşivlenmiş verileri almanız gereken durumlar için önerilmez.

Apache Avro

Apache Avro , protobuf'a benzer bir tanım dosyası kullanan ikili serileştirme biçimidir, ancak bir derleme adımı yoktur. Bunun yerine, serileştirilmiş veriler her zaman bir şema ön derlemesi içerir.

Ön bilgi, üst bilgiyi veya şema tanımlayıcısını barındırabilir. Daha küçük kodlama boyutu nedeniyle, akış verileri için Avro önerilir. Ayrıca, bir kayıt kümesine uygulanan bir üst bilgisi olduğundan, tablosal veriler için iyi bir seçimdir.

MessagePack

MessagePack, kablo üzerinden aktarım için kompakt şekilde tasarlanmış bir ikili serileştirme biçimidir. İleti şemaları veya ileti türü denetimi yoktur. Toplu depolama için bu biçim önerilmez.

CBOR

Kısa İkili Nesne Gösterimi (CBOR) (Belirtim), küçük kodlama boyutu sunan bir ikili biçimdir. CBOR'un MessagePack'e kıyasla avantajı, RFC7049 IETF ile uyumlu olmasıdır.

Sonraki adımlar

• Bulut uygulamaları için mesajlaşma tasarım desenlerini anlama.