Sdílet prostřednictvím

Vzory úloh replikace zpráv

  • Článek

Přehled federace a funkce replikátoru vysvětlují odůvodnění a základní prvky úloh replikace a doporučuje se, abyste se s nimi seznámili, než budete pokračovat v tomto článku.

V tomto článku podrobně popisujeme pokyny k implementaci pro několik vzorů zvýrazněných v části Přehled.

Replikace

Vzor replikace kopíruje zprávy z jedné fronty nebo tématu do další nebo z fronty nebo tématu do jiného cíle, jako je centrum událostí. Zprávy se přeposílají bez jakýchkoli úprav datové části zprávy.

Implementace tohoto modelu je pokryta replikací zpráv do a z ukázky služby Azure Service Bus .

Sekvence a zachování pořadí

Model replikace nemá za cíl zachovat absolutní pořadí zpráv zdrojové fronty nebo tématu do cílové fronty nebo tématu, ale vždy se zaměřuje na zachování relativního pořadí zpráv, ve kterých ji aplikace vyžaduje. Aplikace to umožňuje povolením podpory relace pro zdrojovou entitu a seskupováním souvisejících zpráv se stejným klíčem relace.

Předdefinované funkce replikace pracující s relacemi zajišťují, že sekvence zpráv se stejným ID relace načtené ze zdrojové entity se odesílají do cílové fronty nebo tématu jako dávka v původní sekvenci a se stejným ID relace.

Metadata přiřazená službou

Metadata zprávy přiřazená službou získaná ze zdrojové fronty nebo tématu, původní fronta a pořadové číslo, jsou nahrazena novými hodnotami přiřazenými službou v cílové frontě nebo tématu, ale s výchozími úlohami replikace, které jsou uvedeny v našich ukázkách, původní hodnoty se zachovají ve vlastnostech uživatele: repl-enqueue-time (ISO8601 řetězec) a repl-sequence.

Tyto vlastnosti jsou typu řetězec a obsahují řetězcovou hodnotu odpovídajících původních vlastností. Pokud se zpráva předá vícekrát, metadata přiřazená službou bezprostředního zdroje se připojí k již existujícím vlastnostem s hodnotami oddělenými středníky.

Převzetí služeb při selhání

Pokud používáte replikaci pro účely zotavení po havárii, k ochraně před regionálními zprávami dostupnosti ve službě Service Bus nebo před přerušením sítě, bude každý takový scénář selhání vyžadovat převzetí služeb při selhání z jedné fronty nebo tématu do dalšího, který informuje producenty nebo uživatele, aby používali sekundární koncový bod.

U všech scénářů převzetí služeb při selhání se předpokládá, že požadované prvky oborů názvů jsou strukturálně identické, což znamená, že fronty a témata jsou identicky pojmenované a že pravidla sdíleného přístupového podpisu a/nebo pravidla řízení přístupu na základě role jsou nastavena stejným způsobem. Sekundární obor názvů můžete vytvořit (a aktualizovat) podle pokynů pro přesunutí oborů názvů a vynechání kroku vyčištění.

Pokud chcete výrobcům a příjemcům vynutit přepnutí, musíte nastavit informace o tom, který obor názvů má být dostupný pro vyhledávání v umístění, které je snadno dostupné a aktualizovat. Pokud producenti nebo spotřebitelé narazí na časté nebo trvalé chyby, měli by se poradit s tímto umístěním a upravit jejich konfiguraci. Konfigurace se dá sdílet mnoha způsoby, ale v následujících oblastech ukazujeme na dva: DNS a sdílené složky.

Konfigurace převzetí služeb při selhání založená na DNS

Jedním z kandidátských přístupů je uchovávat informace v záznamech DNS SRV v DNS, které řídíte, a odkazovat na příslušné koncové body fronty nebo tématu. Mějte na paměti, že služba Message Hubs neumožňuje přímé aliasování koncových bodů pomocí záznamů CNAME, což znamená, že dns použijete jako odolný vyhledávací mechanismus pro adresy koncových bodů a nebudete přímo překládat informace o IP adresách.

Předpokládejme, že doménu vlastníte example.com a pro vaši aplikaci zónu test.example.com. Pro dvě alternativní služby Service Bus teď vytvoříte dvě další vnořené zóny a v každém záznamU SRV.

