Azure Service Bus - Sık sorulan sorular (SSS)

Bu makalede, Microsoft Azure Service Bus hakkında sık sorulan bazı sorular ele alınmaktadır. Genel Azure fiyatlandırması ve destek bilgileri için Azure Desteği SSS'lerini de ziyaret edebilirsiniz.

Azure Service Bus hakkında genel sorular

Azure Service Bus nedir?

Azure Service Bus , ayrılmış sistemler arasında veri göndermenizi sağlayan zaman uyumsuz bir mesajlaşma bulut platformudur. Microsoft bu özelliği bir hizmet olarak sunar; başka bir deyişle, bunu kullanmak için kendi donanımınızı barındırmanıza gerek yoktur.

Service Bus ad alanı nedir?

Ad alanı , uygulamanızdaki Service Bus kaynaklarını ele almak için bir kapsam kapsayıcısı sağlar. Ad alanı oluşturmak Service Bus'ı kullanmak için gereklidir ve kullanmaya başlamanın ilk adımlarından biridir.

Azure Service Bus kuyruğu nedir?

Service Bus kuyruğu, iletilerin depolandığı bir varlıktır. Kuyruklar, birden çok uygulamanız veya dağıtılmış bir uygulamanın birbiriyle iletişim kurması gereken birden çok parçası olduğunda kullanışlıdır. Kuyruk, birden çok ürünün (ileti) alındığı ve bu konumdan gönderildiği dağıtım merkezine benzer.

Azure Service Bus konuları ve abonelikleri nelerdir?

Bir konu kuyruk olarak görselleştirilebilir ve birden çok abonelik kullanıldığında daha zengin bir mesajlaşma modeli haline gelir; temelde bire çok iletişim aracıdır. Bu yayımlama/abone olma modeli (veya pub/sub), birden çok aboneliği olan bir konuya ileti gönderen bir uygulamanın bu iletiyi birden çok uygulama tarafından alınmasını sağlar.

Bölümlenmiş varlık nedir?

Geleneksel bir kuyruk veya konu başlığı tek bir ileti aracısı tarafından işlenir ve tek bir mesajlaşma deposunda depolanır. Bölümlenmiş bir kuyruk veya konu başlığı birden çok ileti aracısı tarafından işlenir ve birden çok mesajlaşma deposunda depolanır. Bu özellik, bölümlenmiş bir kuyruğun veya konunun genel aktarım hızının artık tek bir ileti aracısı veya mesajlaşma deposunun performansıyla sınırlı olmadığı anlamına gelir. Ayrıca, bir mesajlaşma deposunda geçici bir kesinti, bölümlenmiş bir kuyruğu veya konu başlığını kullanılamaz duruma getirmiyor.

Bölümlenmiş varlıklar kullanılırken sıralama sağlanmıyor. Bir bölümün kullanılamadığı durumlarda, diğer bölümlerden ileti gönderip almaya devam edebilirsiniz.

Azure Service Bus verileri nerede depolar?

Azure Service Bus standart katmanı, arka uç depolama katmanı için Azure SQL Veritabanı kullanır. Güney Brezilya ve Güneydoğu Asya dışındaki tüm bölgeler için veritabanı yedeklemesi farklı bir bölgede (genellikle Azure eşleştirilmiş bölgesi) barındırılır. Güney Brezilya ve Güneydoğu Asya bölgelerinde veritabanı yedeklemeleri, bu bölgeler için veri yerleşimi gereksinimlerini karşılamak üzere aynı bölgede depolanır.

Azure Service Bus premium katmanı meta verileri ve verileri seçtiğiniz bölgelerde depolar. Azure Service Bus premium ad alanı için coğrafi olağanüstü durum kurtarma ayarlandığında, meta veriler seçtiğiniz ikincil bölgeye kopyalanır.

Güvenlik duvarında hangi bağlantı noktalarını açmam gerekiyor?

İleti göndermek ve almak için Azure Service Bus ile aşağıdaki protokolleri kullanabilirsiniz:

  • Gelişmiş Message Queuing Protokolü 1.0 (AMQP)
  • TLS ile Köprü Metni Aktarım Protokolü 1.1 (HTTPS)

Azure Service Bus ile iletişim kurmak için bu protokolleri kullanmak üzere açmanız gereken giden TCP bağlantı noktaları için aşağıdaki tabloya bakın:

Protokol Bağlantı Noktaları Ayrıntılar
AMQP 5671, 5672 TLS ile AMQP. Bkz. AMQP protokol kılavuzu
HTTPS 443 Bu bağlantı noktası HTTP/REST API ve AMQP-over-WebSockets için kullanılır

İSTEMCI SDK'ları tarafından gerçekleştirilen çeşitli yönetim işlemleri ve Microsoft Entra ID'den belirteç alma (kullanıldığında) HTTPS üzerinden çalıştırıldığından, AMQP bağlantı noktası 5671 üzerinden kullanıldığında da HTTPS bağlantı noktası genellikle giden iletişim için gereklidir.

Resmi Azure SDK'ları genellikle Service Bus'tan ileti göndermek ve almak için AMQP protokollerini kullanır.

AMQP-over-WebSockets protokol seçeneği, HTTP/REST API gibi TCP 443 bağlantı noktası üzerinden çalışır, ancak aksi takdirde işlevsel olarak düz AMQP ile aynıdır. Bu seçenek, fazladan el sıkışması gidiş dönüşleri nedeniyle daha yüksek ilk bağlantı gecikme süresine ve HTTPS bağlantı noktasının paylaşılması için biraz daha fazla ek yüke sahiptir. Bu mod seçilirse, iletişim için 443 numaralı TCP bağlantı noktası yeterlidir. Aşağıdaki seçenekler AMQP WebSockets modunun seçilmesine izin verir.

Dil Seçenek
.NET (Azure.Messaging.ServiceBus) ServiceBusClientOptions'i parametre olarak alan bir oluşturucu kullanarak ServiceBusClient oluşturun. ServiceBusClientOptions.TransportType değerini ServiceBusTransportType.AmqpWebSockets olarak ayarlayın
.NET (Microsoft.Azure.ServiceBus) İstemci nesneleri oluştururken TransportType, ServiceBus Bağlan ion veya ServiceBus Bağlan ionStringBuilder'ı parametre olarak kullanan oluşturucuları kullanın.

Parametre olarak alan transportType yapı için parametresini TransportType.AmqpWebSockets olarak ayarlayın.

Parametre olarak alan ServiceBusConnection oluşturucu için ServiceBus Bağlan ion değerini ayarlayın. TransportType-TransportType.AmqpWebSockets.

kullanıyorsanız ServiceBusConnectionStringBuilder, öğesini belirtmek transportTypeiçin size bir seçenek sağlayan oluşturucuları kullanın.

Java (com.azure.messaging.servicebus) İstemci oluştururken ServiceBusClientBuilder.transportType değerini AmqpTransportType.AMQP.AMQP_WEB_SOCKETS olarak ayarlayın
Java (com.microsoft.azure.servicebus) İstemci oluştururken com.microsoft.azure.servicebus.Client Ayarlar içinde com.microsoft.azure.servicebus.primitives.TransportType.AMQP_WEB_SOCKETS olarak ayarlayın transportType
JavaScript Service Bus istemci nesneleri oluştururken, ServiceBusClientOptions içindeki özelliğini kullanınwebSocketOptions.
Python Service Bus istemcileri oluştururken ServiceBusClient.transport_type TransportType.AmqpOverWebSocket olarak ayarlayın

30 Eylül 2026'da Azure SDK yönergelerine uymayan WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus ve com.microsoft.azure.servicebus Azure Service Bus SDK kitaplıklarını kullanımdan kaldıracağız. Ayrıca SBMP protokolünün desteğini de sonlandıracağız, bu nedenle 30 Eylül 2026'da bu protokolü artık kullanamayacaksınız. Bu tarihten önce kritik güvenlik güncelleştirmeleri ve geliştirilmiş özellikler sunan en son Azure SDK kitaplıklarına geçiş yapın.

Eski kitaplıklar 30 Eylül 2026'dan sonra da kullanılabilir olsa da artık Microsoft'tan resmi destek ve güncelleştirmeler almayacaktır. Daha fazla bilgi için bkz . destek kullanımdan kaldırma duyurusu.

Azure Service Bus Java İleti Hizmeti'nin (JMS) destekleniyor mu?

İzin verilenler listesine hangi IP adreslerini eklemem gerekiyor?

Bağlantılarınız için izin verilenler listesine eklenecek doğru IP adreslerini bulmak için şu adımları izleyin:

  1. Bir komut isteminden aşağıdaki komutu çalıştırın:

    nslookup <YourNamespaceName>.servicebus.windows.net
    
  2. içinde Non-authoritative answerdöndürülen IP adresini not edin.

Ad alanınız için bölge yedekliliğini kullanıyorsanız, birkaç ek adım gerçekleştirmeniz gerekir:

  1. İlk olarak, ad alanında nslookup çalıştırırsınız.

    nslookup <yournamespace>.servicebus.windows.net
    
  2. Aşağıdaki biçimlerden birinde yer alan yetkili olmayan yanıt bölümündeki adı not edin:

    <name>-s1.cloudapp.net
    <name>-s2.cloudapp.net
    <name>-s3.cloudapp.net
    
  3. S1, s2 ve s3 sonekleri olan her biri için nslookup komutunu çalıştırarak üç kullanılabilirlik alanında çalışan üç örneğin de IP adreslerini alın,

    Not

    Komut tarafından nslookup döndürülen IP adresi statik bir IP adresi değildir. Temel alınan dağıtım silinene veya farklı bir kümeye taşınana kadar sabit kalır, ancak IN adreslerinin kullanılması önerilmez veya desteklenmez ve IP adreslerindeki değişiklikleri izlemeniz gerekir.

Bir ad alanına/ad alanından ileti gönderen/alan istemcinin IP adresini nerede bulabilirim?

Ad alanınıza ileti gönderen veya alan istemcilerin IP adreslerini günlüğe kaydetmeyiz. Anahtarları yeniden oluşturarak tüm mevcut istemcilerin kimlik doğrulamasından geçememesini sağlayın ve yalnızca izin verilen kullanıcıların veya uygulamaların ad alanına erişimi olduğundan emin olmak için Azure rol tabanlı erişim denetimi (Azure RBAC)) ayarlarını gözden geçirin.

Premium ad alanı kullanıyorsanız, ad alanına erişimi sınırlamak için IP filtreleme, sanal ağ hizmet uç noktaları ve özel uç noktaları kullanın.

En iyi yöntemler

Bazı Azure Service Bus en iyi yöntemleri nelerdir?

Bkz. Service Bus kullanarak performans geliştirmeleri için en iyi yöntemler – bu makalede, ileti alışverişi sırasında performansın nasıl iyileştirilmesi anlatılmaktadır.

Varlık oluşturmadan önce neleri bilmem gerekir?

Bir kuyruğun ve konunun aşağıdaki özellikleri sabittir. Varlıklarınızı oluştururken bu sınırlamayı göz önünde bulundurun çünkü bu özellikler yeni bir değiştirme varlığı oluşturulmadan değiştirilemez.

  • Bölümleme
  • Oturumlar
  • Yinelenen öğe algılaması
  • Express varlığı

Fiyatlandırma

Bu bölümde Service Bus fiyatlandırma yapısı hakkında sık sorulan bazı sorular yanıtlanmıştır.

Service Bus fiyatlandırma ve faturalama makalesinde Service Bus'taki faturalama ölçümleri açıklanmaktadır. Service Bus fiyatlandırma seçenekleri hakkında belirli bilgiler için bkz . Service Bus fiyatlandırma ayrıntıları.

Genel Azure fiyatlandırma bilgileri için Azure Desteği SSS'lerini de ziyaret edebilirsiniz.

Service Bus için nasıl ücret ödersiniz?

Service Bus fiyatlandırması hakkında tam bilgi için bkz . Service Bus fiyatlandırma ayrıntıları. Belirtilen fiyatlara ek olarak, uygulamanızın sağlandığı veri merkezinin dışındaki çıkış için ilişkili veri aktarımları için ücretlendirilirsiniz.

Hangi Service Bus kullanımı veri aktarımına tabidir? Ne değildir?

Belirli bir Azure bölgesindeki tüm veri aktarımları ve gelen veri aktarımları ücretsiz olarak sağlanır. Bölge dışına veri aktarımı çıkış ücretlerine tabidir ve bu ücret burada bulunabilir.

Service Bus depolama için ücretlendirilir mi?

Hayır Service Bus depolama için ücret almaz. Ancak, kuyruk/konu başına kalıcı olabilecek maksimum veri miktarını sınırlayan bir kota vardır. Sonraki SSS bölümüne bakın.

Service Bus Standard ad alanım var. '$system' kaynak grubu altında ücretleri neden görüyorum?

Azure Service Bus kısa süre önce faturalama bileşenlerini yükseltti. Bu değişiklik nedeniyle, Service Bus Standard ad alanınız varsa kaynak grubu $systemaltında kaynağın /subscriptions/<azure_subscription_id>/resourceGroups/$system/providers/Microsoft.ServiceBus/namespaces/$system satır öğelerini görebilirsiniz.

Bu ücretler, Service Bus Standart ad alanı sağlayan Azure aboneliği başına temel ücreti temsil eder.

Bu ücretlerin yeni olmadığını, yani önceki faturalama modelinde de mevcut olduğunu unutmayın. Tek değişiklik, artık altında $systemlistelenmeleridir. Yeni faturalama sisteminde kaynak kimliği altında $system belirli bir kaynağa bağlı olmayan abonelik düzeyi ücretlerini gruplandıran kısıtlamalar nedeniyle yapılır.

Kotalar

Service Bus sınırları ve kotalarının listesi için bkz . Service Bus kotalarına genel bakış.

1 MB boyutunda > iletileri işleme

Service Bus mesajlaşma hizmetleri (kuyruklar ve konular/abonelikler), uygulamanın 256 KB 'a (standart katman) veya 100 MB'a (premium katman) kadar ileti göndermesine olanak sağlar. İzin verilen boyuttan büyük iletilerle ilgileniyorsanız, bu blog gönderisinde açıklanan talep denetimi desenini kullanın.

Sorun giderme

Başka bir abonelikten sildikten sonra neden ad alanı oluşturamıyorum?

Bir abonelikten bir ad alanını sildiğinizde, ad alanını başka bir abonelikte aynı adla yeniden oluşturmadan önce 4 saat bekleyin. Aksi takdirde şu hata iletisini alabilirsiniz: Namespace already exists.

Azure Service Bus API'leri tarafından oluşturulan bazı özel durumlar ve bunların önerilen eylemleri nelerdir?

Olası Service Bus özel durumlarının listesi için bkz . Özel durumlara genel bakış.

Paylaşılan Erişim İmzası nedir ve hangi diller imza oluşturmayı destekler?

Paylaşılan Erişim İmzaları, SHA-256 güvenli karmalarını veya URI'leri temel alan bir kimlik doğrulama mekanizmasıdır. Node.js, PHP, Java, Python ve C# içinde kendi imzalarınızı oluşturma hakkında bilgi için Paylaşılan Erişim İmzaları makalesine bakın.

Abonelik ve ad alanı yönetimi

Ad alanını başka bir Azure aboneliğine geçirmek Nasıl yaparım??

Azure portalını veya PowerShell komutlarını kullanarak bir ad alanını bir Azure aboneliğinden diğerine taşıyabilirsiniz. İşlemi yürütmek için ad alanının zaten etkin olması gerekir. Komutları yürüten kullanıcının hem kaynak hem de hedef aboneliklerde yönetici olması gerekir.

Portal

Azure portalını kullanarak Service Bus ad alanlarını başka bir aboneliğe geçirmek için buradaki yönergeleri izleyin.

PowerShell

Aşağıdaki PowerShell komutları dizisi, bir ad alanını bir Azure aboneliğinden diğerine taşır. Bu işlemi yürütmek için ad alanının zaten etkin olması ve PowerShell komutlarını çalıştıran kullanıcının hem kaynak hem de hedef aboneliklerde yönetici olması gerekir.

# Create a new resource group in target subscription
Select-AzSubscription -SubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff'
New-AzResourceGroup -Name 'targetRG' -Location 'East US'

# Move namespace from source subscription to target subscription
Select-AzSubscription -SubscriptionId 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'
$res = Find-AzResource -ResourceNameContains mynamespace -ResourceType 'Microsoft.ServiceBus/namespaces'
Move-AzResource -DestinationResourceGroupName 'targetRG' -DestinationSubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff' -ResourceId $res.ResourceId

Service Bus ad alanları üzerinde TLS 1.0 veya 1.1'i devre dışı bırakmak mümkün mü?

Evet, en düşük TLS sürümünü ayarlayarak Service Bus ad alanları üzerinde TLS 1.0 veya 1.1'i devre dışı bırakabilirsiniz. Daha fazla bilgi için bkz . Service Bus ad alanına yönelik istekler için Aktarım Katmanı Güvenliği'nin (TLS) gerekli en düşük sürümünü zorlama.

Sonraki adımlar

Service Bus hakkında daha fazla bilgi edinmek için aşağıdaki makalelere bakın: