İleti çoğaltma ve bölgeler arası federasyon
Ad alanları içinde Azure Service Bus, çeşitli yönlendirme desenlerinin uygulanmasına izin vermek için otomatik zorlama kullanarak zincirlenmiş kuyrukların ve konu aboneliklerinin topolojilerinin oluşturulmasını destekler. Örneğin, iş ortaklarına gönderme veya alma izinlerine sahip oldukları ve gerekirse geçici olarak askıya alınabilecek ayrılmış kuyruklar sağlayabilir ve bunları uygulamaya özel olan diğer varlıklara esnek bir şekilde bağlayabilirsiniz. Ayrıca karmaşık çok aşamalı yönlendirme topolojileri oluşturabilir veya konu başlıklarının kuyruk benzeri aboneliklerini tüketen ve abone başına daha fazla depolama kapasitesi sağlayan posta kutusu stili kuyruklar oluşturabilirsiniz.
Birçok gelişmiş çözüm, bu ve diğer desenleri uygulamak için iletilerin ad alanı sınırları arasında çoğaltılması da gerektirir. İletilerin birden çok, farklı uygulama kiracısıyla ilişkili ad alanları arasında veya birden çok farklı Azure bölgesinde akması gerekebilir.
Çözümünüz farklı bölgelerde birden çok Service Bus ad alanı bulunduracak ve iletileri Kuyruklar ve Konular arasında çoğaltacak ve/veya Azure Event Hubs, Azure IoT Hub veya Apache Kafka gibi kaynak ve hedeflerle ileti alışverişi yapacaksınız.
Bu senaryolar bu makalenin odak noktasıdır.
Federasyon Desenleri
İletileri Kuyruklar veya Konular gibi Service Bus varlıkları arasında veya Service Bus ile diğer kaynaklar ve hedefler arasında taşımak istemeniz için birçok olası motivasyon vardır.
Event Hubs için benzer desen kümesiyle karşılaştırıldığında, kuyruk benzeri varlıklar için federasyon daha karmaşıktır çünkü ileti kuyrukları tüketicilerine tek bir ileti üzerinde özel sahiplik vaat eder, ileti tesliminde varış sırasını korumaları ve aracının iletilerin rakip tüketiciler arasındaki adil dağıtımını koordine etmesi beklenir.
CAP teoreminin kısıtlamaları da dahil olmak üzere, birden çok bölgede aynı anda kullanılabilen ve bölgesel olarak dağıtılmış, rakip tüketicilerin iletilerin özel sahipliğini almasını sağlayan bir kuyruğun birleşik görünümünü sağlamayı zorlaştıran pratik engeller vardır. Coğrafi olarak dağıtılmış böyle bir kuyruk, yalnızca iletilerin değil, iletilerin tüketicilere sunulmadan önce her iletinin teslim durumunun da tamamen tutarlı bir şekilde çoğaltılması gerekir. Varsayımsal, bölgesel olarak dağıtılmış bir kuyruk için tam tutarlılık hedefi, federasyon senaryolarını değerlendirirken neredeyse tüm Azure Service Bus müşterilerin sahip olduğu temel hedefle doğrudan çakışmaktır: Çözümleri için maksimum kullanılabilirlik ve güvenilirlik.
Bu nedenle burada sunulan desenler kullanılabilirlik ve güvenilirlik konularına odaklanırken, aynı zamanda hem bilgi kaybını hem de iletilerin yinelenen işlenmesini en iyi şekilde önlemeyi amaçlar.
Bölgesel kullanılabilirlik olaylarına karşı dayanıklılık
Service Bus için en yüksek kullanılabilirlik ve güvenilirlik en önemli işletim öncelikleri olsa da, bir üreticinin veya tüketicinin ağ veya ad çözümleme sorunları nedeniyle atanmış "birincil" Service Bus ile konuşmasının engellenebileceği veya Service Bus varlığının aslında geçici olarak yanıt vermediği veya hatalar döndürebileceği birçok yol vardır. Belirlenen ileti işlemcisi de kullanılamaz duruma gelebilir.
Olağanüstü durum kurtarma durumunda olduğu gibi bölgesel dağıtımı tamamen bırakmak isteyeceğiniz gibi, bu tür koşullar "felaket" değildir, ancak bazı uygulamaların iş senaryosu zaten birkaç dakikadan veya birkaç saniyeden uzun sürmeyen kullanılabilirlik olaylarından etkilenmiş olabilir. Azure Service Bus genellikle hibrit bulut ortamlarında ve perakende mağazaları, restoran, bankacılık şubeleri, üretim siteleri, lojistik tesisleri ve havaalanları gibi ağ uçlarında bulunan müşterilerle birlikte kullanılır. Bir ağ yönlendirme veya tıkanıklık sorununun herhangi bir sitenin atanmış Service Bus uç noktasına ulaşma becerisini etkilemesi mümkündür, ancak farklı bir bölgedeki ikincil uç noktaya ulaşılabilir. Aynı zamanda, bu sitelerden gelen iletileri işleyen sistemlerin hem birincil hem de ikincil Service Bus uç noktalarına erişimi engellenmemiş olabilir.
Ağ yönlendirme sorunlarının veya Service Bus varlığının geçici kullanılabilirlik sorunlarının etkisine yönelik düşük iş toleransı olan bu tür hibrit bulut ve uç uygulamalarına birçok pratik örnek vardır. Bunlar arasında perakende satış sitelerindeki ödemelerin işlenmesi, havaalanı kapılarında biniş ve restoranlardaki cep telefonu siparişleri yer alır ve bunların hepsi anında gelir ve güvenilir iletişim yolu mevcut olmadığı zaman tam beklemede kalır.
Bu kategoride üç ayrı dağıtılmış desenden bahsedeceğiz: "all-active" çoğaltma, "etkin-pasif" çoğaltma ve "taşma" çoğaltması.
çoğaltmayı All-Active
"All-active" çoğaltma düzeni, aynı mantıksal konunun (veya kuyruğun) etkin bir çoğaltmasının birden çok ad alanında (ve bölgede) ve tüm iletilerin, kuyruğa alındıklarından bağımsız olarak tüm çoğaltmalarda kullanılabilir duruma gelmesini sağlar. Desen genellikle herhangi bir yayımcıya göre iletilerin sırasını korur.
Çizimde gösterildiği gibi, desen genellikle Service Bus Konuları'na dayandırır. Çoğaltma düzenine katılacak her ad alanı için bir konu. Bu konuların her birinde, iletilerin çoğaltılması gereken diğer konulardan herhangi biri için bir "çoğaltma aboneliği" vardır. Yukarıdaki çizimde yalnızca bir çift konu başlığımız ve dolayısıyla ilgili diğer konu için tek bir çoğaltma aboneliğimiz vardır. Üç ad alanı {n1, n2, n3} olan bir senaryoda, n1 ad alanı içindeki bir konu, biri n2'deki ilgili konu, diğeri de n3'teki ilgili konu için olmak üzere iki çoğaltma aboneliğine sahip olabilir.
Her çoğaltma aboneliğinde bir SQL filtre ifadesi (replicated <> 1) ile bir SQL eylemini () birleştiren bir kural vardırset replicated = 1. Kuralın filtresi, yalnızca özel özelliğin replication ayarlanmadığı veya değere 1 sahip olmadığı iletilerin bu abonelik için uygun olmasını sağlar ve eylem bu özelliği hemen ardından seçili her iletideki değere 1 ayarlar. Bunun etkisi, ileti ilgili konuya kopyalandığında, artık ters yönde çoğaltma için uygun olmamasıdır ve bu nedenle iletilerin çoğaltmalar arasında zıplamasını önleriz.
İlgili kurala sahip bir abonelik, Azure CLI kullanılarak herhangi bir konuya kolayca eklenebilir.
az servicebus topic subscription rule create --resource-group myresourcegroup \
--namespace mynamespace --topic-name mytopic \
--subscription-name replication --name replication \
--action-sql-expression "set replication = 1" \
--filter-sql-expression "replication IS NULL"
Bir kuyruğu modellemek için her konu, tüm tüketicilerin paylaştığı tek bir normal abonelikle (çoğaltma abonelikleri dışında) sınırlıdır.
Tüm etkin çoğaltma modeli, konu başlıklarından herhangi birine gönderilen her iletinin bir kopyasını konuların her birine yerleştirir. Bu, her bölgedeki uygulama kodunuzun tüm iletileri göreceği ve işleyeceği anlamına gelir. Bu düzen, verilerin birden çok bölgede paylaşıldığı veya yedekli işlemenin genel olarak istendiği senaryolar için uygundur. Normal kuyrukta olduğu gibi her iletiyi yalnızca bir kez işlemeniz gerekiyorsa, aşağıdaki iki desenden birini göz önünde bulundurmanız gerekir.
çoğaltmayı Active-Passive
"Etkin-pasif" çoğaltma deseni, uygulama tarafından ileti göndermek ve almak için yalnızca bir konunun ("birincil") etkin olarak kullanıldığı ve birincil konunun kullanılamaz veya ulaşılamaz duruma gelebileceği durum için ikincil bir konuya çoğaltıldığı önceki desenin varyasyonudur.
Bu desen ile önceki desen arasındaki temel fark, çoğaltmanın birincil konu başlığından ikincil konuya tek yönlü olmasıdır. İkincil konu hiçbir zaman birincil olmaz, ancak birincil konu geçici olarak kullanılamaz olduğunda için bir yedekleme seçeneğidir.
Bu düzeni kullanmanın iyi tarafı, yinelenen işlemeyi en aza indirmeye çalışmadır. Çoğaltma sırasında ileti özelliği, TimeToLive çoğaltılan iletilerde birincil hatanın yük devretmeye neden olacağı beklenen süreyi yansıtan bir süreye ayarlanır. Örneğin, kullanım örneği senaryonuz, iletilerin birincil başlangıçtan alınmasından itibaren en fazla 1 dakika içinde tüketicinin ikincil sunucuya geçişini gerektiriyorsa, ikincilde ideal olarak birincilde erişemediğiniz tüm iletilerin mevcut olması, ancak sorunlar ortaya çıkmadan önce birincilden önceden işlediğiniz en az sayıda iletinin olması gerekir. Bu süreyi çoğaltma sırasında (set sys.TimeToLive = '0:2:0'kural eyleminde) 2 dakika olmak üzere iki kez ayarlarsakTimeToLive, ikincil ileti yalnızca 2 dakika boyunca tutulur ve eskileri atar. Başka bir deyişle, alıcı ikincilye geçtiğinde, işlediği son iletiden daha eski iletileri hızla okuyup atabilir ve ardından henüz görmediği ilk iletiden işleyebilir. Gerçek saklama süresi, belirli bir kullanım örneğine ve hızlı bir şekilde istediğinize bağlıdır ve uygulamanızda ikincilye geçiş yapabilir. Ayar TimeToLive , birkaç saniye ile gün arasında kabul edilir.
Uygulama ikincili kullanırken, doğrudan ikincil konuya da yayımlayabilir ve bu da normal bir konu gibi davranır. İkincil geçiş sonrasında tüketici, çoğaltılan iletilerin ve doğrudan ikincilde yayımlanan iletilerin bir karışımını görür. Bu nedenle uygulama, tüketiciyi ikincil öğeye geri döndürmeden önce önce yayımlamayı birincile geri döndürmelidir ve yine de yerel olarak yayımlanan iletilerin boşaltılmasına izin vermelidir. Çoğaltma, birincil yeniden kullanılabilir olduğunda otomatik olarak devam ettiğinden, tüketici bu süre boyunca biraz daha yüksek gecikme süresiyle de olsa birincilde yayımlanan yeni iletileri de alır.
Bu düzen, iletilerin yalnızca bir kez işlenmesi gereken senaryolar için uygundur. Uygulamanın, ikincildeki yük devretme penceresinin süresi boyunca yinelenenleri bulacağından ve geri dönerken yine yinelenenleri bulacağından birincilden işlediği iletileri izlemek için işbirliği yapması gerekir. Yinelenenleri kaldırma ölçütü en iyi uygulama tarafından sağlanan
MessageIdolmalıdır. DeğerEnqueuedTimeUtcfiligran göstergesi olarak da uygundur, ancak uygulamanın herhangi bir dağıtılmış sistemde olduğu gibi birincil ve ikincil arasında bir miktar saat kaymasına (birkaç saniye) izin vermesi gerekir.
Taşma Çoğaltma
"Taşma" çoğaltma deseni, Service Bus'ın iyi durumda olduğu ancak tüketicinin bekleyen ileti sayısıyla dolu olduğu veya tam olarak kullanılamadığı senaryoyla başa çıkmak için birden çok bölgede birden çok Service Bus varlığı etkin/etkin kullanımına olanak tanır. Bunun bir nedeni, tüketici işlemini destekleyen bir veritabanının yavaş olması veya kullanılamamış olması olabilir. Bu düzen düz kuyruklarla ve konu abonelikleriyle çalışır.
Çizimde gösterildiği gibi, taşma çoğaltma düzeni bir kuyruğun veya aboneliğin ilişkili teslim edilemeyen ileti kuyruğundaki iletileri farklı bir ad alanında eşleştirilmiş bir kuyruğa veya konuya çoğaltır.
Bir hata durumu olmadan, her biri genel ileti trafiğinin bir alt kümesini alan ve ilişkili tüketicileri bu alt kümeyi işleyen iki ad alanı paralel olarak kullanılır. Tüketicilerden biri yüksek hata oranları göstermeye başladığında veya hemen durduğunda, ilgili iletiler teslim sayısını aşarak veya süresi dolduğundan teslim edilemeyen ileti kuyruğuna ulaşacaktır. Çoğaltma görevleri daha sonra bunları alır ve eşleştirilmiş kuyrukta yeniden kuyruğa alır ve daha sonra olası iyi durumdaki tüketiciye sunulur.
İşlemenin belirli bir son tarih içinde gerçekleşmesi gerekiyorsa, TimeToLive kuyruk ve/veya iletiler için, işlemenin ikincil taşma ikincil tarafından zamanında gerçekleşebileceği şekilde ayarlanmalıdır; örneğin TimeToLive izin verilen sürenin yarısına ayarlanmış olabilir.
Tümü etkin desende olduğu gibi, uygulama iletiye iletinin bir kez çoğaltılıp çoğaltılmadığının göstergesini ekleyebilir; böylece bunlar kuyruk çifti arasında geri sıçramaz, ancak bileşik desen için teslim edilemeyen ileti kuyruğu işlevi gören yardımcı bir kuyruğa gönderilir.
Bu düzen, en önemli endişenin tüketicilerin veya tüketicilerin güvendiği kaynaklardaki kullanılabilirlik sorunlarına karşı savunmak ve eşleştirilmiş kuyruklardan birinde trafik artışlarını yeniden dağıtmak olduğu senaryolar için uygundur. Ayrıca, tüketicilerin her iki kuyruktan da okuması durumunda ad alanlarının birinin kullanılamaz duruma gelmesine karşı koruma sağlar, ancak süre sonu tarafından
TimeToLiveuygulanan çoğaltma gecikmesi, bu zaman penceresindeki iletilerin kullanılamayan ad alanında kalmasına neden olabilir.
Gecikme süresini iyileştirme
Konular, bilgileri birden çok tüketiciye dağıtmak için kullanılır. Bazı durumlarda, özellikle geniş coğrafi dağıtıma sahip tüketiciler, bir konu başlığındaki iletileri tüketicilere daha yakın ikincil bir ad alanında bir konuya çoğaltmak yararlı olabilir.
Örneğin, bölgesel ve kıtasal hub'lar arasında veri paylaşırken, bilgileri hub'lar arasında yalnızca bir kez aktarmak ve tüketicilerin bu hub'lardan veri kopyalarını almalarını sağlamak daha verimlidir.
Çoğaltma aktarımları toplu olarak gerçekleştirilebilir ve tüketiciler genellikle iletileri tek tek alır ve yerleştirebilir. örneğin, Kuzey Amerika ile Avrupa arasında 100 ms'lik temel ağ gecikme süresiyle, her iletinin iletileri almak ve ayarlamak için uzak bir varlığa yapılan iki gidiş dönüş için işlenmesi 200 ms daha uzun sürer ve aynı bölgedeki bir varlığa kıyasla.
Doğrulama, azaltma ve zenginleştirme
İletiler, kendi çözümünüz dışındaki istemciler tarafından bir Service Bus kuyruğuna veya konusuna gönderilebilir.
Bu tür iletiler, belirli bir şemayla uyumluluğun denetlenmesi ve uyumlu olmayan iletilerin bırakılması veya teslim edilmemesi gerekebilir. Bazı iletilerin veri çıkarılarak karmaşıklığının azaltılması ve bazılarının başvuru veri aramalarına göre veri eklenerek zenginleştirilmesi gerekebilir. İşlemler, çoğaltma görevinde özel işlevlerle gerçekleştirilebilir.
Kuyruğa Akış Çoğaltma
Azure Event Hubs, aşırı hacimli gelen olayları işlemek için ideal bir çözümdür. Ancak ne Event Hubs ne de Apache Kafka gibi benzer altyapılar, birden çok tüketicinin yinelenen işleme riski olmadan aynı kaynaktan gelen iletileri eşzamanlı olarak işleyebildiği ve son olarak bu iletileri işlendikten sonra çözebildiği, hizmet tarafından yönetilen rakip bir tüketici modeli sağlamaz.
Kuyruğa çoğaltma akışı, tek bir Olay Hub'ı bölümünün veya tam Bir Olay Hub'ının içeriğini, iletilerin güvenli, işlemsel ve rakip tüketicilerle birlikte işlenebileceği bir Service Bus kuyruğuna aktarır. Bu çoğaltma ayrıca konu başlıklarıyla yönlendirme ve oturum tabanlı ayrıştırma dahil olmak üzere bu iletiler için diğer tüm Service Bus özelliklerinin kullanılmasını sağlar.
Birleştirme ve normalleştirme
Küresel çözümler genellikle kendi işleme özelliklerine sahip olmak da dahil olmak üzere büyük ölçüde bağımsız bölgesel ayak izlerinden oluşur, ancak supra-bölgesel ve küresel perspektifler veri tümleştirmesi ve dolayısıyla yerel perspektif için ilgili bölgesel ayak izinde değerlendirilen aynı ileti verilerinin merkezi bir şekilde birleştirilmesini gerektirir.
Normalleştirme, iki veya daha fazla gelen ileti dizisinin aynı türde bilgileri taşıdığı ancak farklı yapılar veya farklı kodlamalarla birlikte iletinin kullanılabilmesi için önce dönüştürülmesi veya dönüştürülmesi gereken birleştirme senaryosunun bir türüdür.
Normalleştirme, uçtan uca şifrelenmiş yüklerin şifresini çözme ve aşağı akış tüketici kitlesi için farklı anahtarlar ve algoritmalarla yeniden şifreleme gibi şifreleme çalışmalarını da içerebilir.
Bölme ve yönlendirme
Service Bus konuları ve abonelik kuralları genellikle belirli bir hedef kitlenin ileti akışını filtrelemek için kullanılır ve bu hedef kitle filtrelenmiş kümeyi bir abonelikten alır.
Bu iletilerin hedef kitlesinin genel olarak dağıtıldığı veya farklı uygulamalara ait olduğu genel bir sistemde çoğaltma, böyle bir abonelikteki iletileri kullanıldıkları farklı bir ad alanında bulunan bir kuyruğa veya konuya aktarmak için kullanılabilir.
Azure İşlevleri'de çoğaltma uygulamaları
Yukarıdaki desenlerin uygulanması, yapılandırmak ve çalıştırmak istediğiniz çoğaltma görevleri için ölçeklenebilir ve güvenilir bir yürütme ortamı gerektirir. Azure'da durum bilgisi olmayan görevler için en uygun çalışma zamanı ortamı Azure İşlevleri.
Azure İşlevleri, çoğaltma görevleri, çoğaltma yolu boyunca gizli dizileri yönetmek zorunda kalmadan kaynak ve hedef hizmetlerin rol tabanlı erişim denetimi kurallarıyla tümleştirilebileceği şekilde Azure tarafından yönetilen bir kimlik altında çalıştırılabilir. Açık kimlik bilgileri gerektiren çoğaltma kaynakları ve hedefleri için Azure İşlevleri, bu kimlik bilgilerinin yapılandırma değerlerini Azure Key Vault içinde sıkı erişim denetimli depolama alanında tutabilir.
Azure İşlevleri ayrıca çoğaltma görevlerinin tüm Azure mesajlaşma hizmetleri için Azure sanal ağları ve hizmet uç noktalarıyla doğrudan tümleştirilmesine olanak tanır ve Azure İzleyici ile kolayca tümleştirilir.
En önemlisi, Azure İşlevleri Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid ve Azure Kuyruk Depolama için önceden oluşturulmuş, ölçeklenebilir tetikleyiciler ve çıkış bağlamaları vardır. RabbitMQ ve Apache Kafka için özel uzantılar. Tetikleyicilerin çoğu, belgelenen ölçümlere göre eşzamanlı olarak yürütülen örneklerin sayısını artırıp azaltarak aktarım hızı gereksinimlerine dinamik olarak uyarlanır.
Azure İşlevleri tüketim planıyla, önceden oluşturulmuş tetikleyiciler çoğaltma için kullanılabilir ileti olmadığında ölçeği sıfıra düşürebilir ve bu da yapılandırmanın ölçeğini artırmaya hazır tutmanın hiçbir maliyeti olmadığı anlamına gelir. Tüketim planını kullanmanın en önemli dezavantajı, çoğaltma görevlerinin bu durumdan "uyanması" için gecikme süresinin altyapının çalışmaya devam ettiği barındırma planlarından önemli ölçüde daha yüksek olmasıdır.
Tüm bunların aksine, Apache Kafka'nın MirrorMaker'ı gibi mesajlaşma ve olay oluşturma için en yaygın çoğaltma altyapıları bir barındırma ortamı sağlamanızı ve çoğaltma altyapısını kendiniz ölçeklendirmenizi gerektirir. Bu, güvenlik ve ağ özelliklerini yapılandırmayı ve tümleştirmeyi ve izleme verilerinin akışını kolaylaştırmayı içerir ve sonra da akışa özel çoğaltma görevleri ekleme fırsatınız olmaz.
Azure Logic Apps ile çoğaltma görevleri
İşlevler'i kullanarak çoğaltma yapmanın kodlama dışı bir alternatifi , bunun yerine Logic Apps kullanmaktır. Logic Apps'in Service Bus için önceden tanımlanmış çoğaltma görevleri vardır. Bunlar farklı örnekler arasında çoğaltmayı ayarlamaya yardımcı olabilir ve daha fazla özelleştirme için ayarlanabilir.
Sonraki Adımlar
Bu makalede bir dizi federasyon desenini inceledik ve Azure İşlevleri Azure'da olay ve mesajlaşma çoğaltma çalışma zamanı olarak rolünü açıkladık.
Ardından, Azure İşlevleri ile bir çoğaltıcı uygulamasını ayarlamayı ve ardından Event Hubs ile diğer çeşitli olay ve mesajlaşma sistemleri arasında olay akışlarını çoğaltmayı okumak isteyebilirsiniz: