İleti çoğaltma ve bölgeler arası federasyon
Ad alanları içinde Azure Service Bus, çeşitli yönlendirme desenlerinin uygulanmasına olanak sağlamak 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ı tutar ve kuyruklar ve Konular arasında iletileri çoğaltır 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 istemenize neden olabilecek 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ı koruması ve aracının iletilerin rakip tüketiciler arasında adil bir şekilde dağıtılması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ış bu tür bir kuyruk, yalnızca iletilerin değil, iletilerin tüketicilere sunulmadan önce her iletinin teslim durumunun da tam olarak 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üşterilerinin sahip olduğu temel hedefle doğrudan çakışmaktır: Çözümleri için en yüksek kullanılabilirlik ve güvenilirlik.
Bu nedenle burada sunulan desenler kullanılabilirlik ve güvenilirlik odaklıdır ve aynı zamanda hem bilgi kaybından hem de iletilerin yinelenen işlenmesinden en iyi şekilde kaçınmayı hedefler.
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, ağ veya ad çözümleme sorunları nedeniyle üreticinin veya tüketicinin atanmış "birincil" Service Bus ile konuşmasının engellenmesi ya da Service Bus varlığının gerçekten geçici olarak yanıt vermemesi veya hata döndürmesi gibi 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 havalimanları 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 ve farklı bir bölgedeki ikincil uç noktaya ulaşılabilmesi mümkündür. 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ın birçok pratik örneği vardır. Bunlar arasında perakende sitelerindeki ödemelerin işlenmesi, havaalanı kapılarında biniş ve restoranlarda cep telefonu siparişleri yer alır ve bunların hepsi anında gerçekleşir ve güvenilir iletişim yolu mevcut olmadığı zaman tam beklemede kalır.
Bu kategoride üç ayrı dağıtılmış desenden bahsedeceğiz: "tümü etkin" çoğaltma, "etkin-pasif" çoğaltma ve "taşma" çoğaltması.
Tümü Etkin Çoğaltma
"Tümü etkin" ç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) kullanılabilir olmasını ve tüm iletilerin nerede sıralandıklarından bağımsız olarak tüm çoğaltmalarda kullanılabilir olmasını 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 biri, iletilerin çoğaltılacağı diğer konulardan herhangi biri için bir "çoğaltma aboneliğine" sahiptir. Yukarıdaki çizimde yalnızca bir konu çifti 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 olur.
Her çoğaltma aboneliğinde SQL filtre ifadesini () ve SQL eylemini (replicated <> 1) 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 seçili her iletideki değere 1 tam olarak ayarlar. Bunun etkisi, ileti ilgili konuya kopyalandığında, artık ters yönde çoğaltma için uygun olmaması ve bu nedenle iletilerin çoğaltmalar arasında sıçramasını önlememizdir.
İ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 başlığı, tüm tüketicilerin paylaştığı yalnızca 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ı konu başlıklarının her birine yerleştirir. Bu, her bölgedeki uygulama kodunuzun tüm iletileri göreceği ve işleyecek olduğu anlamına gelir. Bu düzen, verilerin birden çok bölgede paylaşıldığı veya genellikle yedekli işlemenin istendiği senaryolar için uygundur. Her iletiyi normal kuyrukta olduğu gibi yalnızca bir kez işlemeniz gerekiyorsa, aşağıdaki iki desenden birini göz önünde bulundurmanız gerekir.
Etkin-Pasif Çoğaltma
"Etkin-pasif" çoğaltma deseni, uygulama tarafından ileti göndermek ve almak için uygulama tarafından etkin olarak kullanılan ve birincil konunun kullanılamadığı veya ulaşılamaması durumunda ikincil bir konuya çoğaltıldığı önceki desenin çeşitlemesidir.
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 yol açacağı beklenen süreyi yansıtan bir süreye ayarlanır. Örneğin, kullanım örneği senaryonuz, birincil başlangıçtan iletilerin alınmasının sorunları gösterdiği en fazla 1 dakika içinde tüketicinin ikincil öğeye 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. Çoğaltma sırasında (set sys.TimeToLive = '0:2:0'kural eyleminde) bu sürenin TimeToLive iki katı olan 2 dakika olarak ayarlarsak, 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 kullanım örneğine ve hızlı bir şekilde istediğinize bağlıdır ve uygulamanızdaki ikincil süreye geçebilir. Ayar TimeToLive , birkaç saniye ile gün arasında kabul edilir.
Uygulama ikincilini kullanırken, doğrudan ikincil konuya da yayımlayabilir ve bu da normal bir konu gibi davranır. Bu nedenle, ikincil geçiş sonrasında tüketici çoğaltılmış iletilerin ve doğrudan ikincil iletide yayımlanan iletilerin bir karışımını görür. Bu nedenle, uygulama önce yayımlamayı birincile geri döndürmelidir ve yine de tüketiciyi ikincilye geri döndürmeden önce yerel olarak yayımlanan iletilerin boşaltılmasına izin vermelidir. Birincil yeniden kullanılabilir duruma geldikten sonra çoğaltmanın otomatik olarak devam ettirilmesi nedeniyle, tüketici bu süre boyunca biraz daha yüksek gecikme süresine sahip olsa da birincilde yayımlanan yeni iletiler de alabilir.
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 yeniden geçiş yaparken 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
MessageIdbir ölçütü olmalı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 verebilmesi gerekir.
Taşma Çoğaltması
"Taşma" çoğaltma düzeni, Service Bus'ın iyi durumda olduğu, ancak tüketicinin bekleyen ileti sayısıyla boğulduğu veya doğrudan 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 iki ad alanı paralel olarak kullanılır ve her biri genel ileti trafiğinin bir alt kümesini alır ve ilişkili tüketicileri bu alt kümeyi işler. 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ğunda teslim edilemeyen ileti kuyruğuna eklenir. Çoğaltma görevleri daha sonra bunları alır ve eşleştirilmiş kuyrukta yeniden kuyruğa alır ve daha sonra kabul edilebilir 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 tarafından hala zamanında gerçekleşebileceği şekilde ayarlanmalıdır; örneğin TimeToLive izin verilen sürenin yarısına ayarlanabilir.
Tüm etkin desende olduğu gibi, uygulama iletiye iletinin bir kez çoğaltılıp çoğaltılmadığını, kuyruk çifti arasında geri dönen değil, bileşik desen için teslim edilemeyen ileti kuyruğu işlevi gören bir yardımcı kuyruğa gönderilip gönderilmediğinin göstergesini ekleyebilir.
Bu düzen, tüketicilerin veya tüketicilerin güvendiği kaynaklarda kullanılabilirlik sorunlarına karşı savunmak ve aynı zamanda eşleştirilmiş kuyruklardan birinde trafik artışlarını yeniden dağıtmak olan senaryolar için uygundur. Ayrıca, tüketiciler her iki kuyruktan da okursa 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 konudaki iletileri tüketicilere daha yakın ikincil bir ad alanında bir konuya çoğaltmak yararlı olabilir.
Örneğin, bölgesel ve kıtasal merkezler arasında veri paylaşırken, bilgileri yalnızca bir kez hub'lar arasında aktarmak ve tüketicilerin bu hub'lardan veri kopyalarını almalarını sağlamak daha verimlidir.
Çoğaltma aktarımları toplu olarak yapılabilir 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 uzak bir varlığa ileti almak ve ayarlamak için iki gidiş dönüş için işlenmesi, aynı bölgedeki bir varlığa kıyasla 200 ms daha uzun sürer.
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ışLa Ç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şlenebildiği bir Service Bus kuyruğuna aktarır. Bu çoğaltma ayrıca konu başlıklarıyla yönlendirme ve oturum tabanlı çözümleme dahil olmak üzere bu iletiler için diğer tüm Service Bus özelliklerinin kullanılmasını sağlar.
Birleştirme ve normalleştirme
Genel çö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 izlerinde değerlendirilen aynı ileti verilerinin merkezi bir şekilde birleştirilmesini gerektirir.
Normalleştirme, iki veya daha fazla gelen ileti dizisinin aynı tür bilgileri taşıdığı, ancak farklı yapılarla veya farklı kodlamalarla birlikte iletilerin kullanılabilmesi için önce kodlanması veya dönüştürülmesi gereken birleştirme senaryosunun bir çeşididir.
Normalleştirme ayrıca 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ı yerden farklı bir ad alanında bulunan bir kuyruğa veya konuya aktarmak için kullanılabilir.
Azure İşlevleri ç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ştirilebilen Azure yönetilen kimliği. 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'un 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ı, RabbitMQ için özel uzantılar ve Apache Kafka'ya sahiptir. 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 tutmak için herhangi bir ücret ödemediğiniz 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ışır durumda tutulduğu barındırma planlarından önemli ölçüde 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. Buna güvenlik ve ağ özelliklerini yapılandırma ve tümleştirme ile izleme verilerinin akışını kolaylaştırma dahildir ve ardından 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,Service Bus için önceden tanımlanmış çoğaltma görevlerine sahiptir. 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: