Mesajlaşma platformu seçme
Microsoft Azure'da da dahil olmak üzere dağıtılmış bir uygulamanın güvenilirliğini artırmaya yardımcı olmak için birçok iletişim platformu kullanılabilir. Her platform farklı bir amaca hizmet eden bir araçtır. Uygulamanızdaki her gereksinim için doğru aracı seçmeniz önemlidir. Azure Service Bus'taki seçeneklerinize göz atın.
Önerilen Contoso Bisikletleri sipariş etme ve uygulamanın dağıtılmış mimarisini izleme için web sitesi, veri depolama ve arka uç hizmeti gibi çeşitli bileşenler gerekir. Uygulamanızın bileşenlerini birçok farklı yolla birbirine bağlayabilirsiniz ve tek bir uygulama birden çok teknikten yararlanabilir.
Yeni Contoso Bisikletleri uygulamasında hangi teknikleri kullanacağınıza karar vermeniz gerekir. İlk adım, birden çok parça arasında iletişimin olduğu her yeri değerlendirmektir. Uygulamanızın işini yapması için bazı bileşenlerin zamanında çalışması gerekir . Bazıları önemli olabilir, ancak zaman açısından kritik olmayabilir. Son olarak, mobil uygulama bildirimleri gibi diğer bileşenler biraz daha isteğe bağlıdır.
İletiler ve olaylar arasında seçim yapma
Hem iletiler hem de olaylar veri birimleridir: bir bileşenden diğerine gönderilen veri paketleri. Bunlar başlangıçta ince görünen şekillerde farklıdır, ancak farklar uygulamanızın mimarisini oluşturma yönteminizde önemli farklılıklara neden olabilir.
İletiler
Dağıtılmış uygulamaların terminolojisinde, bir iletinin tanımlama özelliği, uygulamanın genel bütünlüğünün alınan iletilere dayanabileceğidir. İleti göndermeyi bir bileşenin iş akışını başka bir bileşene teslim ettiği bir bayrak yarışı olarak düşünebilirsiniz. İş akışının tamamı önemli bir iş süreci olabilir ve ileti, bileşenleri bir arada tutan harçtır.
İletiler genellikle yalnızca veri başvurusu (kimlik veya URL gibi) değil gerçek verileri içerir. Verileri bir veri biriminin parçası olarak göndermek, başvuru göndermeye kıyasla daha az kırılgandır. Mesajlaşma mimarisi ileti teslimini garanti eder ve ek arama gerektiremediğinden ileti güvenilir bir şekilde işlenir. Ancak, gönderen uygulamanın çok fazla veri göndermeyi önlemek için tam olarak hangi verileri içermesi gerektiğini bilmesi gerekir ve bu da alıcı bileşenin gereksiz işler gerçekleştirmesini gerektirir. Bu anlamda, ileti göndereni ve alıcısı genellikle katı bir veri sözleşmesiyle birleştirilmiş durumdadır.
Contoso Bisikletleri'nin yeni mimarisinde, bir sipariş verildiğinde, şirket büyük olasılıkla iletileri kullanacaktır. Web ön ucu veya mobil uygulaması, arka uç işleme bileşenlerine bir ileti gönderir. Arka uçta, müşteriye en yakın mağazaya yönlendirme ve kredi kartı ücretlendirme gibi adımlar gerçekleşir.
Ekinlikler
Olay, bir şeyin gerçekleştiğini belirten bir bildirimi tetikler. Olaylar iletilerden daha "hafiftir" ve büyük çoğunlukla yayın iletişimlerinde kullanılır.
Olaylar aşağıdaki özelliklere sahiptir:
- Olay birden çok alıcıya veya hiç alıcıya gönderilebilir.
- Olaylar genellikle "yayma" amaçlıdır veya her yayıncı için çok fazla sayıda abone vardır.
- Olay yayımcısının, alıcı bileşenin gerçekleştirilen eylemle ilgili bir beklentisi yoktur.
Bisiklet parçaları zinciri büyük olasılıkla durum değişiklikleriyle ilgili kullanıcı bildirimleri için olayları kullanır. Durum değişikliği olayları Azure Event Grid'e, ardından Azure İşlevleri'a ve tamamen sunucusuz bir çözüm için Azure Notification Hubs'a gönderilebilir.
Olaylarla iletiler arasındaki temel fark, iletişim platformlarının genellikle ikisinden birini kullanacak şekilde tasarlanmış olmasıdır. Service Bus, iletileri işleyecek şekilde tasarlanmıştır. Olayları göndermek istiyorsanız, büyük olasılıkla Event Grid'i seçmeniz gerekir.
Azure'da da Azure Event Hubs vardır, ancak genellikle analiz için kullanılan belirli bir yüksek akışlı iletişim akışı için kullanılır. Örneğin, üretim ambarlarınızda ağa bağlı algılayıcılarınız varsa, istenmeyen bir yangın veya bileşen aşınmasına işaret edebilecek sıcaklık değişikliklerindeki desenleri izlemek için Event Hubs'ı Azure Stream Analytics ile birlikte kullanabilirsiniz.
Service Bus konuları ve kuyrukları
Azure Service Bus iki farklı yolla ileti alışverişi yapabilir: kuyruklar ve konular.
Kuyruk nedir?
Service Bus kuyruğu , iletiler için basit bir geçici depolama konumudur. İletiyi gönderen bileşen bunu bir kuyruğa ekler. Hedef bileşen, kuyruğun en önündeki iletiyi alır. Normal koşullarda her ileti yalnızca bir alıcı tarafından alınır.
Kuyruklar kaynak ve hedef bileşenleri birbirinden ayırarak, hedef bileşenleri yoğun isteklerden ayrı tutar.
Yoğun zamanlarda iletiler hedef bileşenlerin işleyebileceğinden daha hızlı gelebilir. Kaynak bileşenlerin hedefle doğrudan bağlantısı olmadığından kaynak etkilenmez ve kuyruk büyür. Hedef bileşenler, iletileri işleyebildiklerinden kuyruktan kaldırır. Talep düştüğünde hedef bileşenler yetişebilir ve kuyruk kısalır.
Kuyruk, sisteme kaynak eklemeye gerek kalmadan yüksek talebe yanıt verir. Ancak, hızlı bir şekilde işlenmesi gereken iletiler için hedef bileşeninizin daha fazla örneğini oluşturmak yükü paylaşmalarına izin verebilir. Her ileti yalnızca bir örnek tarafından işlenir. Bu, yalnızca gerçekten ihtiyaç duyan bileşenlere kaynak ekleyerek uygulamanızın tamamını ölçeklendirmenin etkili bir yoludur.
Konu nedir?
Service Bus konusu kuyruğa benzer, ancak bir konuda birden çok abonelik olabilir. Bu, birden çok hedef bileşenin belirli bir konuya abone olabileceği anlamına gelir, böylece her ileti birden çok alıcıya teslim edilir. Abonelikler ayrıca konudaki iletileri filtreleyerek yalnızca ilgili olan iletileri alabilir. Abonelikler kuyruklarla aynı iletişim ayrımını sağlar ve yoğun talep durumunda aynı şekilde yanıt verir. Bir iletinin birden fazla hedef bileşene teslim edilmesini istiyorsanız konuları kullanabilirsiniz.
Dekont
Konu başlıkları, Temel fiyatlandırma katmanında desteklenmez.
Service Bus kuyrukları ve depolama kuyrukları
İki Azure hizmeti ileti kuyrukları içerir: Service Bus ve Azure Depolama. Genel bir kılavuz olarak, depolama kuyruklarının kullanımı daha kolaydır, ancak Service Bus kuyruklarından daha az gelişmiş ve daha az esnektir.
Service Bus kuyruklarının başlıca avantajları şunlardır:
- 256 KB (standart katman) veya ileti başına 100 MB (premium katman) ve Azure Depolama kuyruk iletileri için 64 KB daha büyük ileti boyutlarını destekler.
- Hem en çok bir kez hem de en az bir kez teslimi destekler. Bir iletinin kaybolması veya iki kez işlenmesi için çok küçük bir olasılık arasında seçim yapın.
- İlk gelen, ilk çıkan (FIFO) siparişi garanti eder. İletiler eklendikleri sırayla işlenir. FIFO bir kuyruğun normal işlemi olsa da, kuruluş sıralı veya zamanlanmış iletiler ayarlarsa ya da sistem kilitlenmesi gibi kesintiler sırasında varsayılan FIFO düzeni değiştirilir. Daha fazla bilgi için bkz. Azure Depolama kuyruklarını ve Azure Service Bus kuyruklarını karşılaştırma.
- Bir işlemde birden çok iletiyi gruplandırabilir. İşlemdeki bir ileti teslim edilemezse, işlemdeki tüm iletiler teslim edilmez.
- Rol tabanlı güvenliği destekler.
- Hedef bileşenlerin kuyruğu sürekli yoklamasını gerektirmez.
Depolama kuyruklarının avantajları:
- Sınırsız kuyruk boyutunu destekler (Service Bus kuyruklarında 80 GB sınırı vardır)
- Tüm iletileri günlüğe kaydeder
İletişim teknolojisi seçme
Azure'ın sağladığı farklı kavramları ve uygulamaları gördünüz. Ardından, iletişimlerinizin her biri için karar sürecinizin nasıl görünmesi gerektiğini göz önünde bulundurun.
Dikkat edilmesi gerekenler
İleti göndermek ve almak için bir yöntem seçtiğinizde aşağıdaki soruları göz önünde bulundurun:
İletişim bir olay mı? Bu durumda Event Grid veya Event Hubs kullanın.
Bir iletinin birden fazla hedefe teslim edilmesi gerekiyor mu? Gerekiyorsa Service Bus konularını kullanın. Aksi takdirde, Service Bus kuyruğu kullanın.
Kuyruklar: Service Bus ile depolama karşılaştırması
Kuyruğa ihtiyacınız olduğuna karar verirseniz seçiminizi daha da daraltın.
Şu durumlarda bir Service Bus kuyruğu seçin:
- En fazla bir kerede teslimat garantisine ihtiyacınız vardır.
- Bir FIFO garantisine ihtiyacınız vardır (varsayılan FIFO sırasına önceden atanmış başka bir ayar yoksa).
- İletilerin işlemler içinde gruplandırılmasına ihtiyacınız var.
- Kuyruğu yoklamadan iletileri almak istiyorsunuz.
- Kuyruklara rol tabanlı erişim sağlamanız gerekir.
- Standart katman için 64 KB'tan büyük ancak 256 KB'tan küçük veya premium katman için 100 MB'tan küçük iletileri işlemeniz gerekir.
- Kuyruk boyutunuz 80 GB'tan büyük olmayacaktır.
- Toplu iletileri yayımlayıp kullanabilmek istiyorsunuz.
Şu durumlarda bir depolama kuyruğu seçin:
- Belirli bir ek gereksinimi olmayan basit bir kuyruğa ihtiyacınız vardır.
- Kuyruktan geçen tüm iletilerin denetim günlüğüne ihtiyacınız var.
- Kuyruğun boyutunun 80 GB'ı aşmasını bekliyorsunuz.
- Kuyruk içindeki bir iletiyi işleme işleminin ilerleme durumunu izlemek istiyorsunuz.
Dağıtılmış bir uygulamanın bileşenleri doğrudan iletişim kurabilir, ancak genellikle Azure Event Hubs veya Azure Event Grid gibi bir ara iletişim platformu kullanarak bu iletişimin güvenilirliğini artırabilirsiniz.
Event Hubs ve Event Grid, yalnızca bir olayı alıcılara bildiren ve bu olayla ilişkili ham verileri içermeyen olaylar için tasarlanmıştır. Azure Event Hubs, yüksek akışlı, analitik olay türleri için tasarlanmıştır.
Azure Service Bus ve depolama kuyrukları, herhangi bir uygulama iş akışının temel parçalarını bağlamak için kullanabileceğiniz iletiler içindir.
Gereksinimleriniz basitse, her iletiyi yalnızca bir hedefe göndermek istiyorsanız veya mümkün olan en hızlı şekilde kod yazmak istiyorsanız, depolama kuyruğu en iyi seçenek olabilir. Aksi takdirde Service Bus kuyrukları daha fazla seçenek ve esneklik sunmaktadır.
Birden çok aboneye ileti göndermek istiyorsanız bir Service Bus konusu kullanabilirsiniz.