Záznamy SRV mají následující běžnou konvenci s předponou _azure_servicebus._amqp a uchovávají dva záznamy koncových bodů: jeden pro protokol AMQP-over-TLS na portu 5671 a jeden pro AMQP-over-WebSockets na portu 443, oba odkazují na koncový bod služby Service Bus oboru názvů odpovídající zóně.

Zóna Záznam SRV
sb1.test.example.com _azure_servicebus._amqp.sb1.test.example.com
1 1 5671 sb1-test-example-com.servicebus.windows.net
2 2 443 sb1-test-example-com.servicebus.windows.net
sb2.test.example.com _azure_servicebus._amqp.sb1.test.example.com
1 1 5671 sb2-test-example-com.servicebus.windows.net
2 2 443 sb2-test-example-com.servicebus.windows.net

V zóně vaší aplikace pak vytvoříte položku CNAME, která odkazuje na podřízenou zónu odpovídající vaší primární frontě nebo tématu:

Záznam CNAME Alias
servicebus.test.example.com sb1.test.example.com

Pomocí klienta DNS, který umožňuje explicitně dotazovat záznamy CNAME a SRV (integrované klienty Javy a .NET umožňují pouze jednoduché překlady názvů na IP adresy), pak můžete přeložit požadovaný koncový bod. U DnsClient.NET je například vyhledávací funkce:

static string GetServiceBusName(string aliasName)
{
    const string SrvRecordPrefix = "_azure_servicebus._amqp.";
    LookupClient lookup = new LookupClient();

    return (from CNameRecord alias in (lookup.Query(aliasName, QueryType.CNAME).Answers)
            from SrvRecord srv in lookup.Query(SrvRecordPrefix + alias.CanonicalName, QueryType.SRV).Answers
            where srv.Port == 5671
            select srv.Target).FirstOrDefault()?.Value.TrimEnd('.');
}

Funkce vrátí cílový název hostitele zaregistrovaný pro port 5671 zóny, který je aktuálně aliasovaný pomocí CNAME, jak je znázorněno výše.

Provedení převzetí služeb při selhání vyžaduje úpravu záznamu CNAME a jeho nasměrování na alternativní zónu.

Výhodou použití DNS a konkrétně Azure DNS je, že se informace Azure DNS globálně replikují, a proto jsou odolné proti výpadkům v jedné oblasti.

Tento postup je podobný tomu, jak funguje geografická zotavení po havárii služby Service Bus, ale plně pod vaší vlastní kontrolou a funguje také s aktivními a aktivními scénáři.

Konfigurace převzetí služeb při selhání na základě sdílené složky

Nejjednodušší alternativou k použití DNS pro sdílení informací o koncovém bodu je vložení názvu primárního koncového bodu do souboru prostého textu a poskytování souboru z infrastruktury, která je robustní proti výpadkům a stále umožňuje aktualizace.

Pokud už spouštíte vysoce dostupnou infrastrukturu webu s globální dostupností a replikací obsahu, přidejte do ní takový soubor a znovu ho publikujte, pokud je potřeba přepnout.

Sloučení

Vzor sloučení obsahuje jeden nebo více úloh replikace odkazující na jeden cíl, případně současně s běžnými producenty, kteří také odesílají zprávy do stejného cíle.

Varianty tohoto modelu jsou:

  • Dvě nebo více funkcí replikace, které současně získávají zprávy z oddělených zdrojů a odesílají je do stejného cíle.
  • Jedna další funkce replikace, která získává zprávy ze zdroje, zatímco cíl je také používán přímo producenty.
  • Předchozí vzor, ale zprávy zrcadlené mezi dvěma nebo více tématy, což vede k těmto tématům obsahujícím stejné zprávy bez ohledu na to, kde se vytvářejí zprávy.

První dvě varianty vzorů jsou triviální a neliší se od úloh prosté replikace.

Poslední scénář vyžaduje, aby se už replikované zprávy znovu nereplikovaly. Tato technika se demonstruje a vysvětluje v ukázce aktivní/aktivní.

Editor

Vzor editoru vychází ze vzoru replikace , ale zprávy se před jejich přeposílání upraví. Mezi příklady takových úprav patří:

  • Překódování – Pokud obsah zprávy (označovaný také jako "tělo" nebo "datová část") přijde ze zdroje kódovaného pomocí formátu Apache Avro nebo nějakého proprietárního serializačního formátu, ale očekává se, že systém, který vlastní cíl, bude obsah kódovaný ve formátu JSON, úloha transkódování replikace nejprve deserializuje datovou část z Apache Avro do grafu objektu v paměti a potom tento graf serializuje do formátu JSON. formát zprávy, která se přeposílají. Překódování zahrnuje také kompresi obsahu a dekompresi úloh.
  • Transformace – zprávy, které obsahují strukturovaná data, mohou vyžadovat změnu tvaru těchto dat, aby je mohli příjemní příjemci usnadnit. To může zahrnovat práci, jako je zploštění vnořených struktur, vyřazení nadbytečných datových prvků nebo změna tvaru datové části tak, aby přesně odpovídala danému schématu.
  • Dávkování – zprávy mohou být přijaty v dávkách (více zpráv v jednom přenosu) ze zdroje, ale musí se předávat ingálně do cíle nebo naopak. Úkol proto může předávat více zpráv na základě jednoho přenosu vstupní zprávy nebo agregovat sadu zpráv, které se pak přenesou dohromady.
  • Ověření – data zpráv z externích zdrojů je často potřeba zkontrolovat, jestli jsou v souladu se sadou pravidel, než je možné je přeposlat. Pravidla mohou být vyjádřena pomocí schémat nebo kódu. Zprávy, které nejsou v souladu s předpisy, mohou být vyřazeny, s problémem v protokolech nebo mohou být přeposlány do speciálního cílového cíle pro jejich další zpracování.
  • Rozšiřování – data zpráv pocházející z některých zdrojů mohou vyžadovat rozšiřování s dalším kontextem, aby je bylo možné použít v cílových systémech. To může zahrnovat vyhledání referenčních dat a vložení těchto dat se zprávou nebo přidání informací o zdroji, který je známý pro úlohu replikace, ale neobsahuje je ve zprávách.
  • Filtrování – Některé zprávy přicházející ze zdroje můžou být z cíle na základě nějakého pravidla odmítnuty. Filtr otestuje zprávu proti pravidlu a zprávu zahodí, pokud zpráva neodpovídá pravidlu. Filtrování duplicitních zpráv sledováním určitých kritérií a vyřazením následných zpráv se stejnými hodnotami je forma filtrování.
  • Směrování a dělení – Některé úlohy replikace můžou umožňovat dva nebo více alternativních cílů a definovat pravidla, pro které je cíl replikace zvolen pro každou konkrétní zprávu na základě metadat nebo obsahu zprávy. Zvláštní forma směrování je dělení, kde úloha explicitně přiřazuje oddíly v jednom cíli replikace na základě pravidel.
  • Kryptografie – Úloha replikace může obsahovat dešifrování obsahu přicházejícího ze zdroje nebo šifrování obsahu předávaného směrem k cíli nebo k ověření integrity obsahu a metadat vzhledem k podpisu přenášeného ve zprávě nebo k připojení takového podpisu.
  • Ověření identity – Úloha replikace může připojit metadata, potenciálně chráněná digitálním podpisem, ke zprávě, která potvrzuje, že zpráva byla přijata prostřednictvím určitého kanálu nebo v konkrétní době.
  • Řetězení – Úloha replikace může používat podpisy u sekvencí zpráv tak, aby byla chráněna integrita sekvence a bylo možné detekovat chybějící zprávy.

Všechny tyto vzory je možné implementovat pomocí služby Azure Functions pomocí triggeru služby Message Hubs pro získávání zpráv a výstupní vazby fronty nebo tématu pro jejich doručování.

Směrování

Vzor směrování vychází ze vzoru replikace , ale místo toho, aby měl jeden zdroj a jeden cíl, má úloha replikace více cílů, jak je znázorněno tady v jazyce C#:

[FunctionName("SBRouter")]
public static async Task Run(
    [ServiceBusTrigger("source", Connection = "serviceBusConnectionAppSetting")] ServiceBusReceivedMessage[] messages,
    [ServiceBusOutput("dest1", Connection = "serviceBusConnectionAppSetting")] IAsyncCollector<dynamic> output1,
    [ServiceBusOutput("dest2", Connection = "serviceBusConnectionAppSetting")] IAsyncCollector<dynamic> output2,
    ILogger log)
{
    foreach (Message messageData in messages)
    {
        // send to output1 or output2 based on criteria 
    }
}

Funkce směrování bude brát v úvahu metadata zpráv nebo datovou část zprávy a pak vybere jeden z dostupných cílů pro odeslání.

Další kroky