Replikace zpráv a federace mezi oblastmi
V rámci oborů názvů Azure Service Bus podporuje vytváření topologií zřetězených front a odběrů témat pomocí automatického zřetězování, které umožňuje implementaci různých vzorů směrování. Partnerům můžete například poskytnout vyhrazené fronty, ke kterým mají oprávnění k odesílání nebo přijímání a které mohou být v případě potřeby dočasně pozastaveny, a pružně je připojit k jiným entitám, které jsou pro aplikaci soukromé. Můžete také vytvořit složité topologie vícefázového směrování nebo můžete vytvořit fronty ve stylu poštovní schránky, které vyčerpávají odběry témat podobných frontám a umožňují větší kapacitu úložiště na předplatitele.
Mnoho sofistikovaných řešení také vyžaduje, aby se zprávy replikovaly přes hranice oboru názvů, aby bylo možné implementovat tyto a další vzory. Zprávy můžou být potřeba protékat mezi obory názvů přidruženými k několika tenantům aplikací nebo napříč několika různými oblastmi Azure.
Vaše řešení bude udržovat několik oborů názvů služby Service Bus v různých oblastech a replikovat zprávy mezi frontami a tématy nebo že si budete vyměňovat zprávy se zdroji a cíli, jako jsou Azure Event Hubs, Azure IoT Hub nebo Apache Kafka.
Tento článek se zaměřuje na tyto scénáře.
Vzory federace
Existuje mnoho potenciálních motivací, proč můžete chtít přesouvat zprávy mezi entitami služby Service Bus, jako jsou fronty nebo témata, nebo mezi službou Service Bus a dalšími zdroji a cíli.
V porovnání s podobnou sadou vzorů pro službu Event Hubs je federace entit podobných frontám složitější, protože fronty zpráv slibují příjemcům výhradní vlastnictví nad libovolnou zprávou, očekává se, že zachová pořadí doručení při doručování zpráv a že zprostředkovatel bude koordinovat spravedlivé rozdělení zpráv mezi konkurenčními příjemci.
Existují praktické překážky, včetně omezení cap teorému, které ztěžují poskytování jednotného pohledu na frontu, která je současně dostupná ve více oblastech, a která umožňuje, aby regionálně distribuovaným a konkurenčním spotřebitelům umožnil převzít výhradní vlastnictví zpráv. Taková geograficky distribuovaná fronta by vyžadovala plně konzistentní replikaci nejen zpráv, ale také stavu doručení každé zprávy, aby bylo možné zprávy zpřístupnit příjemcům. Cíl úplné konzistence hypotetické, regionálně distribuované fronty je v přímém konfliktu s klíčovým cílem, který mají prakticky všichni Azure Service Bus zákazníci při zvažování scénářů federace: Maximální dostupnost a spolehlivost svých řešení.
Zde uvedené vzory se proto zaměřují na dostupnost a spolehlivost a zároveň se snaží co nejlépe zabránit ztrátě informací a duplicitnímu zpracování zpráv.
Odolnost proti událostem dostupnosti v jednotlivých oblastech
I když je maximální dostupnost a spolehlivost hlavní provozní prioritou služby Service Bus, existuje mnoho způsobů, jak může producent nebo příjemce zabránit tomu, aby komunikovali se svou přiřazenou "primární" službou Service Bus kvůli problémům se sítěmi nebo překladem názvů nebo kdy entita služby Service Bus může dočasně nereagovat nebo vracet chyby. Může také dojít k nedostupnosti určeného procesoru zpráv.
Takové podmínky nejsou "katastrofické", a proto byste chtěli úplně opustit regionální nasazení, jako je tomu v případě zotavení po havárii, ale obchodní scénář některých aplikací už může být ovlivněn událostmi dostupnosti, které netrvají déle než několik minut nebo i sekund. Azure Service Bus se často používá v hybridních cloudových prostředích a u klientů, kteří se nacházejí na hranici sítě, například v maloobchodních prodejnách, restauracích, pobočkách bank, výrobních lokalitách, logistických provozech a na letištích. Problém se směrováním nebo zahlcením sítě může mít vliv na schopnost jakékoli lokality dosáhnout přiřazeného koncového bodu služby Service Bus, zatímco sekundární koncový bod v jiné oblasti může být dostupný. Systémy zpracovávající zprávy přicházející z těchto lokalit zároveň můžou mít stále neomezený přístup k primárnímu i sekundárnímu koncovému bodu služby Service Bus.
Existuje mnoho praktických příkladů takových hybridních cloudových a hraničních aplikací s nízkou obchodní tolerancí k dopadu problémů se směrováním sítě nebo přechodným problémům s dostupností entity služby Service Bus. Mezi ně patří zpracování plateb v maloobchodních prodejnách, nástup u letištních bran a objednávky z mobilních telefonů v restauracích, z nichž všechny se okamžitě zastaví, kdykoli není k dispozici spolehlivá komunikační cesta.
V této kategorii probereme tři různé distribuované vzory: replikace "vše-aktivní", replikace "aktivní-pasivní" a replikace "přesahující přesah".
Replikace All-Active
Model replikace "vše aktivní" umožňuje, aby aktivní replika stejného logického tématu (nebo fronty) byla k dispozici ve více oborech názvů (a oblastech) a aby byly všechny zprávy dostupné ve všech replikách bez ohledu na to, kde byly zařazeny do fronty. Tento vzor obecně zachovává pořadí zpráv vzhledem k libovolnému vydavateli.
Jak je znázorněno na obrázku, vzor obecně vychází z témat služby Service Bus. Jedno téma pro každý obor názvů, který se má účastnit schématu replikace. Každé z těchto témat má jeden odběr replikace pro jakékoli další témata, do kterého se mají zprávy replikovat. Na obrázku výše máme jednoduše pár témat a tedy jeden odběr replikace pro příslušné další téma. Ve scénáři se třemi obory názvů {n1, n2, n3} by téma v oboru názvů n1 měla dva odběry replikace, jeden pro odpovídající téma v n2 a jeden pro odpovídající téma v n3.
Každý odběr replikace má pravidlo, které kombinuje výraz filtru SQL (replicated <> 1) a akci SQL (set replicated = 1). Filtr pravidla zajistí, že pouze zprávy, u kterých není nastavená vlastní vlastnost replication nebo nemá hodnotu 1 , budou způsobilé pro tento odběr a akce nastaví tuto vlastnost na hodnotu 1 u každé vybrané zprávy hned potom. Výsledkem je, že když se zpráva zkopíruje do odpovídajícího tématu, už není způsobilá k replikaci v opačném směru, a proto se vyhneme tomu, aby se zprávy mezi replikami poskakovaly.
Předplatné s příslušným pravidlem můžete snadno přidat do libovolného tématu pomocí Azure CLI, jako je tento.
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"
Při modelování fronty je každé téma omezeno pouze na jedno běžné předplatné (kromě předplatných replikace), které sdílejí všichni spotřebitelé.
Model replikace s veškerou aktivitou vloží kopii každé zprávy odeslané do libovolného tématu do každého z témat. To znamená, že kód aplikace v každé oblasti uvidí a zpracuje všechny zprávy. Tento model je vhodný pro scénáře, kdy se data sdílí do více oblastí, nebo pokud je obecně potřeba redundantní zpracování. Pokud potřebujete zpracovat každou zprávu jenom jednou, jako u běžné fronty, musíte zvážit jeden z následujících dvou vzorů.
Replikace Active-Passive
Vzor replikace "aktivní-pasivní" je variací předchozího vzoru, kdy aplikace k odesílání a přijímání zpráv aktivně používá pouze jedno z témat ("primární") a zprávy se replikují do sekundárního tématu v případě, že primární téma může být nedostupné nebo nedostupné.
Klíčovým rozdílem mezi tímto a předchozím vzorem je, že replikace je jednosměrná z primárního tématu do sekundárního tématu. Sekundární téma se nikdy nestane primárním, ale je to možnost zálohování, pokud je primární téma dočasně nepoužitelné.
Nevýhodou použití tohoto modelu je, že se snaží minimalizovat duplicitní zpracování. Během replikace TimeToLive je vlastnost message nastavena na dobu trvání replikovaných zpráv, která odráží očekávanou dobu, během které selhání primárního serveru povede k převzetí služeb při selhání. Pokud například váš scénář použití vyžaduje přechod příjemce na sekundárního uživatele do maximálně 1 minuty od okamžiku, kdy načítání zpráv z primárního počítače ukazuje problémy, sekundární by v ideálním případě měly mít k dispozici všechny zprávy, ke kterým jste neměli přístup v primární databázi, ale minimální počet zpráv, které jste už z primárního serveru zpracovali před tím, než se objevily problémy. Pokud během replikace ( v akci pravidla) nastavíme TimeToLive hodnotu na dvojnásobek tohoto období (set sys.TimeToLive = '0:2:0' 2 minuty), sekundární bude uchovávat zprávy pouze po dobu 2 minut a zahodí ty starší. To znamená, že když příjemce přepne na sekundární, může rychle přečíst a zahodit zprávy starší než poslední, které zpracoval, a pak zpracovat první zprávu, kterou ještě neviděl. Skutečná doba uchovávání bude záviset na konkrétním případu použití a na tom, jak rychle chcete a můžete ve své aplikaci přepnout na sekundární. Nastavení TimeToLive se respektuje v rozsahu od několika sekund až po dny.
Zatímco aplikace používá sekundární, může také publikovat přímo do sekundárního tématu, což pak funguje jako jakékoli běžné téma. Po přepnutí na sekundární proto příjemce uvidí kombinaci replikovaných zpráv a zpráv publikovaných přímo do sekundární. Aplikace by proto měla nejprve přepnout publikování zpět na primární a přesto umožnit vyprázdnění místně publikovaných zpráv před přepnutím příjemce zpět na sekundární. Vzhledem k tomu, že replikace se automaticky obnovuje, jakmile bude primární server opět k dispozici, příjemce by během této doby dostával také nové zprávy publikované na primárním serveru, i když s poněkud vyšší latencí.
Tento model je vhodný pro scénáře, kdy by se zprávy měly zpracovávat jenom jednou. Aplikace musí spolupracovat při sledování zpráv, které z primárního serveru zpracovala, protože najde duplicitní položky po dobu trvání časového intervalu převzetí služeb při selhání v sekundární databázi a při přepínání zpět znovu najde duplicitní položky. Kritériem odstranění duplicit by měla být nejlépe zadaná
MessageIdaplikace . HodnotaEnqueuedTimeUtcje také vhodná jako ukazatel meze, ale aplikace musí umožňovat určitý posun času (několik sekund) mezi primárním a sekundárním jako u jakéhokoli distribuovaného systému.
Replikace přesahu
Model replikace "přelití" umožňuje aktivní/aktivní použití několika entit služby Service Bus v několika oblastech, aby se vypořádal se scénářem, kdy je služba Service Bus v pořádku, ale příjemce se zahltí počtem čekajících zpráv nebo je přímo nedostupný. Důvodem může být to, že databáze podporující proces příjemce může být pomalá nebo nedostupná. Tento model funguje s prostými frontami a odběry témat.
Jak je znázorněno na obrázku, model replikace přesahujících dat replikuje zprávy z fronty nebo fronty nedoručených zpráv přidružených k odběru do spárované fronty nebo tématu v jiném oboru názvů.
Bez situace selhání se oba obory názvů používají paralelně, přičemž každý z nich přijímá určitou podmnožinu celkového provozu zpráv a jejich přidružení příjemci zpracovávající tuto podmnožinu. Jakmile jeden ze příjemců začne vykazovat vysokou míru selhání nebo se zastaví přímo, příslušné zprávy skončí ve frontě nedoručených zpráv buď překročením počtu doručení, nebo protože vyprší její platnost. Úlohy replikace je pak vyberou a znovu zadají do fronty ve spárované frontě, kde se pak předají předpokládanému příjemci, který je v pořádku.
Pokud zpracování musí proběhnout v určitém termínu, TimeToLive měla by být fronta a/nebo zprávy nastavená tak, aby zpracování mohlo stále probíhat v čase v sekundárním přelévání, například TimeToLive může být nastaveno na polovinu povoleného času.
Stejně jako u všech aktivních vzorů může aplikace do zprávy přidat indikátor, jestli už byla zpráva jednou replikována, aby se neodskakovala mezi jednotlivými frontami, ale byla odeslána do pomocné fronty, která funguje jako fronta nedoručených zpráv pro složený vzor.
Tento model je vhodný pro scénáře, kde je nejdůležitější bránit se problémům s dostupností u příjemců nebo prostředků, na které se příjemci spoléhají, a také redistribuovat špičky provozu v jedné ze spárovaných front. Poskytuje také ochranu před nedostupností jednoho z oborů názvů, pokud uživatelé čtou z obou front, ale prodleva replikace způsobená vypršením
TimeToLiveplatnosti může způsobit, že se zprávy v tomto časovém intervalu zobrazí v nedostupném oboru názvů.
Optimalizace latence
Témata se používají k distribuci informací více příjemcům. V některých případech, zejména u příjemců se širokou geografickou distribucí, může být užitečné replikovat zprávy z tématu do tématu v sekundárním oboru názvů blíže příjemcům.
Například při sdílení dat mezi regionálními a kontinentálními centry je efektivnější přenášet informace mezi centry pouze jednou a nechat uživatele získat kopii dat z těchto center.
Přenosy replikace se dají provádět v dávkách, které příjemci často získávají a vyřizují zprávy jeden po druhém. S latencí základní sítě mezi Severní Amerika a Evropou 100 ms trvá zpracování každé zprávy o 200 ms déle než dvě doby odezvy vzdálené entity za účelem získání a vypořádání zpráv v porovnání s entitou ve stejné oblasti.
Ověřování, redukce a rozšiřování
Zprávy můžou do fronty nebo tématu služby Service Bus odesílat klienti mimo vaše vlastní řešení.
Takové zprávy můžou vyžadovat kontrolu kompatibility s daným schématem a zahozených nebo nedoručených zpráv. Některé zprávy může být nutné omezit na složitost vynecháním dat a některé je nutné rozšířit přidáním dat na základě vyhledávání referenčních dat. Operace je možné provádět s vlastními funkcemi v úloze replikace.
Replikace streamu do fronty
Azure Event Hubs je ideálním řešením pro zpracování extrémních objemů příchozích událostí. Služba Event Hubs ani podobné moduly, jako je Apache Kafka, ale neposkytují model konkurenčních příjemců spravovaný službou, ve kterém může více příjemců zpracovávat zprávy ze stejného zdroje současně, aniž by riskovali duplicitní zpracování, a nakonec tyto zprávy po zpracování vyřídí.
Replikace datového proudu do fronty přenáší obsah jednoho oddílu centra událostí nebo obsahu úplného centra událostí do fronty Service Bus, odkud je možné zprávy zpracovávat bezpečně, transakčním způsobem a s konkurenčními příjemci. Tato replikace také umožňuje pro tyto zprávy používat všechny ostatní funkce služby Service Bus, včetně směrování s tématy a demultiplexu na základě relací.
Konsolidace a normalizace
Globální řešení se často skládají z regionální stopy, která jsou do značné míry nezávislá, včetně vlastních možností zpracování, ale nadregionální a globální perspektiva bude vyžadovat integraci dat, a tedy centrální konsolidaci stejných dat zpráv, která se vyhodnocují v příslušných regionálních stopách pro místní perspektivu.
Normalizace je příchuť scénáře konsolidace, kdy dvě nebo více příchozích sekvencí zpráv mají stejný druh informací, ale s různými strukturami nebo různými kódováními, a zprávy musí být před jejich spotřebou překódovány nebo transformovány.
Normalizace může také zahrnovat kryptografickou práci, jako je dešifrování komplexních šifrovaných datových částí a jejich opětovné šifrování pomocí různých klíčů a algoritmů pro cílovou skupinu podřízených uživatelů.
Rozdělení a směrování
Témata služby Service Bus a jejich pravidla odběru se často používají k filtrování streamu zpráv pro konkrétní cílovou skupinu a tato cílová skupina pak získala filtrovanou sadu z předplatného.
V globálním systému, kde je cílová skupina pro tyto zprávy globálně distribuovaná nebo patří do různých aplikací, lze replikaci použít k přenosu zpráv z takového odběru do fronty nebo tématu v jiném oboru názvů, než kde jsou spotřebovány.
Replikační aplikace v Azure Functions
Implementace výše uvedených vzorů vyžaduje škálovatelné a spolehlivé spouštěcí prostředí pro úlohy replikace, které chcete konfigurovat a spouštět. V Azure je prostředí runtime, které je nejvhodnější pro bezstavové úlohy, Azure Functions.
Azure Functions může běžet pod spravovanou identitou Azure, aby se úlohy replikace mohly integrovat s pravidly řízení přístupu na základě role zdrojových a cílových služeb, aniž byste museli spravovat tajné kódy v cestě replikace. V případě zdrojů a cílů replikace, které vyžadují explicitní přihlašovací údaje, můžou Azure Functions uchovávat hodnoty konfigurace těchto přihlašovacích údajů v úložišti s úzce řízeným přístupem uvnitř Azure Key Vault.
Azure Functions navíc umožňuje přímou integraci úloh replikace s virtuálními sítěmi a koncovými body služby Azure pro všechny služby zasílání zpráv Azure a je snadno integrovaná se službou Azure Monitor.
Nejdůležitější je, že Azure Functions má předem připravené škálovatelné triggery a výstupní vazby pro Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid a Azure Queue Storage. vlastní rozšíření pro RabbitMQ a Apache Kafka. Většina triggerů se dynamicky přizpůsobí potřebám propustnosti škálováním počtu souběžně spuštěných instancí nahoru a dolů na základě zdokumentovaných metrik.
S plánem Azure Functions Consumption můžou předem vytvořené triggery dokonce vertikálně snížit kapacitu na nulu, zatímco pro replikaci nejsou k dispozici žádné zprávy, což znamená, že se vám za udržování konfigurace připravené na vertikální navýšení kapacity neúčtují žádné náklady. Klíčovou nevýhodou použití plánu Consumption je, že latence úloh replikace, které se "probouzí" z tohoto stavu, je výrazně vyšší než u plánů hostování, ve kterých je infrastruktura stále spuštěná.
Na rozdíl od toho všeho většina běžných replikačních modulů pro zasílání zpráv a událostí, jako je mirrormaker Apache Kafka, vyžadují, abyste sami poskytli hostitelské prostředí a škálujte replikační modul. To zahrnuje konfiguraci a integraci funkcí zabezpečení a sítí a usnadnění toku dat monitorování a pak stále nemáte možnost vkládat do toku vlastní úlohy replikace.
Úlohy replikace s využitím Azure Logic Apps
Alternativou, která není kódováním k replikaci pomocí funkcí, by bylo místo toho použít Logic Apps . Logic Apps mají předdefinované úlohy replikace pro Service Bus. Ty můžou pomoct s nastavením replikace mezi různými instancemi a dají se upravit pro další přizpůsobení.
Další kroky
V tomto článku jsme prozkoumali řadu vzorů federace a vysvětlili roli Azure Functions jako modulu runtime replikace událostí a zasílání zpráv v Azure.
Dále si můžete přečíst, jak nastavit aplikaci replikátoru s Azure Functions a jak replikovat toky událostí mezi službou Event Hubs a různými dalšími systémy pro vytváření událostí a zasílání zpráv: