Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Tüketicilerin aynı ileti kanalı üzerinden alınan iletileri eşzamanlı olarak işlemesine olanak tanıyın. Birden çok eşzamanlı tüketici ile sistem, aktarım hızını iyileştirmek, ölçeklenebilirliği ve kullanılabilirliği geliştirmek ve iş yükünü dengelemek için birden çok iletiyi aynı anda işleyebilir.
Bağlam ve sorun
Bulut uygulaması genellikle çok sayıda isteği işler. Uygulama, her isteği zaman uyumlu olarak işlemek yerine bir mesajlaşma sistemi aracılığıyla istekleri zaman uyumsuz olarak işleyen bir tüketici hizmetine geçirebilir. Bu strateji, istek işlemenin uygulama iş mantığını engellemesini önlemeye yardımcı olur.
İstek sayısı zaman içinde önemli ölçüde farklılık gösterebilir. Birden çok kiracıdan gelen kullanıcı etkinliğinde veya toplu isteklerde ani bir artış öngörülemeyen bir iş yükü oluşturabilir. Yoğun saatlerde bir sistemin saniyede yüzlerce isteği işlemesi gerekebilir. Diğer durumlarda, sayı küçük olabilir. Ayrıca, bu istekleri işlemek için gereken çalışma büyük ölçüde farklılık gösterebilir. Tek bir tüketici hizmeti örneği kullanıyorsanız istekler bu örneği zorlayabilir. Ya da uygulama iletilerinin bir akını mesajlaşma sistemini aşırı yükleyebilir.
Bu dalgalı iş yükünü işlemek için sistem birden çok tüketici hizmeti örneği çalıştırabilir. Ancak, her iletinin yalnızca bir tüketiciye teslim edilmesini sağlamak için sistemin bu tüketicileri koordine etmesi gerekir. Sistemin ayrıca bir örneğin performans sorununa dönüşmesini önlemek için iş yükünü tüketiciler arasında dengelemesi gerekir.
Çözüm
Uygulama ve tüketici hizmeti örnekleri arasındaki iletişim kanalını uygulamak için bir ileti kuyruğu kullanın. Uygulama istekleri kuyruğa ileti olarak gönderir ve tüketici hizmeti örnekleri kuyruktan iletileri alır ve işler. Bu yaklaşım, aynı tüketici hizmeti örnekleri havuzunun uygulamanın herhangi bir örneğinden gelen iletileri işlemesine olanak tanır. Aşağıdaki diyagram, bir ileti kuyruğunun işleri hizmet örneklerine nasıl dağıttığını göstermektedir.
Uyarı
Birden çok tüketici bu iletileri alır, ancak Rakip Tüketiciler düzeni Publisher-Subscriber deseninden farklıdır. Rakip Tüketiciler düzeninde, bir tüketici her iletiyi işlenmek üzere alır. Publisher-Subscriber düzeninde tüm tüketiciler her iletiyi alır.
Bu çözümün şöyle avantajları vardır:
Uygulama örneklerinden gelen istek hacmindeki geniş varyasyonları işleyebilen yük düzeyinde bir sistem sağlar. Kuyruk, uygulama örnekleriyle tüketici hizmeti örnekleri arasında bir arabellek işlevi görür. Bu arabellek, hem uygulama hem de hizmet örneklerinin kullanılabilirlik ve yanıt verme süresi üzerindeki etkisini en aza indirir. Daha fazla bilgi için bkz . Kuyruk Tabanlı Yük Dengeleme düzeni. Uzun süre çalışan işlemler gerektiren bir ileti, diğer tüketici hizmeti örneklerinin diğer iletileri eşzamanlı olarak işlemesini engellemez.
Güvenilirliği artırır. Bir üretici bu deseni kullanmak yerine doğrudan bir tüketiciyle iletişim kurarsa ve tüketiciyi izlemezse, iletileri kaybetme veya tüketici başarısız olduğunda iletileri işlememe olasılığı yüksektir. Bu düzende sistem belirli bir hizmet örneğine ileti göndermez. Başarısız bir hizmet örneği bir üreticiyi engellemez ve çalışan herhangi bir hizmet örneği iletileri işleyebilir.
Tüketiciler arasında veya üretici ile tüketici örnekleri arasında karmaşık koordinasyon gerektirmez. Mesaj kuyruğu, her bir mesajın en az bir kere teslim edilmesini sağlar.
Ölçeklendirilir. Otomatik ölçeklendirme uyguladığınızda, ileti hacmi dalgalandığında sistem tüketici hizmeti örneklerinin sayısını dinamik olarak artırabilir veya azaltabilir.
Mesaj kuyruğu işlemsel okuma işlemleri sağlıyorsa dayanıklılığı artırabilir. Bir tüketici hizmeti örneği bir iletiyi bir işlem işleminin parçası olarak okur ve işlerse ve başarısız olursa, bu düzen iletinin başka bir tüketici hizmeti örneğinin işleyebilmesi için kuyruğa döndürülmesini sağlayabilir. Sürekli ileti hatası riskini azaltmak için ölü harf kuyruklarını kullanmanızı öneririz.
Sorunlar ve dikkat edilmesi gerekenler
Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:
İleti sıralama: Tüketici hizmeti örneklerinin iletileri alma sırası garanti değildir ve iletilerin oluşturulduğu sırayı mutlaka göstermez. Sistemi , iletileri aynı anda işleyebilecek şekilde tasarlayın. Bu tasarım, işlem sırası bağımlılıklarını ortadan kaldırmaya yardımcı olur.
Azure Service Bus, ileti oturumlarını kullanarak iletilerin ve diğer desenlerin ilk sırada sıralanması garantisini uygulayabilir.
Hizmet dayanıklılığı gereksinimleri: Sistem başarısız hizmet örneklerini algılar ve yeniden başlatırsa, tek bir iletiyi birden çok kez alıp işlediğinde etkileri en aza indirmek için bu hizmet örneklerinin aynı anda gerçekleştirdiği işlemleri uygulaması gerekebilir.
Zehirli ileti algılama: Hatalı biçimlendirilmiş bir ileti veya kullanılabilir olmayan kaynaklara erişim gerektiren bir görev, hizmet örneğinin başarısız olmasına neden olabilir. Sistem, bu iletilerin süresiz olarak kuyruğa dönmesini engellemeli ve bunun yerine gerekirse analiz için ayrıntılarını başka bir yerde yakalayıp depolamalıdır. Service Bus, teslim sayısı yapılandırılan eşiği aştıktan sonra otomatik olarak bir
MaxDeliveryCountileti gönderebilir.Sonuç işleme: İletiyi işleyen hizmet örneği, iletiyi oluşturan uygulama mantığından tamamen ayrılmıştır, bu nedenle doğrudan iletişim kuramayabilirler. Hizmet örneği uygulama mantığına geri dönmesi gereken sonuçlar oluşturuyorsa, bu bilgileri her iki bileşenin de erişebileceği bir konumda depolayın. Uygulama mantığının eksik verileri almasını önlemek için, sistemin işlem tamamlandığında bunu belirtmesi gerekir. Çalışan işlemi, sonuçları ayrılmış bir ileti yanıt kuyruğu aracılığıyla uygulama mantığına geri geçirebilir. Uygulama mantığının bu sonuçları özgün mesajla ilişkilendirebilmesi gerekir.
Mesajlaşma sistemi ölçeklendirmesi: Büyük ölçekli bir çözümde, yüksek ileti hacmi tek bir ileti kuyruğunu bunaltabilir ve bunu bir sistem performans sorununa dönüştürebilir. Bu durumda, belirli üreticilerden belirli bir kuyruğa ileti göndermek için mesajlaşma sistemini bölümlendirmeyi veya iletileri birden çok ileti kuyruğuna dağıtmak için yük dengelemeyi göz önünde bulundurun.
Mesajlaşma sistemi güvenilirliği: Uygulama bunları sıraladıktan sonra iletilerin kaybolmayabileceklerini garanti etmek için güvenilir bir mesajlaşma sistemi kullanın. Bu özellik, tüm iletilerin en az bir kez teslim edilmesini sağlamak için gereklidir.
Bu desen ne zaman kullanılır?
Bu düzeni aşağıdaki durumlarda kullanın:
Uygulama iş yükü zaman uyumsuz olarak çalışabilen görevlere ayrılır.
Görevler birbirinden bağımsızdır ve paralel olarak çalıştırılabilir.
İş hacmi son derece değişkendir ve ölçeklenebilir bir çözüm gerektirir.
Çözüm yüksek kullanılabilirlik sağlamalı ve görev işleme başarısız olduğunda dayanıklı kalmalıdır.
Bu düzen aşağıdaki durumlarda uygun olmayabilir:
Uygulama iş yükünü kolayca ayrı görevlere ayıramazsınız veya görevler arasında yüksek düzeyde bağımlılık vardır.
Görevlerin zaman uyumlu bir şekilde çalışması ve uygulama mantığının devam etmeden önce her görevin tamamlanmasını beklemesi gerekir.
Görevler belirli bir sırada çalıştırılmalıdır.
Uyarı
Bazı mesajlaşma sistemleri, bir üreticinin iletileri birlikte gruplandırmasını ve aynı tüketicinin gruptaki tüm iletileri işlemesini sağlayan oturumları destekler. bu mekanizmayı, ileti sıralamasını zorunlu kılmak ve iletileri bir üreticiden tek bir tüketiciye sırayla teslim etmek için desteklendiğinde öncelikli iletilerle kullanabilirsiniz.
İş 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 Rakip Tüketiciler deseninin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin her bir sütunun hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.
| Ana Direk | Bu desen sütun hedeflerini nasıl destekler? |
|---|---|
| Güvenilirlik tasarımı kararları, iş yükünüzün hatalı çalışmaya dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma geldiğinden emin olmasına yardımcı olur. | Bu düzen, tüketicileri çoğaltma olarak değerlendirerek kuyruk işlemede yedeklilik oluşturur, bu nedenle örnek hatası diğer tüketicilerin kuyruk iletilerini işlemesini engellemez. - RE:05 Yedeklilik - Arka plan işleri |
| Maliyet İyileştirme, iş yükünüzün yatırım getirisinisürdürmeye ve geliştirmeye odaklanır. | Bu düzen maliyetleri iyileştirmeye yardımcı olabilir çünkü kuyruk derinliğine göre ölçeklendirilir ve kuyruk boş olduğunda ölçeği sıfıra düşürebilir. Ayrıca, en fazla eşzamanlı tüketici örneği sayısını sınırlayabileceğiniz için maliyetleri iyileştirebilir. - CO:05 Hız iyileştirme - CO:07 Bileşen maliyetleri |
| Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar. | Bu düzen kullanımı artırmak için yükü tüketici düğümleri arasında dağıtır ve kuyruk derinliğine göre dinamik ölçeklendirme fazla sağlamayı en aza indirir. - PE:05 Ölçeklendirme ve bölümleme - PE:07 Kod ve altyapı |
Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.
Example
Azure, birlikte doğrudan bu bulut tasarım deseni uygulayan Service Bus kuyrukları ve Azure İşlevleri kuyruğu tetikleyicileri sağlar. İşlevler, tetikleyiciler ve bağlamalar aracılığıyla Service Bus ile tümleşir. Bu tümleştirme, yayımcılardan gelen kuyruk iletilerini kullanan işlevler oluşturmanıza olanak tanır. Yayınlanan uygulamalar bir kuyruğa ileti gönderir ve İşlevler olarak uygulanan tüketiciler bu iletileri alabilir ve işleyebilir.
Dayanıklılık için Service Bus kuyruğu, tüketicinin kuyruktan bir ileti aldığında PeekLock modunu kullanmasına izin verir. Bu mod iletiyi tutar ancak diğer tüketicilerden gizler. İşlevler çalışma zamanı PeekLock modunda bir ileti alır. İşlev başarıyla tamamlanırsa, çalışma zamanı Complete'yi ileti üzerinde çağırır. İşlev başarısız olursa, Abandon çağırılabilir ve çalışma zamanı, başka bir tüketicinin iletiyi alabilmesi için mesajı yeniden görünür hale getirebilir. İşlev PeekLock zaman aşımından daha uzun çalışırsa, işlev çalıştığı sürece çalışma zamanı kilidi otomatik olarak yeniler.
İşlevler, kuyruk derinliğine ve trafiğe göre tüketici örneklerinin sayısını otomatik olarak ölçeklendirir. Bu ölçeklendirme, çözümün iş artışlarını işlemesine olanak tanırken düşük hacimli dönemlerde maliyeti en aza indirir. İşlevler birden çok örnek oluşturursa, iletileri bağımsız olarak çekerek ve işleyerek rekabet eder. Daha fazla bilgi için bkz. Service Bus kuyrukları, konuları ve abonelikler ve İşlevler için Service Bus tetikleyicisi.
Service Bus kuyruğuna ileti göndermek üzere .NET için Service Bus istemci kitaplığını kullanma hakkında daha fazla bilgi için yayımlanan örneklere bakın.
Sonraki Adımlar
Azure'da mesajlaşma hizmeti seçme: Service Bus, Azure Depolama kuyrukları, Azure Event Hubs ve Azure Event Grid gibi farklı Azure mesajlaşma hizmetlerinin zaman uyumsuz iletişim düzenlerini nasıl desteklediğini ve senaryonuz için doğru hizmet ve mesajlaşma modelini seçmeyi öğrenin.
Otomatik ölçeklendirme en iyi yöntemleri: En yüksek yükü işleyebilmeniz ve düşük etkinlik dönemlerinde maliyeti denetleyebilmeniz için kuyruk uzunluğu veya ileti aktarım hızı gibi iş yüküne göre tüketici örneklerinin ölçeğini genişleten çözümler tasarlamayı öğrenin.
İlgili kaynaklar
İşlem Kaynağı Birleştirme düzeni: Maliyetleri ve yönetim ek yükünü azaltmak için bir tüketici hizmetinin birden çok örneğini tek bir işlemde birleştirebilirsiniz. İşlem Kaynağı Birleştirme düzeni, bu yaklaşımın avantajlarını ve ödünlerini açıklar.
Kuyruk tabanlı Yük Dengeleme düzeni: İleti kuyruğu sisteme dayanıklılık ekleyebilir. Dayanıklılık, hizmet örneklerinin uygulama örneklerinden gelen çok çeşitli istekleri işlemesine olanak tanır. İleti kuyruğu, yükü düzeyleyen bir arabellek olarak çalışır. Kuyruk Tabanlı Yük Dengeleme düzeninde bu senaryo daha ayrıntılı olarak açıklanmıştır.