Claim-Check deseninin
Büyük bir iletiyi bir talep denetimine ve yüküne ayırın. Talep denetimini mesajlaşma platformuna gönderin ve yükü bir dış hizmete depolayın. Bu model, büyük iletilerin işlenmesine, böylece ileti veri yolu ve istemcinin yavaşlanması ya da yavaşlanması için koruma sağlar. Bu model, depolama genellikle mesajlaşma platformu tarafından kullanılan kaynak birimlerinden daha ucuz olduğundan maliyetleri azaltmaya da yardımcı olur.
bu düzen Reference-Based mesajlaşma olarak da bilinir ve başlangıçta, gregor hohpe ve bobwoolf tarafından kitap Kurumsal Tümleştirme desenlerindeaçıklanmıştı .
Bağlam ve sorun
Bir noktada mesajlaşma tabanlı mimarinin büyük iletilerini gönderebilmesi, alabilmesi ve işleyebilmeleri gerekir. Bu tür iletilerde görüntüler (örneğin, MRI taramaları), ses dosyaları (örneğin, çağrı merkezi çağrıları), metin belgeleri veya rastgele boyuttaki herhangi bir tür ikili veri gibi herhangi bir şey olabilir.
Daha fazla kaynak ve bant genişliği kullanılması gerektiğinden, bu tür büyük iletileri doğrudan Message Bus 'a göndermek önerilmez. Mesajlaşma platformları genellikle çok büyük miktarlarda küçük iletileri işlemek üzere ince ayar yaptığından, büyük iletiler tüm çözümü de yavaşlatabilir. Ayrıca, çoğu mesajlaşma platformunda ileti boyutu sınırlandırmalar vardır; bu nedenle büyük iletiler için bu sınırlara geçici bir çözüm yapmanız gerekebilir.
Çözüm
Tüm ileti yükünü bir veritabanı gibi bir dış hizmete depolayın. Depolanan yükün başvurusunu alın ve yalnızca bu başvuruyu ileti veri yoluna gönderin. Başvuru, bir lugaj parçasını almak için kullanılan bir talep denetimi gibi davranır, bu nedenle düzenin adı. Belirli bir iletinin işlenmesiyle ilgilenen istemciler, gerekirse yükü almak için edinilen başvuruyu kullanabilir.
Sorunlar ve dikkat edilmesi gerekenler
Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:
İletileri arşivlemeniz gerekmiyorsa ileti verilerini kullandıktan sonra silmeyi göz önünde bulundurun. BLOB depolama görece bir şekilde oldukça büyük olsa da, özellikle çok fazla veri olması durumunda uzun çalıştırmada bazı para maliyetlerini ücretlidir. İletiyi silme işlemi, iletiyi alan ve işleyen uygulama tarafından zaman uyumlu olarak veya ayrı bir adanmış işlem tarafından zaman uyumsuz olarak yapılabilir. Zaman uyumsuz yaklaşım, alıcı uygulamanın aktarım hızı ve ileti işleme performansı üzerinde etkilenmeden eski verileri kaldırır.
İletiyi depolamak ve almak bazı ek yüke ve gecikmeye neden olur. Bu stili yalnızca ileti boyutu ileti veri yolu veri sınırını aştığında kullanmak için gönderme uygulamasında mantığı uygulamak isteyebilirsiniz. Daha küçük iletiler için bu model atlanır. Bu yaklaşım, koşullu talep denetimi düzenine neden olur.
Bu düzenin kullanılacağı durumlar
Bu model, bir ileti seçilen ileti veri yolu teknolojisinin desteklenen ileti sınırına uyamadığında kullanılmalıdır. Örneğin, Event Hubs Şu anda 256 KB 'lik bir sınıra sahiptir (temel katman) Event Grid yalnızca 64 KB 'lik iletileri destekler.
Bu model, yük yalnızca onu görme yetkisi olan hizmetlerden erişilmesi gerekiyorsa de kullanılabilir. Yükün bir dış kaynağa boşaltılabilmesi için, daha sıkı kimlik doğrulama ve yetkilendirme kuralları yerinde yer alabilir.
Örnekler
Azure 'da bu model çeşitli yollarla ve farklı teknolojilerle uygulanabilir, ancak iki ana kategori vardır. Her iki durumda da alıcı, talep denetimini okuma ve yükü almak için kullanma sorumluluğunu içerir.
Otomatik talep-üretimi denetle. Bu yaklaşım, talep denetimini otomatik olarak oluşturmak ve ileti veri yoluna göndermek için Azure Event Grid kullanır.
El ile talep-üretimi denetleyin. Bu yaklaşımda gönderici, yükü yönetmekten sorumludur. Gönderici ilgili hizmeti kullanarak yükü depolar, talep denetimini alır veya üretir ve talep denetimini ileti veri yoluna gönderir.
Event Grid bir olay yönlendirme hizmetidir ve en fazla 24 saate kadar yapılandırılabilir bir süre içinde olay sunmaya çalışır. Bundan sonra olaylar atılır veya atılacak. olay yüklerini arşivlemeniz veya olay akışını yeniden oynatmeniz gerekiyorsa, Event Hubs veya kuyruk Depolama Event Grid bir abonelik ekleyebilirsiniz; burada iletiler daha uzun süreler için korunabilir ve iletileri arşivleme desteklenir. İleti teslimi ve yeniden deneme Event Grid hassas ayarlama ve atılacak mektup yapılandırması hakkında daha fazla bilgi için bkz. atılacak mektup ve yeniden deneme ilkeleri.
otomatik talep-Blob Depolama ve Event Grid ile üretimi denetle
bu yaklaşımda gönderici, ileti yükünü belirlenmiş bir Azure Blob Depolama kapsayıcısına bırakır. Event Grid otomatik olarak bir etiket/başvuru oluşturur ve Azure Depolama kuyrukları gibi desteklenen bir ileti veri yoluna gönderir. alıcı kuyruğu yoklayabilirler, iletiyi alabilir ve ardından doğrudan Blob Depolama yük indirmek için depolanan başvuru verilerini kullanabilir.
Aynı Event Grid ileti, Azure işlevleritarafından doğrudan bir ileti veri yolu ile çalışmaya gerek kalmadan tüketilebilir. Bu yaklaşım hem Event Grid hem de Işlevlerinin sunucusuz doğası ile tam olarak yararlanır.
Bu yaklaşım için örnek kodu buradabulabilirsiniz.
Event Hubs Event Grid
Önceki örneğe benzer şekilde, bir Azure Blob kapsayıcısına yük yazıldığında Event Grid otomatik olarak bir ileti üretir. Ancak, bu örnekte ileti veri yolu Event Hubs kullanılarak uygulanır. İstemci, Olay Hub 'ına yazıldığı gibi ileti akışını almak için kendisini kaydedebilir. Olay Hub 'ı iletileri arşivlemek için de yapılandırılabilir, bu dosyaları Apache Spark, Apache detaya gitme veya kullanılabilir avro kitaplıklarının herhangi biri gibi araçlar kullanılarak sorgulanabilecek bir avro dosyası olarak kullanılabilir hale getirir.
Bu yaklaşım için örnek kodu buradabulabilirsiniz.
Service Bus ile talep denetimi oluşturma
bu çözüm, talep denetimi iş akışını kolayca uygulamak için belirli bir Service Bus eklentisi olan servicebus. attachmentpluginözelliğinden yararlanır. eklenti, ileti gönderildiğinde bir ileti gövdesini Azure Blob 'da depolanan bir eklentiye dönüştürür Depolama.
using ServiceBus.AttachmentPlugin;
...
// Getting connection information
var serviceBusConnectionString = Environment.GetEnvironmentVariable("SERVICE_BUS_CONNECTION_STRING");
var queueName = Environment.GetEnvironmentVariable("QUEUE_NAME");
var storageConnectionString = Environment.GetEnvironmentVariable("STORAGE_CONNECTION_STRING");
// Creating config for sending message
var config = new AzureStorageAttachmentConfiguration(storageConnectionString);
// Creating and registering the sender using Service Bus Connection String and Queue Name
var sender = new MessageSender(serviceBusConnectionString, queueName);
sender.RegisterAzureStorageAttachmentPlugin(config);
// Create payload
var payload = new { data = "random data string for testing" };
var serialized = JsonConvert.SerializeObject(payload);
var payloadAsBytes = Encoding.UTF8.GetBytes(serialized);
var message = new Message(payloadAsBytes);
// Send the message
await sender.SendAsync(message);
Service Bus ileti, bir istemcinin abone olabileceği bir bildirim kuyruğu işlevi görür. tüketici iletiyi aldığında, eklenti ileti verilerini Blob Depolama doğrudan okumasını mümkün hale getirir. Daha sonra iletiyi nasıl işlemek istediğinizi seçebilirsiniz. Bu yaklaşımın bir avantajı, gönderen ve alıcıdan talep denetimi iş akışını soyutmıdır.
Bu yaklaşım için örnek kodu buradabulabilirsiniz.
El ile talep-Kafka ile üretimi denetle
bu örnekte, bir Kafka istemcisi yükü Azure Blob Depolama yazar. Ardından, Kafka özellikli Event Hubskullanarak bir bildirim iletisi gönderir. tüketici iletiyi alır ve Blob Depolama yük yüküne erişebilir. Bu örnekte, Azure 'da talep denetimi modelini uygulamak için farklı bir mesajlaşma protokolünün nasıl kullanılabileceği gösterilmektedir. Örneğin, var olan Kafka istemcilerini desteketmeniz gerekebilir.
Bu yaklaşım için örnek kodu buradabulabilirsiniz.
Sonraki adımlar
- Yukarıda açıklanan örnekler GitHubkullanılabilir.
- Kurumsal Tümleştirme Patterns sitesi bu düzenin bir açıklamasına sahiptir.
- diğer bir örnek için bkz. talep denetim modelini kullanarak büyük Service Bus iletilerle ilgilenme (blog gönderisi).