Depolama kuyrukları ve Service Bus kuyrukları - karşılaştırmalı ve karşıt
Bu makalede, Microsoft Azure tarafından sunulan iki kuyruk türü arasındaki farklar ve benzerlikler analiz edilir: Depolama kuyrukları ve Service Bus kuyrukları. Bu bilgileri kullanarak, hangi çözümün ihtiyaçlarınızı en iyi şekilde karşıladığı konusunda daha bilinçli bir karar vekleyebilirsiniz.
Giriş
Azure desteği iki tür kuyruk mekanizması vardır: Depolama kuyrukları ve Service Bus kuyrukları.
Depolama kuyrukları Azure Depolama altyapısının bir parçasıdır. Çok sayıda iletiyi depolamanıza olanak sağlar. HTTP veya HTTPS kullanarak kimliği doğrulanmış çağrılar aracılığıyla dünyanın herhangi bir yerinden iletilere erişebilirsiniz. Kuyruk iletisinin boyutu en fazla 64 KB olabilir. Kuyruk, depolama hesabının toplam kapasite sınırına kadar milyonlarca ileti içerebilir. Kuyruklar genellikle zaman uyumsuz olarak işlenmek üzere bir iş kapsamı oluşturmak için kullanılır. Daha fazla bilgi için bkz . Azure Depolama kuyrukları nedir?
Service Bus kuyrukları , kuyruğa alma, yayımlama/abone olma ve daha gelişmiş tümleştirme desenlerini destekleyen daha geniş bir Azure mesajlaşma altyapısının parçasıdır. Birden çok iletişim protokolüne, veri sözleşmelerine, güven etki alanlarına veya ağ ortamlarına yayabilecek uygulamaları veya uygulama bileşenlerini tümleştirmek için tasarlanmıştır. Service Bus kuyrukları/konuları/abonelikleri hakkında daha fazla bilgi için bkz . Service Bus kuyrukları, konuları ve abonelikleri.
Teknoloji seçimiyle ilgili dikkat edilmesi gerekenler
Depolama kuyrukları ve Service Bus kuyrukları biraz farklı bir özellik kümesine sahiptir. Kendi çözümünüzün gereksinimlerine bağlı olarak birini veya her ikisini de seçebilirsiniz.
Belirli bir çözümün amacına hangi kuyruğa alma teknolojisinin uygun olduğunu belirlerken, çözüm mimarları ve geliştiriciler bu önerileri dikkate almalıdır.
Depolama kuyruklarını kullanmayı göz önünde bulundurun
Çözüm mimarı/geliştirici olarak aşağıdaki durumlarda Depolama kuyruklarını kullanmayı düşünmelisiniz:
- Uygulamanızın kuyrukta 80 gigabayttan fazla ileti depolaması gerekir.
- Uygulamanız kuyruktaki bir iletiyi işlemek için ilerleme durumunu izlemek istiyor. bir iletiyi işleyen çalışan kilitleniyorsa yararlıdır. Daha sonra başka bir çalışan, önceki çalışanın bıraktığı yerden devam etmek için bu bilgileri kullanabilir.
- Kuyruklarınızda yürütülen tüm işlemlerin sunucu tarafı günlüklerine ihtiyacınız vardır.
Service Bus kuyruklarını kullanmayı göz önünde bulundurun
Çözüm mimarı/geliştirici olarak aşağıdaki durumlarda Service Bus kuyruklarını kullanmayı düşünmelisiniz:
- Çözümünüzün kuyruğu yoklamadan ileti alması gerekir. Service Bus ile, Service Bus'ın desteklediği TCP tabanlı protokolleri kullanarak uzun yoklama alma işlemi kullanarak bunu başarabilirsiniz.
- Çözümünüz için kuyruğun garantili ilk çıkar (FIFO) sıralı teslim sağlaması gerekir.
- Çözümünüz otomatik yinelenen algılamayı desteklemeli.
- Uygulamanızın uzun süre çalışan paralel akışlar olarak iletileri işlemesini istiyorsunuz (iletiler iletideki oturum kimliği özelliği kullanılarak bir akışla ilişkilendirilir). Bu modelde, tüketen uygulamadaki her düğüm, iletiler yerine akışlar için rekabet eder. Tüketen bir düğüme akış verildiğinde, düğüm işlemleri kullanarak uygulama akışı durumunu inceleyebilir.
- Çözümünüz bir kuyruktan birden çok ileti gönderirken veya alırken işlemsel davranış ve bölünmezlik gerektirir.
- Uygulamanız, 64 KB'ı geçebilecek iletileri işler ancak seçilen hizmet katmanına bağlı olarak 256 KB veya 1 MB sınırına yaklaşamaz (Service Bus kuyrukları 100 MB'a kadar olan iletileri işleyebilir).
- Kuyruklara rol tabanlı erişim modeli ve gönderenler ve alıcılar için farklı haklar/izinler sağlama gereksinimiyle ilgilenirsiniz. Daha fazla bilgi için aşağıdaki makalelere bakın:
- Kuyruk boyutunuz 80 GB'tan büyük olmayacaktır.
- AMQP 1.0 standartlarına dayalı mesajlaşma protokollerini kullanmak istiyorsunuz. AMQP hakkında daha fazla bilgi için bkz . Service Bus AMQP'ye Genel Bakış.
- Kuyruk tabanlı noktadan noktaya iletişimden yayımla-abone ol mesajlaşma düzenine nihai geçiş olmasını öngörürsunuz. Bu düzen ek alıcıların (aboneler) tümleştirilmesini sağlar. Her alıcı, kuyruğa gönderilen iletilerin bazılarının veya tümünün bağımsız kopyalarını alır.
- Mesajlaşma çözümünüzün ek altyapı bileşenlerini oluşturmanıza gerek kalmadan "En Çok Bir Kez" ve "En Az Bir Kez" teslim garantilerini desteklemesi gerekir.
- Çözümünüzün toplu iletileri yayımlaması ve kullanması gerekir.
Depolama kuyruklarını ve Service Bus kuyruklarını karşılaştırma
Aşağıdaki bölümlerde yer alan tablolar kuyruk özelliklerinin mantıksal gruplandırmalarını sağlar. Hem Azure Depolama kuyruklarında hem de Service Bus kuyruklarında kullanılabilen özellikleri bir bakışta karşılaştırmanıza olanak sağlar.
Temel özellikler
Bu bölüm, Depolama kuyrukları ve Service Bus kuyrukları tarafından sağlanan temel kuyruğa alma özelliklerinden bazılarını karşılaştırır.
| Karşılaştırma Ölçütleri | Depolama kuyrukları | Service Bus kuyrukları |
|---|---|---|
| Sipariş garantisi | Hayır Daha fazla bilgi için Ek Bilgiler bölümündeki ilk nota bakın. |
Evet - İlk Çıkan İlk Çıkar (FIFO) (ileti oturumlarını kullanarak) |
| Teslimat garantisi | En Az Bir Kez | En Az Bir Kez (PeekLock alma modunu kullanarak). Varsayılandır) En Çok Bir Kez (ReceiveAndDelete alma modunu kullanarak) Çeşitli Alma modları hakkında daha fazla bilgi edinin |
| Atomik işlem desteği | Hayır | Evet |
| Alma davranışı | Engelleyici değil (yeni ileti bulunmazsa hemen tamamlanır) |
Zaman aşımıyla veya zaman aşımı olmadan engelleme (uzun yoklama veya "Kuyrukluyot tekniği" sunar) Engelleyici değil (yalnızca .NET yönetilen API kullanarak) |
| Gönderme stili API | Hayır | Evet .NET, Java, JavaScript ve Go SDK'larımız gönderme stili API sağlar. |
| Alma modu | Göz Atma ve Kiralama | Göz Atma ve Kilitleme Alma ve Silme |
| Özel erişim modu | Kira tabanlı | Kilit tabanlı |
| Kiralama/Kilitleme süresi | 30 saniye (varsayılan) 7 gün (en fazla) (UpdateMessage API'sini kullanarak bir ileti kirasını yenileyebilir veya serbest bırakabilirsiniz.) |
30 saniye (varsayılan) İleti kilidini her seferinde el ile aynı kilit süresiyle yenileyebilir veya istemcinin sizin için kilit yenilemeyi yönettiği otomatik kilit yenileme özelliğini kullanabilirsiniz. |
| Kira/Kilit duyarlığı | İleti düzeyi Her iletinin farklı bir zaman aşımı değeri olabilir. Daha sonra UpdateMessage API'sini kullanarak iletiyi işlerken gerektiğinde güncelleştirebilirsiniz. |
Kuyruk düzeyi (Her kuyruğun tüm iletilerine bir kilit duyarlığı uygulanır, ancak kilit önceki satırda açıklandığı gibi yenilenebilir) |
| Toplu alma | Yes (en fazla 32 ileti olmak üzere iletileri alırken ileti sayısını açıkça belirtme) |
Yes (bir ön getirme özelliğini örtük olarak etkinleştirme veya işlemleri kullanarak açıkça etkinleştirme) |
| Toplu gönderme | Hayır | Evet (işlemleri veya istemci tarafı toplu işlemini kullanarak) |
Ek bilgi
- Depolama kuyruklarındaki iletiler genellikle ilk önce çıkarılır, ancak bazen sıra dışı olabilir. Örneğin, bir ileti işlenirken istemci uygulaması kilitlendiğinden iletinin görünürlük zaman aşımı süresi dolduğunda. Görünürlük zaman aşımı süresi dolduğunda, başka bir çalışanın kuyruğa alma işlemi için ileti kuyrukta yeniden görünür hale gelir. Bu noktada, yeni görünen ileti yeniden sıralanacak kuyruğa yerleştirilebilir.
- Service Bus kuyruklarındaki garantili FIFO deseni, mesajlaşma oturumlarının kullanılmasını gerektirir. Uygulama, Göz Atma ve Kilitleme modunda alınan bir iletiyi işlerken kilitleniyorsa, bir sonraki sefer kuyruk alıcısı bir mesajlaşma oturumunu kabul ederse, oturumun kilit süresi dolduktan sonra başarısız iletiyle başlar.
- Depolama kuyrukları, aşağıdakiler gibi standart kuyruğa alma senaryolarını destekleyecek şekilde tasarlanmıştır:
- Hataların ölçeklenebilirliğini ve toleransını artırmak için uygulama bileşenlerini ayırma
- Yük dengeleme
- İşlem iş akışları oluşturma.
- Service Bus oturumları bağlamında ileti işlemeyle ilgili tutarsızlıklar, oturumun ileti sırasını işlemenin ilerleme durumuna göre uygulamanın durumunu depolamak için oturum durumu kullanılarak ve alınan iletilerin ayarlanması ve oturum durumunun güncelleştirilmesiyle ilgili işlemler kullanılarak önlenebilir. Bu tür bir tutarlılık özelliği bazen diğer satıcının ürünlerinde tam olarak bir kez işlendiğinde etiketlenmiştir. Herhangi bir işlem hatası iletilerin yeniden teslim edilmesine neden olur ve bu nedenle terim tam olarak yeterli değildir.
- Depolama kuyrukları, hem geliştiriciler hem de operasyon ekipleri için kuyruklar, tablolar ve BLOB'lar arasında tekdüzen ve tutarlı bir programlama modeli sağlar.
- Service Bus kuyrukları, tek bir kuyruk bağlamında yerel işlemler için destek sağlar.
- Service Bus tarafından desteklenen Alma ve Silme modu, daha düşük teslim güvencesi karşılığında mesajlaşma işlemi sayısını (ve ilişkili maliyeti) azaltma olanağı sağlar.
- Depolama kuyrukları, kiralamalara ileti kiralarını genişletme olanağı sağlar. Bu özellik, çalışan işlemlerinin iletilerde kısa kiralamalar yapmasını sağlar. Bu nedenle, bir çalışan kilitlenirse ileti başka bir çalışan tarafından hızla yeniden işlenebilir. Ayrıca bir çalışan, geçerli kiralama süresinden daha uzun süre işlemesi gerekiyorsa iletideki kira süresini uzatabilir.
- Depolama kuyrukları, bir iletinin sıralanması veya sıralanması üzerine ayarlayabileceğiniz bir görünürlük zaman aşımı sunar. Ayrıca, çalışma zamanında farklı kira değerlerine sahip bir iletiyi güncelleştirebilir ve aynı kuyruktaki iletiler arasında farklı değerleri güncelleştirebilirsiniz. Service Bus kilit zaman aşımları kuyruk meta verilerinde tanımlanır. Ancak, önceden tanımlanmış kilit süresi için ileti kilidini el ile yenileyebilir veya istemcinin sizin için kilit yenilemeyi yönettiği otomatik kilit yenileme özelliğini kullanabilirsiniz.
- Service Bus kuyruklarında engelleme alma işlemi için en fazla zaman aşımı 24 gündür. Ancak REST tabanlı zaman aşımları en fazla 55 saniyelik bir değere sahiptir.
- Service Bus tarafından sağlanan istemci tarafı toplu işlemi, bir kuyruk istemcisinin birden çok iletiyi tek bir gönderme işlemi halinde toplu işlemesine olanak tanır. Toplu işlem yalnızca zaman uyumsuz gönderme işlemleri için kullanılabilir.
- Depolama kuyruklarının 200 TB'lık tavanı (hesapları sanallaştırdığınızda daha fazla) ve sınırsız kuyruklar gibi özellikler onu SaaS sağlayıcıları için ideal bir platform haline getirir.
- Depolama kuyrukları esnek ve performanslı bir temsilcili erişim denetimi mekanizması sağlar.
Gelişmiş özellikler
Bu bölüm, Depolama kuyrukları ve Service Bus kuyrukları tarafından sağlanan gelişmiş özellikleri karşılaştırır.
| Karşılaştırma Ölçütleri | Depolama kuyrukları | Service Bus kuyrukları |
|---|---|---|
| Zamanlanmış teslim | Yes | Yes |
| Otomatik ölü harfleme | Hayır | Evet |
| Kuyruk yaşam süresi değerini artırma | Yes (görünürlük zaman aşımının yerinde güncelleştirilerek) |
Yes (ayrılmış BIR API işlevi aracılığıyla sağlanır) |
| Zehirli ileti desteği | Yes | Yes |
| Yerinde güncelleştirme | Yes | Yes |
| Sunucu tarafı işlem günlüğü | Yes | Hayır |
| Depolama ölçümleri | Yes Dakika Ölçümleri kullanılabilirlik, TPS, API çağrı sayıları, hata sayıları ve daha fazlası için gerçek zamanlı ölçümler sağlar. Hepsi gerçek zamanlıdır, dakika başına toplanır ve üretimde olanlardan birkaç dakika içinde bildirilir. Daha fazla bilgi için bkz. Depolama Analizi Ölçümleri Hakkında. |
Yes Azure Service Bus tarafından desteklenen ölçümler hakkında bilgi için bkz . İleti ölçümleri. |
| Durum yönetimi | Hayır | Evet (Etkin, Devre Dışı, SendDisabled, ReceiveDisabled. Bu durumlarla ilgili ayrıntılar için bkz. Kuyruk durumu) |
| İletiyi otomatik olarak zorlama | Hayır | Evet |
| Kuyruk temizleme işlevi | Yes | Evet |
| İleti grupları | Hayır | Evet (mesajlaşma oturumlarını kullanarak) |
| İleti grubu başına uygulama durumu | Hayır | Evet |
| Yinelenen öğe algılaması | Hayır | Evet (gönderen tarafında yapılandırılabilir) |
| İleti gruplarına göz atma | Hayır | Evet |
| İleti oturumlarını kimliğine göre getirme | Hayır | Evet |
Ek bilgi
- Her iki kuyruğa alma teknolojisi de iletinin daha sonra teslim için zamanlanması sağlar.
- Kuyruk otomatik zorlama, binlerce kuyruğun iletilerini otomatik olarak tek bir kuyruğa göndermesini sağlar ve bu kuyrukta alıcı uygulama iletiyi tüketir. Her ileti yayımcısı arasında güvenlik, denetim akışı ve yalıtma elde etmek için bu mekanizmayı kullanabilirsiniz.
- Depolama kuyrukları, ileti içeriğini güncelleştirme desteği sağlar. Bu işlevi, durum bilgilerini ve artımlı ilerleme güncelleştirmelerini iletide kalıcı hale getirerek sıfırdan başlamak yerine bilinen son denetim noktasından işlenebilmesini sağlayabilirsiniz. Service Bus kuyruklarıyla, ileti oturumlarını kullanarak aynı senaryoyu etkinleştirebilirsiniz. Daha fazla bilgi için bkz . İleti oturumu durumu.
- Service Bus kuyrukları, teslim edilemeyen bildirimleri destekler. Aşağıdaki ölçütlere uyan iletileri yalıtmada yararlı olabilir:
- İletiler alıcı uygulama tarafından başarıyla işlenemiyor
- Süresi dolan yaşam süresi (TTL) özelliği nedeniyle iletiler hedeflerine ulaşamıyor. TTL değeri, bir iletinin kuyrukta ne kadar süre kaldığını belirtir. Service Bus ile, TTL dönemi sona erdiğinde ileti $DeadLetterQueue adlı özel bir kuyruğa taşınır.
- Depolama kuyruklarında "zehirli" iletileri bulmak için, bir iletiyi sıralarken uygulama iletinin DequeueCount özelliğini inceler. DequeueCount belirli bir eşikten büyükse, uygulama iletiyi uygulama tanımlı bir "teslim edilemedi" kuyruğuna taşır.
- Depolama kuyrukları, kuyrukta yürütülen tüm işlemlerin ve toplanan ölçümlerin ayrıntılı günlüğünü almanıza olanak tanır. Bu seçeneklerin her ikisi de hata ayıklama ve uygulamanızın Depolama kuyruklarını nasıl kullandığını anlamak için kullanışlıdır. Ayrıca uygulamanızın performansını ayarlamak ve kuyrukları kullanma maliyetlerini azaltmak için de kullanışlıdır.
- Service Bus tarafından desteklenen ileti oturumları , bir mantıksal gruba ait iletilerin bir alıcıyla ilişkilendirilmesine olanak tanır. İletiler ve ilgili alıcıları arasında oturum benzeri bir benzite oluşturur. Bir iletide oturum kimliği özelliğini ayarlayarak Bu gelişmiş işlevselliği Service Bus'ta etkinleştirebilirsiniz. Alıcılar daha sonra belirli bir oturum kimliğini dinleyebilir ve belirtilen oturum tanımlayıcısını paylaşan iletileri alabilir.
- Service Bus kuyruklarının yineleme algılama özelliği, ileti kimliği özelliğinin değerine bağlı olarak bir kuyruğa veya konuya gönderilen yinelenen iletileri otomatik olarak kaldırır.
Kapasite ve kotalar
Bu bölümde, Depolama kuyrukları ve Service Bus kuyrukları kapasite ve geçerli olabilecek kotalar açısından karşılaştırır.
| Karşılaştırma Ölçütleri | Depolama kuyrukları | Service Bus kuyrukları |
|---|---|---|
| En büyük kuyruk boyutu | 500 TB (tek bir depolama hesabı kapasitesiyle sınırlıdır) |
1 GB ile 80 GB (Bölümleme ile Premium SKU veya Standart SKU) |
| İleti boyutu üst sınırı | 64 KB (Temel 64 kodlama kullanılırken 48 KB) Azure desteği kuyrukları ve blobları birleştirerek büyük iletileri Azure desteği; bu noktada tek bir öğe için en fazla 200 GB sıraya alabilirsiniz. |
256 KB, 1 MB veya 100 MB (hem üst bilgi hem de gövde dahil, üst bilgi boyutu üst bilgi boyutu: 64 KB). Hizmet katmanına bağlıdır. |
| En fazla ileti TTL'si | Sonsuz (api-version 2017-07-27 veya üzeri) | TimeSpan.MaxValue |
| En fazla kuyruk sayısı | Sınırsız | 10.000 (Standart SKU) 1000 / Mesajlaşma Birimi (Premium SKU) (hizmet ad alanı başına) |
| En fazla eşzamanlı istemci sayısı | Sınırsız | 5.000 |
Ek bilgi
- Service Bus, kuyruk boyutu sınırlarını zorlar. Kuyruk oluşturulurken en büyük kuyruk boyutu belirtilir. 1 GB ile 80 GB arasında olabilir. Kuyruğun boyutu bu sınıra ulaşırsa, ek gelen iletiler reddedilir ve arayan bir özel durum alır. Service Bus'taki kotalar hakkında daha fazla bilgi için bkz . Service Bus Kotaları.
- Standart mesajlaşma katmanında 1 (varsayılan), 2, 3, 4 veya 5 GB boyutunda Service Bus kuyrukları ve konuları oluşturabilirsiniz. Standart katmanda bölümleme etkinleştirilirken Service Bus, varlığın her biri aynı boyutta belirtilen 16 kopyasını (16 bölüm) oluşturur. Bu nedenle, boyutu 5 GB olan bir kuyruk oluşturursanız, 16 bölümle en fazla kuyruk boyutu (5 * 16) = 80 GB olur. Bölümlenmiş kuyruğunuzun veya konu başlığınızın en büyük boyutunu Azure portalında görebilirsiniz.
- Depolama kuyruklarında, iletinin içeriği XML açısından güvenli değilse Base64 kodlanmış olmalıdır. İletiyi Base64 ile kodlarsanız, kullanıcı yükü 64 KB yerine en fazla 48 KB olabilir.
- Service Bus kuyruklarında, kuyrukta depolanan her ileti iki bölümden oluşur: üst bilgi ve gövde. İletinin toplam boyutu, hizmet katmanı tarafından desteklenen ileti boyutu üst sınırını aşamaz.
- İstemciler TCP protokolü üzerinden Service Bus kuyruklarıyla iletişim kurarken, tek bir Service Bus kuyruğuna eş zamanlı bağlantı sayısı üst sınırı 100 ile sınırlıdır. Bu numara gönderenler ve alıcılar arasında paylaşılır. Bu kotaya ulaşılırsa, ek bağlantı istekleri reddedilir ve çağrı kodu tarafından bir özel durum alınır. Bu sınır, REST tabanlı API kullanarak kuyruklara bağlanan istemcilere uygulanmaz.
- Service Bus Standart SKU'su veya Service Bus Premium SKU ile 1000 kuyruk/Mesajlaşma Birimi ile 10.000 kuyruğun ötesine ölçeklendirmek için Azure portalını kullanarak ek ad alanları da oluşturabilirsiniz.
Yönetim ve işlemler
Bu bölüm, Depolama kuyrukları ve Service Bus kuyrukları tarafından sağlanan yönetim özelliklerini karşılaştırır.
| Karşılaştırma Ölçütleri | Depolama kuyrukları | Service Bus kuyrukları |
|---|---|---|
| Yönetim protokolü | HTTP/HTTPS üzerinden REST | HTTPS üzerinden REST |
| Çalışma zamanı protokolü | HTTP/HTTPS üzerinden REST | HTTPS üzerinden REST AMQP 1.0 Standard (TLS ile TCP) |
| .NET API’si | Yes (.NET Depolama İstemciSI API'si) |
Yes (.NET Service Bus API'si) |
| Yerel C++ | Yes | Yes |
| Java API’si | Yes | Yes |
| PHP API'si | Yes | Yes |
| Node.js API’si | Yes | Yes |
| Rastgele meta veri desteği | Yes | Hayır |
| Kuyruk adlandırma kuralları | En fazla 63 karakter uzunluğunda (Kuyruk adındaki harfler küçük harf olmalıdır.) |
En fazla 260 karakter uzunluğunda (Kuyruk yolları ve adları büyük/küçük harfe duyarlı değildir.) |
| Kuyruk uzunluğu işlevini alma | Yes (İletilerin süresi silinmeden TTL'nin ötesinde dolarsa yaklaşık değer.) |
Yes (Tam, belirli bir noktaya değer.) |
| Peek işlevi | Yes | Yes |
Ek bilgi
- Depolama kuyrukları, ad/değer çiftleri biçiminde kuyruk açıklamasına uygulanabilen rastgele öznitelikler için destek sağlar.
- Her iki kuyruk teknolojisi de iletiyi kilitlemek zorunda kalmadan göz atma olanağı sunar. Bu, kuyruk gezgini/tarayıcı aracı uygulanırken yararlı olabilir.
- Service Bus .NET aracılı mesajlaşma API'leri, HTTP üzerinden REST ile karşılaştırıldığında iyileştirilmiş performans için tam çift yönlü TCP bağlantıları kullanır ve AMQP 1.0 standart protokollerini destekler.
- Depolama kuyruklarının adları 3-63 karakter uzunluğunda olabilir, küçük harfler, sayılar ve kısa çizgiler içerebilir. Daha fazla bilgi için bkz . Kuyrukları ve Meta Verileri Adlandırma.
- Service Bus kuyruğu adları en fazla 260 karakter uzunluğunda olabilir ve daha az kısıtlayıcı adlandırma kurallarına sahip olabilir. Service Bus kuyruğu adları harf, sayı, nokta, kısa çizgi ve alt çizgi içerebilir.
Kimlik doğrulaması ve yetkilendirme
Bu bölümde Depolama kuyrukları ve Service Bus kuyrukları tarafından desteklenen kimlik doğrulaması ve yetkilendirme özellikleri ele alınmaktadır.
| Karşılaştırma Ölçütleri | Depolama kuyrukları | Service Bus kuyrukları |
|---|---|---|
| Kimlik Doğrulaması | Simetrik anahtar ve Rol tabanlı erişim denetimi (RBAC) | Simetrik anahtar ve Rol tabanlı erişim denetimi (RBAC) |
| Kimlik sağlayıcısı federasyonu | Yes | Yes |
Ek bilgi
- Kuyruğa alma teknolojilerinden herhangi biri için yapılan her isteğin kimliği doğrulanmalıdır. Anonim erişime sahip genel kuyruklar desteklenmez.
- Paylaşılan erişim imzası (SAS) kimlik doğrulamasını kullanarak, kullanıcılara salt yazma, salt okunur veya tam erişim verebilen bir kuyrukta paylaşılan erişim yetkilendirme kuralı oluşturabilirsiniz. Daha fazla bilgi için bkz . Azure Depolama - SAS kimlik doğrulaması ve Azure Service Bus - SAS kimlik doğrulaması.
- Her iki kuyruk da Microsoft Entra Id kullanarak erişimi yetkilendirmeyi destekler. Microsoft Entra ID tarafından döndürülen OAuth 2.0 belirtecini kullanarak kullanıcıları veya uygulamaları yetkilendirmek, paylaşılan erişim imzaları (SAS) üzerinden üstün güvenlik ve kullanım kolaylığı sağlar. Microsoft Entra Id ile belirteçleri kodunuzda depolamanıza ve olası güvenlik açıklarını riske atmaya gerek yoktur. Daha fazla bilgi için bkz . Azure Depolama - Microsoft Entra kimlik doğrulaması ve Azure Service Bus - Microsoft Entra kimlik doğrulaması.
Sonuç
İki teknoloji hakkında daha ayrıntılı bilgi edinerek, hangi kuyruk teknolojisinin ne zaman kullanılacağı konusunda daha bilinçli bir karar vekleyebilirsiniz. Depolama kuyruklarının veya Service Bus kuyruklarının ne zaman kullanılacağına ilişkin karar birçok faktöre bağlıdır. Bu faktörler, uygulamanızın ve mimarinizin bireysel ihtiyaçlarına büyük ölçüde bağlıdır.
Aşağıdakiler gibi nedenlerle Depolama kuyruklarını seçmeyi tercih edebilirsiniz:
- Uygulamanız zaten Microsoft Azure'ın temel özelliklerini kullanıyorsa
- Hizmetler arasında temel iletişim ve mesajlaşma gerekiyorsa
- Boyutu 80 GB'tan büyük olabilecek kuyruklar gerekiyor
Service Bus kuyrukları aşağıdakiler gibi birçok gelişmiş özellik sağlar. Bu nedenle, karma bir uygulama oluşturuyorsanız veya uygulamanız bu özellikleri gerektiriyorsa tercih edilen bir seçenek olabilir.
- Oturumlar
- İşlemler
- Yinelenen saptama
- Otomatik ölü harfleme
- Dayanıklı yayımlama ve abone olma özellikleri
Sonraki adımlar
Aşağıdaki makaleler Depolama kuyruklarını veya Service Bus kuyruklarını kullanma hakkında daha fazla rehberlik ve bilgi sağlar.