Talep Denetimi düzeni

Büyük bir ileti yükünü bir dış veri deposunda depolayın ve mesajlaşma sistemi aracılığıyla yalnızca depolanan yüke bir başvuru gönderin. Alıcı uygulamalar, işlemeleri gerektiğinde büyük yükü almak için claim check olarak adlandırılan referans belirtecini sunar. Bu yaklaşım, iş yüklerinin büyük yükleri mesajlaşma sisteminde depolamadan aktarmasına olanak tanır.

Bağlam ve sorun

Geleneksel mesajlaşma sistemleri, yüksek hacimli küçük iletileri yönetmek için iyileştirilmiştir ve genellikle işleyebileceği ileti boyutunu kısıtlar. Büyük iletiler yalnızca boyut sınırlarını aşma riskiyle kalmaz, aynı zamanda mesajlaşma sistemi bunları depoladığında sistem performansını düşürebilir.

Aşağıdaki kısıtlamalar, ileti sistemi üzerinden satır içi yük iletimini yetersiz hale getirir:

  • Boyut sınırı nedeniyle reddedildi. Mesajlaşma sistemleri, yapılandırılan üst sınırı aşan iletileri reddeder.

  • Broker kaynak yükü. Aracı üzerinde büyük veri yüklerinin depolanması, aracının iletiyi yönlendirmesi ve teslim etmesi için gereken meta verilere kıyasla orantısız miktarda bellek ve disk alanı tüketir. Bu tüketim, sistemdeki diğer iletiler için gerekli kaynaklarla rekabet eder.

  • Aktarım hızı düşüşü. Daha büyük iletiler işlem başına serileştirme, aktarım ve seri durumdan çıkarma süresini artırır.

  • Maliyet yükseltmesi. Bazı mesajlaşma sistemleri ileti boyutuna, katmana veya kapasite birimine göre ücretlendirilir. Büyük yüklerin doğrudan iletilmesi, iş yüklerini daha yüksek maliyetli katmanlara veya kapasite tahsislerine itebilir.

Çözüm

Talep Denetimi düzeni, yük depolama alanını ileti tesliminden ayırır. Gönderen bir uygulama, yükün tamamını bir dış veri deposuna yazar ve mesajlaşma sistemi aracılığıyla bu yüke bir başvuru gönderir. Mesajlaşma sistemi yükü hiçbir zaman görmez veya depolamaz. Alıcı uygulamalar, yük verisini doğrudan veri deposundan almak için referansı kullanır. Başvuru, alıcı uygulamanın çözümlemesi gereken bir tanımlayıcıdır.

Talep Denetimi düzenini gösteren diyagram.

Desen şu sırayı izler:

  1. Gönderen uygulama yükü oluşturur.
  2. Gönderen uygulama yükü dış veri deposuna kaydeder.
  3. Kaydetme işlemi başarılı olduktan sonra, gönderen uygulama depolanan yüke bir başvuru oluşturur ve bunu bir talep denetimi iletisi olarak mesajlaşma sisteminde yayımlar.
  4. Alıcı uygulama iletiyi alır ve talep denetimi belirtecini okur.
  5. Alıcı uygulama, veri deposundan veri yükünü almak için belirteci kullanır.
  6. Alıcı uygulama veri yükünü işler.

Mesajlaşma sistemi yalnızca küçük talep denetimi iletisini işler; bu da ileti boyutu reddini ve büyük ileti yüklerini aktarmak ve korumak için kaynakları kullanma gereksinimini önler. Dış veri deposu, mesajlaşma sisteminden bağımsız olarak yüke erişim denetimleri ve yaşam döngüsü ilkeleri uygular.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:

  • Yük yaşam döngüsünün sahipliği. Hangi bileşenin yük silmeye sahip olduğunu ve bileşenin yükün gerekli olmadığını nasıl belirlediğini tanımlayın. Geçerli bir claim check’in silinmiş verilere işaret etmemesi için ileti süresinin dolması ile yük verisinin saklama süresini koordine edin.

  • Koşullu uygulama. Tüm iletilerin talep denetimleri mi yapacağına yoksa her ileti için talep denetimi kararı mı vereceğine karar verin. Koşulluysa, şemanın yükün satır içi mi yoksa dış mı olduğunu tanımladığından emin olun.

  • Belirteç ve depolama güvenliği. Talep denetiminin bir parçası olarak güvenlik belirteçleri eklemeyin. Yetkilendirmeyi üretici veya tüketici sistemleriyle veri deposu arasında bağımsız bir etkileşim olarak bırakın. Çözümünüz tüketicilere açıkça geçici erişim verilmesini gerektiriyorsa, bunun yerine Vale Anahtarı desenini kullanın.

  • Veri yükü ve belirteç tutarlılığı. Yük verisinin yazılması ve token’ın yayımlanması ayrı sistemlerde gerçekleşir ve tek bir atomik işlem kapsamında gerçekleşmez. Yük verisi yazıldıktan sonra ancak token yayımlanmadan önce meydana gelen bir hata, yük verisini sahipsiz bırakabilir. Veri yükü erişilebilir hâle gelmeden önce yayımlanan bir belirteç, tüketicilerin çözemeyecekleri referanslar almasına neden olabilir. Belirteci yalnızca yük yazma işlemi başarılı olduktan sonra yayımlayın. Yeniden denemeler aynı claim check’i birden fazla kez iletebildiğinden, yinelenenleri güvenle işlemek için Idempotent Consumer desenini kullanın.

  • Yük bütünlüğü. Tüketicilerin yük bütünlüğünü doğrulaması gerektiğinde, iletiye bir içerik karması veya dijital imza ekleyin. Yükü reddetme, alma işlemini yeniden deneme veya iletiyi araştırma için yönlendirme gibi uyuşmazlıklar için bir protokol tanımlayın.

  • Yükün kullanılabilirliği ve dayanıklılığı. Dış veri deposu, alan uygulamaların yük alması gereken süre boyunca kullanılabilir ve dayanıklı kalmalıdır. Depoda bir kesinti veya veri kaybı yaşanırsa, geçerli belirteçlere sahip tüketiciler yük verilerine erişemez ve ileti işleme süreçleri durur.

  • Alma atlama gecikmesi. Bu model, satır içi mesaj teslimine kıyasla ağ üzerinden ek gidiş gelişler gerektirir. İşlemenin başlayabilmesi için, alıcı uygulamaların yükü almak için dış veri depoyu çağırması gerekir.

  • Çerçeve tarafından sağlanan talep denetimi desteği. İleti veri yolu SDK'nızın sunduğu özellikleri kullanın. Örneğin, NServiceBus,yük depolama ve alma sürecini otomatikleştirebilen bir DataBus özelliğine sahiptir.

Bu desen ne zaman kullanılır?

Bu düzeni aşağıdaki durumlarda kullanın:

  • İleti yükleri, mesajlaşma sisteminin desteklediği maksimum ileti boyutunu düzenli olarak aşıyor . Veri yükünün harici bir veri deposuna aktarılması ve yalnızca hafif bir claim check belirtecinin iletilmesi, boyut sınırı nedeniyle reddedilmeyi önler.

  • Büyük iletiler, orantısız miktarda aracı hizmeti kaynağı tüketir. Büyük iletiler, serileştirme ve aktarım süresini artırarak veya mesajlaşma sistemini paylaşan tüm üreticiler ve tüketiciler için aktarım hızını düşürerek mesajlaşma sistemi performansını etkiler.

  • Yüklerde, mesajlaşma sistemi veya kuyruk izleme araçları gibi aracı bileşenler için görünmemesi gereken hassas bilgiler bulunur. Deseni yükün tamamına veya yalnızca hassas bölümlerine uygulayın. Hassas içeriği, mesajlaşma yolundan uzak tutmak için ayrılmış erişim denetimleriyle güvenli bir veri deposunda depolayın.

  • İletiler, yinelenen serileştirme ile karmaşık yönlendirmeye sahiptir. İletiler serileştirme, seri durumdan çıkarma, şifreleme veya şifre çözme gerçekleştiren birden çok yönlendirme bileşeninde geçiş yapar. Her atlamada tam yükün tekrar tekrar işlenmesini ortadan kaldırmak ve kümülatif gecikme süresini azaltmak için aracılar aracılığıyla yalnızca küçük bir belirteç iletin.

Bu düzen aşağıdaki durumlarda uygun olmayabilir:

  • Gecikme süresi duyarlılığı yük boyutuyla ilgili sorunlardan daha ağır basıyor. Üretici ve tüketici arasında mümkün olan en düşük uçtan uca gecikme süresini gerektiren iş yükleri, yük depolama ve alma için eklenen ağ atlamalarını tolere etmeyebilir. İletiler boyut veya performans sınırları aşılmadan satır içinde teslim edilebiliyorsa, doğrudan teslim daha basit ve hızlıdır.

  • Yük boyutunu destekleyen bir aktarım veya katman seçebilirsiniz. Veri yükleri, taşıma mekanizmasının desteklediği sınır içinde kalıyor ve kabul edilemez düzeyde veri aktarım yükü veya gecikme yaratmıyorsa, harici depolama bağımlılığını önlemek için bunları satır içinde gönderin. Örneğin, Azure Service Bus Premium katmanı 100 MB'a kadar Gelişmiş Message Queuing Protokolü (AMQP) iletilerini destekler. Büyük iletiler aktarım hızını azalttığı ve gecikme süresini artırdığı için iletileri olabildiğince küçük tutun.

  • İki sistem arasında koordinasyon mümkün değildir. Desen, iki bağımsız sistem arasında koordinasyon gerektirir. Talep denetimi değerinin, alıcı sistemin anlayabileceği şekilde yazılması ve biçiminin zaman içinde ayarlanması gerekebilir.

Alternatives

Bu yaklaşımları bu desenin alternatifleri olarak düşünün:

  • Satır içi yük boyutunu küçültün. Sıkıştırma, yinelenen metin veya ikili yükleri azaltabilir ve daha kompakt bir seri hale getirici ileti yükünü azaltabilir. Azaltılan yük taşıma sınırına rahatça sığdığında ve her üretici ve tüketici aynı sıkıştırma ve serileştirme biçimini kullanabildiğinde bu yaklaşımı seçin.

  • Veri yükünü doğal bir şekilde bölün ve toplayın. Tüketicilerin öbekleri bağımsız olarak işleyebildiği veya teslimden sonra yeniden birleştirebildiği durumlarda, büyük bir yükü daha küçük bir ileti dizisine bölün. Bu yaklaşım verileri mesajlaşma sisteminde tutar, ancak sıralama, bağıntı, yinelenen işleme ve yeniden birleştirme gereksinimleri ekler. Daha fazla bilgi için bkz. Kurumsal Tümleştirme Desenlerinden Bölücü ve Toplayıcı desenleri.

İş yükü tasarımı

Azure Well-Architected Framework yapılarında ele alınan hedefleri ve ilkeleri ele almak için bir iş yükünün tasarımında Talep Denetimi deseninin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin sütunların hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.

Temel Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün arızaya karşı dayanıklı olmasına ve hatadan sonra tamamen kurtarılmasını sağlamaya yardımcı olur. Mesajlaşma sistemleri dayanıklı teslim, yüksek kullanılabilirlik ve olağanüstü durum kurtarma sağlayabilir, ancak genellikle ayrılmış bir veri deposunun sürüm oluşturma, yedekleme, belirli bir noktaya geri yükleme veya bağımsız çoğaltma gibi yük düzeyinde veri koruma ve kurtarma özelliklerini sağlamaz. Yükü ayrı ayrı depolamak, bu özellikleri yük kurtarma gereksinimlerine göre seçmenize ve yapılandırmanıza olanak tanır.

- RE:03 Hata modu analizi
- RE:09 Olağanüstü durum kurtarma
Güvenlik tasarımı kararları, iş yükü verilerinin ve sistemlerinin gizliliğini, bütünlüğünü ve kullanılabilirliğini sağlamaya yardımcı olur. Talep Denetimi düzeni, iletilerden hassas verileri ayıklayabilir ve güvenli bir veri deposunda depolayabilir. Bu kurulum, yalnızca hassas verileri kullanmayı amaçlayan hizmetlerin erişebilmesi için daha sıkı erişim denetimleri sağlar. Desen ayrıca bu verileri kuyruk izleme için kullanılanlar gibi ilgisiz hizmetlerden gizler.

- SE:03 Veri sınıflandırması
- SE:04 Segmentlere Ayırma
Maliyet İyileştirme, iş yükünüzün yatırım getirisini sürdürmeye ve geliştirmeye odaklanır. Mesajlaşma sistemleri genellikle ileti boyutuna sınırlar uygular ve artan boyut sınırları genellikle premium bir özelliktir. İleti gövdelerinin boyutunu küçültmek daha ucuz bir mesajlaşma çözümü kullanmanıza olanak tanıyabilir. Yük depolama, ağ aktarımı ve temizleme işlemleri için ek maliyetleri dikkate alır.

- CO:07 Bileşen maliyetleri
- CO:09 Akış maliyetleri
Performans Verimliliği , ölçeklendirmeyi, veri aktarımını ve kod yürütmeyi iyileştirerek iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar. Talep Denetimi düzeni, büyük iletileri daha etkili bir şekilde yöneterek gönderme, alma ve mesajlaşma sistemi verimliliğini artırır. Mesajlaşma sistemine gönderilen iletilerin boyutunu küçültür ve uygulamaların büyük iletilere yalnızca gerektiğinde erişmesini sağlar.

- PE:05 Ölçeklendirme ve bölümleme
- PE:12 Sürekli performans iyileştirme

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Examples

Bu bölüm, Azure hizmetlerin Talep Denetimi düzenini nasıl uyguladığını gösteren GitHub Talep denetimi bulut deseni örneklerine bağlantı sağlar. Her örnek, dış veri deposu olarak Azure Blob Depolama kullanır ve bunu farklı bir Azure mesajlaşma sistemiyle eşleştirmektedir. Örnek 1 ile 3 arasında bir Azure Event Grid bildirimindeki blob URL'sini talep denetimi olarak kullanır. Örnek 4, gönderen uygulamanın yayımladığı özel bir talep denetimi kullanır.

1 ile 3 arasında örneklerde:

  1. Bir gönderen uygulama, büyük bir yükü Blob Depolama'a yükler.
  2. Yükleme, Event Grid sistem konusu üzerinden bir Microsoft.Storage.BlobCreated olayı tetikler.
  3. Event Grid, örneklerin talep denetimi olarak kullandığı doğrudan blob URL'sini içeren bildirimi yapılandırılan mesajlaşma sistemine yönlendirir.
  4. Azure İşlevleri işlev uygulaması veya komut satırı istemcisi olarak uygulanan bir alıcı uygulama, bildirimi alır, blob URL’sini ayıklar ve yük verisini işlemek üzere doğrudan Blob Depolama’dan indirir.

Üretim uygulamasında, olay aboneliğini tamamen kesinleştirilmiş bir blok blobunu belirten işlemlere göre filtreler ve alıcıyı gecikmeli, yinelenen ve sırası bozulmuş olayları işleyecek şekilde tasarlarsınız.

Örnek 4 farklı bir yaklaşım kullanır. Gönderen uygulama, Event Grid aracılığıyla bir Blob Depolama bildirimi yönlendirmek yerine yükü Blob Depolama yükledikten sonra talep denetimini oluşturur. Gönderen uygulama daha sonra Apache Kafka protokolunu kullanarak talep denetimini Azure Event Hubs Kafka uç noktasında yayımlar. Bu yaklaşım, Kafka uyumlu üreticileri kullanan veya özel belirteç biçimleri gerektiren ortamlara uygundur.

Aşağıdaki tabloda her örnek mesajlaşma sistemi, talep denetimi yayımcısı, alıcı uygulama ve depolama bağımlılıkları ile listelenmiştir. Örnek kodu GitHub görüntülemek için her bağlantıyı seçin.

Örnek kodu Mesajlaşma sistemi Claim check yayımcısı Uygulama alınıyor Depolama bağımlılıkları
Kod örneği 1 Azure Kuyruk Depolama (Azure Kuyruk Depolama) Event Grid Functions Blob Depolama (Blob Depolama)
Kod örneği 2 Event Hubs (AMQP üzerinden Azure SDK) Event Grid Yürütülebilir komut satırı istemcisi Yükler için Blob Depolama ve ayrı bir Blob Depolama denetim noktası deposu
Kod örneği 3 Service Bus Event Grid Functions Blob Depolama (Blob Depolama)
Kod örneği 4 Event Hubs (Apache Kafka protokolü) Yürütülebilir komut satırı istemcisi Functions Blob Depolama (Blob Depolama)

Sonraki Adımlar

  • Last updated on