Çok siteli ve çok bölgeli federasyon
Birçok gelişmiş çözüm, aynı olay akışlarının birden çok konumda kullanıma sunulmasını veya olay akışlarının birden çok konumda toplanması ve ardından belirli bir tüketim konumunda birleştirilmesini gerektirir. Ayrıca genellikle tek bir bölge ve çözüm içinde de olay akışlarını zenginleştirme veya azaltma ya da olay biçimi dönüştürmeleri gerçekleştirme gereksinimi vardır.
Pratik olarak bu, çözümünüz genellikle farklı bölgelerde ve Event Hubs ad alanında birden çok Event Hubs barındıracağı ve ardından olayları bunlar arasında çoğaltacağı anlamına gelir. Ayrıca olayları Azure Service Bus, Azure IoT Hub veya Apache Kafka gibi kaynak ve hedeflerle de değiştirebilirsiniz.
Farklı bölgelerde birden çok etkin Event Hub'ın korunması, istemcilerin içerikleri birleştiriliyorsa bunları seçip aralarında geçiş yapmasına da olanak tanır ve bu da sistemin genel olarak bölgesel kullanılabilirlik sorunlarına karşı daha dayanıklı olmasını sağlar.
Bu "Federasyon" bölümünde federasyon desenleri ve bu desenlerin sunucusuz Azure Stream Analytics veya Azure İşlevleri çalışma zamanlarını kullanarak nasıl gerçekleştireceğiniz açıklanır ve doğrudan olay akışı yolunda kendi dönüştürme veya zenginleştirme kodunuz olabilir.
Federasyon Desenleri
Olayları farklı Event Hub'lar veya diğer kaynaklar ve hedefler arasında taşımak istemeniz için birçok olası motivasyon vardır ve bu bölümdeki en önemli desenleri sıralar ve ilgili desen için daha ayrıntılı yönergelere bağlantı sağlarız.
- Bölgesel kullanılabilirlik olaylarına karşı dayanıklılık
- Gecikme süresini iyileştirme
- Doğrulama, azaltma ve zenginleştirme
- Analiz hizmetleriyle tümleştirme
- Olay akışlarını birleştirme ve normalleştirme
- Olay akışlarını bölme ve yönlendirme
- Günlük projeksiyonları
Bölgesel kullanılabilirlik olaylarına karşı dayanıklılık
Event Hubs için en yüksek kullanılabilirlik ve güvenilirlik en önemli operasyonel öncelikler olsa da, ağ veya ad çözümleme sorunları nedeniyle üretici veya tüketicinin atanmış "birincil" Event Hubs ile konuşmasının engellenmesi ya da Event Hubs'ın gerçekten geçici olarak yanıt vermemesi veya hatalar döndürmesi gibi birçok yol vardır.
Olağanüstü durum kurtarma durumunda yaptığınız 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ç dakika hatta saniyeyi geçmeyecek kullanılabilirlik olaylarından etkilenmiş olabilir.
Bu tür senaryoları ele almak için iki temel desen vardır:
- Çoğaltma düzeni, birincil Event Hubs'ın içeriğini ikincil bir Event Hubs'a çoğaltmaktır. Burada birincil Event Hubs genellikle uygulama tarafından olayları üretmek ve kullanmak için kullanılır ve birincil Event Hubs kullanılamaz hale gelirse ikincil bir geri dönüş seçeneği olarak görev alır. Çoğaltma birincilden ikincile tek yönlü olduğundan, hem üreticilerin hem de tüketicilerin kullanılamayan birincilden ikincile geçişi eski birincilin artık yeni olayları almamasına neden olur ve bu nedenle artık geçerli olmaz. Bu nedenle yalnızca tek yönlü yük devretme senaryoları için saf çoğaltma uygundur. Yük devretme gerçekleştirildikten sonra eski birincil terk edilir ve farklı bir hedef bölgede yeni bir ikincil Event Hubs oluşturulması gerekir.
- Birleştirme düzeni, iki veya daha fazla Event Hubs içeriğinin sürekli birleştirilmesini gerçekleştirerek çoğaltma desenini genişletir. Başlangıçta şemaya dahil edilen Event Hubs'lardan birinde üretilen her olay diğer Event Hubs'a çoğaltılır. Olaylar çoğaltılırken, daha sonra çoğaltma hedefinin çoğaltma işlemi tarafından yoksayılması için bunlara açıklama eklenir. Birleştirme desenini kullanmanın sonuçları, sonunda tutarlı bir şekilde aynı olay kümesini içerecek iki veya daha fazla Event Hub'dır.
Her iki durumda da Event Hubs içeriği aynı olmaz. Herhangi bir üreticiden gelen ve aynı bölüm anahtarına göre gruplandırılmış olaylar başlangıçta gönderilenle aynı göreli sırada görünür, ancak olayların mutlak sırası farklı olabilir. Bu durum özellikle kaynak ve hedef Event Hubs'ın bölüm sayısının farklı olduğu senaryolar için geçerlidir ve bu durum burada açıklanan genişletilmiş desenlerin birkaçı için tercih edilir. Bir bölücü veya yönlendirici, yüzlerce bölüme ve huniye sahip çok daha büyük bir Event Hubs dilimini, yalnızca birkaç bölümü olan daha küçük bir Event Hubs'a alabilir ve alt kümeyi sınırlı işleme kaynaklarıyla işlemeye daha uygundur. Buna karşılık bir birleştirme işlemi, birkaç küçük Event Hubs'daki verileri birleştirilmiş aktarım hızı ve işleme gereksinimleriyle başa çıkmak için daha fazla bölüme sahip tek ve daha büyük bir Event Hubs'a dönüştürebilir.
Olayları bir arada tutma ölçütü, özgün bölüm kimliği değil bölüm anahtarıdır. Göreli sıra ve aynı akış uzaklıkları kapsamına bağlı kalmadan bir Event Hubs'dan diğerine yük devretme gerçekleştirme hakkındaki diğer konular çoğaltma düzeni açıklamasında ele alınmalıdır.
Rehber -lik:
Gecikme süresini iyileştirme
Olay akışları üreticiler tarafından bir kez yazılır, ancak olay tüketicileri tarafından birkaç kez okunabilir. Bir bölgedeki olay akışının birden çok tüketici tarafından paylaşıldığı ve farklı bir bölgede bulunan analiz işlemesi sırasında tekrar tekrar erişilmesi gereken senaryolarda veya eş zamanlı tüketicilerin yetersiz kalmasına neden olacak tüm taleplerde, gidiş dönüş gecikme süresini azaltmak için olay akışının bir kopyasını analiz işlemcisinin yanına yerleştirmek yararlı olabilir.
Çoğaltmanın, bölgeler arasında olayları uzaktan tüketirken tercih edilmesi gereken durumlara iyi örnekler, özellikle de bölgelerin çok uzak olduğu bölgelerdir; örneğin Avrupa ve Avustralya neredeyse antipodlardır, coğrafi olarak ve ağ gecikmeleri herhangi bir gidiş dönüş için 250 ms'yi kolayca aşabilir. Işık hızını hızlandıramazsınız, ancak verilerle etkileşime geçmek için yüksek gecikmeli gidiş dönüş sayısını azaltabilirsiniz.
Rehber -lik:
Doğrulama, azaltma ve zenginleştirme
Olay akışları, kendi çözümünüz dışındaki istemciler tarafından bir Event Hubs'a gönderilebilir. Bu tür olay akışları, dışarıdan gönderilen olayların belirli bir şemayla uyumluluğunun denetlenmesi ve uyumlu olmayan olayların bırakılması gerektirebilir.
Bant genişliği ölçülen birçok "Nesnelerin İnterneti" senaryosunda olduğu gibi istemcilerin bant genişliğinin son derece kısıtlandığı veya olayların sınırlı paket boyutlarına sahip IP olmayan ağlar üzerinden gönderildiği senaryolarda, olayların aşağı akış olay işlemcileri tarafından kullanılabilir hale getirmek için başvuru verileriyle zenginleştirilmesi gerekebilir.
Diğer durumlarda, özellikle de akışlar birleştirilirken, olay verilerinin karmaşıklığı azaltılmış veya biraz ayrıntı atlanarak daha büyük bir boyuta sahip olması gerekebilir.
Bu işlemlerden herhangi biri çoğaltma, birleştirme veya birleştirme akışlarının bir parçası olarak gerçekleşebilir.
Rehber -lik:
Analiz hizmetleriyle tümleştirme
Azure Stream Analytics veya Azure Synapse gibi Azure'ın buluta özel analiz hizmetlerinin çoğu, Azure Event Hubs sunulan akışlı veya önceden toplu verilerle en iyi şekilde çalışır ve Azure Event Hubs Apache Samza, Apache Flink, Apache Spark ve Apache Storm gibi çeşitli açık kaynak analiz paketleriyle tümleştirme sağlar.
Çözümünüz öncelikli olarak Service Bus veya Event Grid kullanıyorsa, bu olayları bu tür analiz sistemleri için ve ayrıca Event Hubs'a hunilerseniz Event Hubs Capture ile arşivleme için kolayca erişilebilir hale getirebilirsiniz. Event Grid bunu Event Hubs tümleştirmesiyle yerel olarak yapabilir. Service Bus için Service Bus çoğaltma yönergelerini izlersiniz.
Azure Stream Analytics , Event Hubs ile doğrudan tümleşir.
Rehber -lik:
Olay akışlarını birleştirme ve normalleştirme
Küresel çözümler genellikle kendi analiz özelliklerine sahip olmak da dahil olmak üzere büyük ölçüde bağımsız bölgesel ayak izinden oluşur, ancak supra-bölgesel ve küresel analiz perspektifleri tümleşik bir perspektif gerektirir ve bu nedenle yerel perspektif için ilgili bölgesel ayak izlerinde değerlendirilen aynı olay akışlarının merkezi birleştirilmesi gerekir.
Normalleştirme, iki veya daha fazla gelen olay akışının aynı tür olayları taşıdığı, ancak farklı yapılarda veya farklı kodlamalarda olduğu ve olayların tüketilmeden önce en çok dönüştürüldüğü veya dönüştürüldüğü birleştirme senaryosunun bir özelliğidir.
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.
Rehber -lik:
Olay akışlarını bölme ve yönlendirme
Azure Event Hubs, alınan olayların gelen bir torrentinin Azure Service Bus veya Azure Event Grid kapasitesini çok aştığı ve her ikisi de yerel yayımlama-abone ol filtreleme ve dağıtım özelliklerine sahip olan ve bu desen için tercih edilen "publish-subscribe" stili senaryolarda bazen kullanılır.
Gerçek bir "yayımla-abone ol" özelliği abonelerin istedikleri olayları seçmesini sağlarken, bölme düzeninde üretici olayları önceden belirlenmiş bir dağıtım modeliyle bölümlere eşler ve belirlenen tüketiciler daha sonra yalnızca "kendi" bölümünden çeker. Event Hubs genel trafiği arabelleğe alırsa, özgün aktarım hızı hacminin bir bölümünü temsil eden belirli bir bölümün içeriği güvenilir, işlemsel ve rakip tüketici tüketimi için bir kuyruğa çoğaltılabilir.
Event Hubs'ın öncelikli olarak bir bölgedeki bir uygulama içindeki olayları taşımak için kullanıldığı birçok senaryoda, yalnızca tek bir bölümden gelen belirli olayların başka bir yerde de kullanılabilir duruma getirilmesi gerekir. Bu senaryo bölme senaryosuna benzer, ancak bir Event Hubs'a gelen tüm iletileri dikkate alan ve ileriye doğru yönlendirme için yalnızca birkaç tane seçen ve yönlendirme hedeflerini olay meta verilerine veya içeriğe göre ayırt eden ölçeklenebilir bir yönlendirici kullanabilir.
Rehber -lik:
Günlük projeksiyonları
Bazı senaryolarda, bir olayın herhangi bir alt akışı için gönderilen ve genellikle bölüm anahtarıyla ayırt edilen en son değere erişim sahibi olmak istersiniz. Apache Kafka'da bu genellikle herhangi bir benzersiz anahtarla etiketlenmiş en son olayı atan bir konuda "günlük sıkıştırma" etkinleştirilerek gerçekleştirilir. Günlük sıkıştırma yaklaşımının üç bileşik dezavantajı vardır:
- Sıkıştırma, günlüğün sürekli olarak yeniden düzenlenmesini gerektirir. Bu, yalnızca ekleme iş yükleri için iyileştirilmiş bir aracı için aşırı pahalı bir işlemdir.
- Sıkıştırma yıkıcıdır ve aynı akışın sıkıştırılmış ve sıkıştırılmamış bir perspektife izin vermez.
- Sıkıştırılmış akışın hala sıralı erişim modeli vardır; başka bir deyişle günlükte istenen değeri bulmak için en kötü durumda günlüğün tamamının okunması gerekir ve bu da genellikle burada sunulan tam deseni uygulayan iyileştirmelere yol açar: günlük içeriğini bir veritabanına veya önbelleğe yansıtma.
Sonuç olarak, sıkıştırılmış günlük bir anahtar-değer deposudur ve bu nedenle, bu tür bir depo için mümkün olan en kötü uygulama seçeneğidir. Aramalar ve sorguların günlüğün düzgün bir anahtar-değer deposuna veya başka bir veritabanına kalıcı bir yansıtması oluşturup kullanması çok daha verimlidir.
Olaylar sabit olduğundan ve sıra her zaman bir günlükte korunduğu için, bir günlüğün anahtar-değer deposuna yansıtılması her zaman aynı olay aralığı için aynı olacaktır; yani güncel tuttuğunuz bir projeksiyon her zaman yetkili bir görünüm sağlar ve oluşturulduktan sonra günlük içeriğinden yeniden oluşturmak için hiçbir zaman iyi bir neden yoktur.
Rehber -lik:
Çoğaltma uygulama teknolojileri
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 bu tür görevler için en uygun çalışma zamanı ortamları durum bilgisi olmayan görevlerdir. Durum bilgisi olan akış çoğaltma görevleri için Azure Stream Analytics ve durum bilgisi olmayan çoğaltma görevleri için Azure İşlevleri.
Azure Stream Analytics'te durum bilgisi olan çoğaltma uygulamaları
Olaylar arasındaki ilişkileri göz önünde bulundurması, bileşik olaylar oluşturması, olayları zenginleştirmesi veya azaltması, veri toplamaları oluşturması ve olay yüklerini dönüştürmesi gereken durum bilgisi olan çoğaltma uygulamaları için Azure Stream Analytics en iyi uygulama seçeneğidir.
Azure Stream Analytics'te girişleri ve çıkışları tümleştirip girişlerdeki verileri sorgular aracılığıyla tümleştirerek çıkışlarda kullanılabilir hale gelen bir sonuç elde eden işler oluşturursunuz.
Sorgular SQL sorgu dilini temel alır ve akış verilerini belirli bir süre boyunca kolayca filtrelemek, sıralamak, toplamak ve birleştirmek için kullanılabilir. Bu SQL dilini JavaScript ve C# kullanıcı tanımlı işlevler (UDF) ile de genişletebilirsiniz. Basit dil yapıları ve/veya yapılandırmaları aracılığıyla toplama işlemleri gerçekleştirirken olay sıralama seçeneklerini ve zaman pencerelerinin süresini kolayca ayarlayabilirsiniz.
Her işin dönüştürülen veriler için bir veya birkaç çıkışı vardır ve analiz ettiğiniz bilgilere yanıt olarak ne olacağını denetleyebilirsiniz. Örneğin, şunları yapabilirsiniz:
- İletişimleri veya özel iş akışlarını tetikleme amacıyla Azure İşlevleri, Service Bus Konuları veya Kuyruklar gibi hizmetlere veri gönderin.
- Gerçek zamanlı pano oluşturmak için power BI panosuna veri gönderme.
- Toplu analiz gerçekleştirmek veya çok büyük, dizinlenmiş geçmiş veri havuzlarını temel alan makine öğrenmesi modellerini eğitmek için verileri diğer Azure depolama hizmetlerinde (örneğin, Azure Data Lake, Azure Synapse Analytics vb.) depolayın.
- Projeksiyonları ("gerçekleştirilmiş görünümler" olarak da adlandırılır) veritabanlarında (SQL Veritabanı, Azure Cosmos DB) depolayın.
Azure İşlevleri'da durum bilgisi olmayan çoğaltma uygulamaları
Olayları yüklerini dikkate almadan iletmek istediğiniz veya olayların ilişkilerini (göreli düzenleri dışında) dikkate almak zorunda kalmadan tek tek işleyen durum bilgisi olmayan çoğaltma görevleri için, çok büyük esneklik sağlayan Azure İşlevleri kullanabilirsiniz.
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ının yanı sıra özel RabbitMQ ve Apache Kafka için 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.
günlük projeksiyonları oluşturmak için Azure İşlevleri, Azure Cosmos DB ve Azure Tablo Depolama için çıkış bağlamalarını destekler.
Azure İşlevleri Bir Azure yönetilen kimliği altında çalışabilir ve bu kimlik bilgileri için 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.
Azure İşlevleri tüketim planıyla, önceden oluşturulmuş tetikleyiciler çoğaltma için kullanılabilir ileti yokken sıfıra kadar ölçeklendirilebilir, bu da yapılandırmayı ölçeği artırmaya hazır tutmanın bir maliyeti olmadığı anlamına gelir; tüketim planını kullanmanın temel 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 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 İşlevleri ile Azure Stream Analytics arasında seçim
Azure Stream Analytics (ASA), olayları çoğaltırken yüklerini işlemeniz gerektiğinde en iyi seçenektir. ASA olayları tek tek kopyalayabilir veya iletmeden önce olay akışlarının bilgilerini daraltan toplamalar oluşturabilir. Bu tür verileri akışa aktarmak zorunda kalmadan Azure Blob Depolama veya Azure SQL Veritabanında tutulan başvuru verilerini tamamlamaya kolayca dayanabilir.
ASA ile hiper ölçekli veritabanlarında akışların kalıcı, gerçekleştirilmiş görünümlerini kolayca oluşturabilirsiniz. Apache Kafka'nın clunky "log compaction" modeline ve Kafka Streams'in geçici, istemci tarafı tablo projeksiyonlarına çok daha üstün bir yaklaşımdır.
ASA yüklerin CSV, JSON ve Apache Avro biçimlerinde kodlanmış olduğu olayları kolayca işleyebilir ve diğer biçimler için özel seri durumdan çıkarıcıları takabilirsiniz.
Olay akışlarını "olduğu gibi" kopyalamak ve yüklere dokunmadan kopyalamak istediğiniz tüm çoğaltma görevleri için ya da yönlendirici uygulamanız, şifreleme çalışması yapmanız, yüklerin kodlamasını değiştirmeniz veya veri akışı içeriği üzerinde tam denetime ihtiyacınız varsa Azure İşlevleri en iyi seçenektir.
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 Stream Analytics veya 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: