Přístupy architektury pro zasílání zpráv ve víceklientských řešeních

Asynchronní zasílání zpráv a komunikace řízená událostmi jsou důležité prostředky při vytváření distribuované aplikace, která se skládá z několika interních a externích služeb. Při návrhu víceklientské řešení je důležité provést předběžnou analýzu, která definuje, jak sdílet nebo rozdělit zprávy, které se týkají různých tenantů.

Sdílení stejného systému zasílání zpráv nebo služby streamování událostí může výrazně snížit složitost provozních nákladů a správy. Použití vyhrazeného systému zasílání zpráv pro každého tenanta ale poskytuje lepší izolaci dat, snižuje riziko úniku dat, eliminuje problém s hlučným sousedem a umožňuje snadno účtovat náklady na Azure vašim tenantům.

V tomto článku najdete rozdíl mezi zprávami a událostmi a najdete pokyny, které mohou architekti řešení dodržovat při rozhodování o tom, jaký přístup použít pro zasílání zpráv nebo infrastrukturu událostí ve víceklientských řešeních.

Zprávy, datové body a diskrétní události

Všechny systémy zasílání zpráv mají podobné funkce, přenosové protokoly a scénáře použití. Většina moderních systémů zasílání zpráv například podporuje asynchronní komunikaci, která používá nestálé nebo trvalé fronty, přenosové protokoly AMQP a HTTPS, alespoň jedno doručení atd. Při bližším pohledu na typ publikovaných informací a způsobu využívání a zpracování dat klientskými aplikacemi však můžeme rozlišovat mezi různými druhy zpráv a událostí. Mezi službami, které doručí události, a systémy, které odesílají zprávu, je zásadní rozdíl. Další informace naleznete v následujících zdrojích:

• Volba mezi službami zasílání zpráv Azure – Event Grid, Event Hubs a Service Bus
• Události, datové body a zprávy – Volba správné služby zasílání zpráv Azure pro vaše data

Události

Událost je odlehčené oznámení o stavu nebo změně stavu. Události můžou být samostatné jednotky nebo můžou být součástí řady. Události jsou zprávy, které obecně nesdělují jiný záměr vydavatele než informovat. Událost zachycuje fakt a komunikuje s jinými službami nebo komponentami. Příjemce události může událost zpracovat tak, jak ji chce, a nesplňuje žádná konkrétní očekávání, která vydavatel uchovává. Události můžeme klasifikovat do dvou hlavních kategorií:

• Diskrétní události uchovávají informace o konkrétních akcích, které aplikace publikování provedla. Při použití asynchronní komunikace řízené událostmi publikuje aplikace událost oznámení, když se něco stane v rámci své domény. Jedna nebo více spotřebovaných aplikací si musí být vědoma této změny stavu, jako je například změna ceny v aplikaci katalogu produktů. Uživatelé se přihlásí k odběru událostí, aby je dostávali asynchronně. Když dojde k určité události, můžou aplikace, které využívají, aktualizovat entity domény, což může způsobit publikování dalších událostí integrace.
• Události řady obsahují informační datové body, jako jsou například hodnoty teploty ze zařízení pro analýzu nebo akce uživatelů v řešení pro analýzu kliknutí, jako prvky v probíhajícím nepřetržitém datovém proudu. Stream událostí souvisí s konkrétním kontextem, jako je teplota nebo vlhkost hlášená zařízením pole. Všechny události související se stejným kontextem mají striktní časové pořadí, které je důležité při zpracování těchto událostí pomocí modulu zpracování datových proudů událostí. Analýza datových proudů událostí, které přenášejí datové body, vyžaduje shromáždění těchto událostí v vyrovnávací paměti, která zahrnuje požadovaný časový interval. Nebo může být ve vybraném počtu položek a následné zpracování těchto událostí pomocí řešení téměř v reálném čase nebo strojově natrénovaného algoritmu. Analýza řady událostí může přinést signály, jako je průměr hodnoty měřené v časovém intervalu, který překročí prahovou hodnotu. Tyto signály pak mohou být vyvolány jako diskrétní a akceovatelné události.

Samostatné události hlásí změny stavu a jsou použitelné. Datová část události obsahuje informace o tom, co se stalo, ale obecně neobsahuje úplná data, která událost aktivovala. Například událost upozorní uživatele, že aplikace pro vytváření sestav vytvořila nový soubor v účtu úložiště. Datová část události může mít obecné informace o souboru, ale samotný soubor neobsahuje. Samostatné události jsou ideální pro řešení bez serveru, která vyžadují škálování.

Řady událostí hlásí určitý stav a jsou analyzovatelné. Diskrétní události jsou časově uspořádané a vzájemně propojené. V některých kontextech musí příjemce obdržet kompletní posloupnost událostí, aby analyzoval, co se stalo, a provést potřebnou akci.

Zprávy

Zprávy obsahují nezpracovaná data vytvořená službou, která se mají využívat nebo ukládat jinde. Zprávy často obsahují informace potřebné k tomu, aby přijímající služba prováděla kroky v pracovním postupu nebo řetězu zpracování. Příkladem tohoto typu komunikace je vzor Příkaz. Vydavatel může také očekávat, že příjemci zprávy spustí řadu akcí a ohlásí výsledek zpracování pomocí asynchronní zprávy. Mezi vydavatelem zprávy a příjemcem zpráv existuje smlouva. Vydavatel například odešle zprávu s některými nezpracovanými daty a očekává, že příjemce vytvoří soubor z dat a po dokončení odešle zprávu s odpovědí. V jiných situacích může proces odesílatele odeslat asynchronní jednosměrnou zprávu, která požádá jinou službu, aby provedla danou operaci, ale bez očekávání, že od ní dostanete potvrzení nebo odpověď.

Tento druh zpracování smluvních zpráv se liší od vydavatele, který publikuje diskrétní události cílové skupině spotřebitelských agentů bez jakéhokoli konkrétního očekávání, jak budou tato oznámení zpracovávat.

Ukázkové scénáře

Tady je seznam některých ukázkových scénářů s více tenanty pro zprávy, datové body a diskrétní události:

• Diskrétní události:
  • Platforma pro sdílení hudby sleduje skutečnost, že konkrétní uživatel v konkrétním tenantovi naslouchal konkrétní hudební skladbě.
  • Ve webové aplikaci online obchodu odešle aplikace katalogu událost pomocí vzoru Vydavatel-Odběratel do jiných aplikací, aby jim oznámila, že se změnila cena položky.
  • Výrobní společnost nasdílí zákazníkům a třetím stranám informace o údržbě zařízení, stavu systémů a aktualizacích smluv v reálném čase.
• Datové body:
  • Řídicí systém budovy přijímá telemetrické události, jako jsou teploty nebo vlhkost čtení ze senzorů, které patří více zákazníkům.
  • Monitorovací systém řízený událostmi přijímá a zpracovává diagnostické protokoly téměř v reálném čase z několika služeb, jako jsou webové servery.
  • Skript na straně klienta na webové stránce shromažďuje akce uživatelů a odesílá je do řešení pro analýzu kliknutí.
• Zprávy:
  • Finanční aplikace B2B obdrží zprávu, která začne zpracovávat bankovní záznamy tenanta.
  • Dlouhotrvající pracovní postup obdrží zprávu, která aktivuje spuštění dalšího kroku.
  • Aplikace nákupního košíku aplikace online obchodu odešle příkaz CreateOrder pomocí asynchronní trvalé zprávy do aplikace objednávání.

Klíčové aspekty a požadavky

Model nasazení a tenantů , který zvolíte pro vaše řešení, má hluboký dopad na zabezpečení, výkon, izolaci dat, správu a možnost křížově účtovat náklady na prostředky tenantům. Tato analýza zahrnuje model, který vyberete pro infrastrukturu zasílání zpráv a událostí. V této části si projdeme některá klíčová rozhodnutí, která musíte provést, když plánujete systém zasílání zpráv ve víceklientských řešeních.

Měřítko

Počet tenantů, složitost toků zpráv a datových proudů událostí, objem zpráv, očekávaný profil provozu a úroveň izolace by měla řídit rozhodování při plánování zasílání zpráv nebo infrastruktury událostí.

Prvním krokem je provádění vyčerpávajícího plánování kapacity a vytvoření nezbytné maximální kapacity systému zasílání zpráv z hlediska propustnosti pro správné zpracování očekávaného objemu zpráv v rámci pravidelného nebo špičkového provozu.

Některé nabídky služeb, jako je úroveň Premium služby Azure Service Bus, poskytují izolaci prostředků na úrovni procesoru a paměti, aby každá úloha zákazníka běžela izolovaně. Kontejner prostředků se nazývá jednotka zasílání zpráv. Každému prémiovému obor názvů se přiřadí aspoň jedna jednotka zasílání zpráv. Pro každý obor názvů služby Service Bus Premium si můžete koupit 1, 2, 4, 8 nebo 16 jednotek zasílání zpráv. Jedna úloha nebo entita může zahrnovat více jednotek zasílání zpráv a podle potřeby můžete změnit počet jednotek zasílání zpráv. Výsledkem je předvídatelný a opakovatelný výkon vašeho řešení založeného na službě Service Bus. Další informace najdete v tématu Úrovně zasílání zpráv Service Bus Premium a Standard. Podobně cenové úrovně služby Azure Event Hubs umožňují velikost oboru názvů na základě očekávaného objemu příchozích a odchozích událostí. Například nabídka Premium se účtuje procesorovými jednotkami (PU), které odpovídají podílu izolovaných prostředků (procesoru, paměti a úložiště) v základní infrastruktuře. Efektivní propustnost ingestování a datových proudů na pu bude záviset na následujících faktorech:

• Počet výrobců a spotřebitelů
• Velikost datové části
• Počet oddílů
• Rychlost požadavků výchozího přenosu dat
• Použití funkce Event Hubs Capture, Schema Registry a dalších pokročilých funkcí

Další informace najdete v tématu Přehled služby Event Hubs Premium.

Když vaše řešení zpracovává velký počet tenantů a rozhodnete se pro každého tenanta přijmout samostatný systém zasílání zpráv, musíte mít konzistentní strategii pro automatizaci nasazení, monitorování, upozorňování a škálování každé infrastruktury odděleně od druhé.

Například systém zasílání zpráv pro daného tenanta může být nasazen během procesu zřizování pomocí nástroje infrastruktury jako kódu (IaC), jako je Terraform, Bicep nebo šablony JSON Azure Resource Manageru (ARM) a systému DevOps, jako je Azure DevOps nebo GitHub Actions. Další informace najdete v tématu Přístupy architektury pro nasazení a konfiguraci víceklientských řešení.

Systém zasílání zpráv může mít maximální propustnost ve zprávách za jednotku času. Pokud systém podporuje dynamické automatické škálování, může se jeho kapacita automaticky zvýšit nebo snížit na základě podmínek provozu a metrik, aby splňovala očekávanou smlouvu o úrovni služeb.

Předvídatelnost a spolehlivost výkonu

Při navrhování a vytváření systému zasílání zpráv pro omezený počet tenantů může být použití jednoho systému zasílání zpráv vynikajícím řešením pro splnění funkčních požadavků, pokud jde o propustnost, a může snížit celkové náklady na vlastnictví. Víceklientní aplikace může sdílet stejné entity zasílání zpráv, jako jsou fronty a témata napříč více zákazníky. Nebo můžou pro každý z nich použít vyhrazenou sadu komponent, aby se zvýšila izolace tenanta. Na druhé straně by sdílení stejné infrastruktury zasílání zpráv napříč několika tenanty mohlo vystavit celé řešení problému typu Noisy Soused. Aktivita jednoho tenanta může poškodit jiné tenanty z hlediska výkonu a provozuschopnosti.

V takovém případě by systém zasílání zpráv měl mít správnou velikost, aby udržel očekávané zatížení provozu ve špičce. V ideálním případě by měla podporovat automatické škálování. Systém zasílání zpráv by měl dynamicky navýšovat kapacitu, když se provoz zvyšuje a škáluje při poklesu provozu. Vyhrazený systém zasílání zpráv pro každého tenanta by také mohl zmírnit riziko hlučného souseda, ale správa velkého počtu systémů zasílání zpráv by mohla zvýšit složitost řešení.

Multitenantní aplikace může nakonec přijmout hybridní přístup, kdy základní služby používají stejnou sadu front a témat v jednom systému sdíleného zasílání zpráv, aby bylo možné implementovat interní asynchronní komunikaci. Naproti tomu ostatní služby by mohly přijmout vyhrazenou skupinu entit zasílání zpráv nebo dokonce vyhrazený systém zasílání zpráv, aby každý tenant zmírnit problém s hlučným sousedem a zaručit izolaci dat.

Při nasazování systému zasílání zpráv do virtuálních počítačů byste měli tyto virtuální počítače najít společně s výpočetními prostředky, abyste snížili latenci sítě. Tyto virtuální počítače by se neměly sdílet s jinými službami nebo aplikacemi, aby se zabránilo infrastruktuře zasílání zpráv, která by soutěžila o systémové prostředky, jako jsou procesor, paměť a šířka pásma sítě s jinými systémy. Virtuální počítače se také můžou rozšířit mezi zóny dostupnosti, aby se zvýšila odolnost uvnitř oblasti a spolehlivost důležitých obchodních úloh, včetně systémů zasílání zpráv. Předpokládejme, že se rozhodnete hostovat systém zasílání zpráv, jako je RabbitMQ nebo Apache ActiveMQ, na virtuálních počítačích. V takovém případě doporučujeme ji nasadit do škálovací sady virtuálních počítačů a nakonfigurovat ji pro automatické škálování na základě metrik, jako je procesor nebo paměť. Díky tomu se počet uzlů agentů hostující systém zasílání zpráv správně škáluje a škáluje na základě podmínek provozu. Další informace najdete v tématu Přehled automatického škálování pomocí škálovacích sad virtuálních počítačů Azure.

Stejně tak při hostování systému zasílání zpráv v clusteru Kubernetes zvažte použití selektorů a taintů uzlů k naplánování provádění jeho podů ve vyhrazeném fondu uzlů, který není sdílený s jinými úlohami, aby se zabránilo problému s hlučným sousedem. Při nasazování systému zasílání zpráv do zónově redundantního clusteru AKS použijte omezení topologie podů, která určují , jak se pody distribuují v clusteru AKS mezi domény selhání, jako jsou oblasti, zóny dostupnosti a uzly. Při hostování systému zasílání zpráv třetí strany v AKS použijte automatické škálování Kubernetes k dynamickému horizontálnímu navýšení kapacity počtu pracovních uzlů při zvýšení provozu. Díky automatickému škálování horizontálních podů a automatického škálování clusteru AKS se svazky uzlů a podů dynamicky upraví v reálném čase tak, aby odpovídaly požadavkům na provoz a vyhnuly se výpadkům způsobeným problémy s kapacitou. Další informace najdete v tématu Automatické škálování clusteru tak, aby splňoval požadavky aplikací na službu Azure Kubernetes Service (AKS). Pokud chcete na základě délky dané fronty škálovat pody systému zasílání zpráv hostovaného v Kubernetes, jako je RabbitMQ nebo Apache ActiveMQ, zvažte použití automatického škálování kubernetes (KEDA). KeDA umožňuje řídit škálování libovolného kontejneru v Kubernetes na základě počtu událostí, které je potřeba zpracovat. KeDA můžete například použít ke škálování aplikací na základě délky fronty služby Azure Service Bus, fronty RabbitMQ nebo fronty ActiveMQ. Další informace o KEDA najdete v tématu Automatické škálování řízené událostmi Kubernetes.

Izolace

Při navrhování systému zasílání zpráv pro víceklientské řešení byste měli zvážit, že různé typy aplikací vyžadují jiný druh izolace, který je založený na požadavcích na výkon, ochranu osobních údajů a auditování tenantů.

• Více tenantů může sdílet stejné entity zasílání zpráv, jako jsou fronty, témata a odběry, ve stejném systému zasílání zpráv. Aplikace s více tenanty může například přijímat zprávy, které přenášejí data pro více tenantů z jedné fronty služby Azure Service Bus . Toto řešení může vést k problémům s výkonem a škálovatelností. Pokud některé z tenantů generují větší objem objednávek než jiné, může to způsobit backlog zpráv. Tento problém, označovaný také jako problém typu Noisy Neighbor, může snížit smlouvu o úrovni služeb z hlediska latence u některých tenantů. Problém je zřetelnější, pokud aplikace příjemce čte a zpracovává zprávy z fronty, po jednom v přísném chronologickém pořadí a pokud doba potřebná ke zpracování zprávy závisí na počtu položek v datové části. Při sdílení jednoho nebo více prostředků fronty mezi více tenanty by měly být systémy infrastruktury zasílání zpráv a zpracování schopny přizpůsobit očekávané přenosy na základě požadavků na škálování a propustnost. Tento přístup k architektuře je vhodný v těchto scénářích, kdy víceklientské řešení přijímá jeden fond pracovních procesů, aby bylo možné přijímat, zpracovávat a odesílat zprávy pro všechny tenanty.
• Více tenantů sdílí stejný systém zasílání zpráv, ale používá jiné téma nebo prostředky fronty. Tento přístup poskytuje lepší izolaci a ochranu dat s vyššími náklady, vyšší provozní složitost a nižší flexibilitu, protože správci systému musí zřizovat, monitorovat a udržovat vyšší počet prostředků fronty. Toto řešení zajišťuje konzistentní a předvídatelné prostředí pro všechny tenanty, pokud jde o smlouvy o výkonu a úrovni služeb, protože brání jakémukoli tenantovi v vytvoření kritického bodu, který může ovlivnit ostatní tenanty.
• Pro každého tenanta se používá samostatný vyhrazený systém zasílání zpráv. Například víceklientové řešení může pro každého tenanta použít odlišný obor názvů služby Azure Service Bus . Toto řešení poskytuje maximální míru izolace s vyšší složitostí a provozními náklady. Tento přístup zaručuje konzistentní výkon a umožňuje jemně doladit systém zasílání zpráv na základě konkrétních potřeb tenanta. Když je nový tenant nasazený, kromě plně vyhrazeného systému zasílání zpráv může aplikace zřizování také potřebovat vytvořit samostatnou spravovanou identitu nebo instanční objekt se správnými oprávněními RBAC pro přístup k nově vytvořenému oboru názvů. Například když cluster Kubernetes sdílí několik instancí stejné aplikace SaaS, jeden pro každého tenanta a každý spuštěný v samostatném oboru názvů, může každá instance aplikace pro přístup k vyhrazenému systému zasílání zpráv používat jiný instanční objekt nebo spravovanou identitu. V tomto kontextu může být systém zasílání zpráv plně spravovanou službou PaaS, jako je obor názvů služby Azure Service Bus nebo systém zasílání zpráv hostovaný v Kubernetes, například RabbitMQ. Při odstraňování tenanta ze systému by aplikace měla odebrat systém zasílání zpráv a všechny vyhrazené prostředky, které byly dříve vytvořeny pro tenanta. Hlavní nevýhodou tohoto přístupu je, že zvyšuje provozní složitost a snižuje flexibilitu, zejména v případě, že počet tenantů v průběhu času roste.

Projděte si následující další aspekty a pozorování:

• Pokud tenanti potřebují k šifrování a dešifrování zpráv použít vlastní klíč, mělo by víceklientové řešení poskytnout možnost přijmout samostatný obor názvů Azure Service Bus Premium pro každého tenanta. Další informace najdete v tématu Konfigurace klíčů spravovaných zákazníkem pro šifrování neaktivních uložených dat služby Azure Service Bus.
• Pokud tenanti potřebují vysokou úroveň odolnosti a provozní kontinuity, mělo by víceklientové řešení poskytnout možnost zřídit obor názvů Service Bus Premium s povoleným geografickým zotavením po havárii a zónami dostupnosti. Další informace najdete v tématu Geografické zotavení po havárii služby Azure Service Bus.
• Při použití samostatných prostředků fronty nebo vyhrazeného systému zasílání zpráv pro každého tenanta je vhodné přijmout samostatný fond pracovních procesů, pro každý z nich zvýšit úroveň izolace dat a snížit složitost zpracování více entit zasílání zpráv. Každá instance systému zpracování může přijímat různé přihlašovací údaje, jako jsou připojovací řetězec, instanční objekt nebo spravovaná identita, aby bylo možné získat přístup k vyhrazenému systému zasílání zpráv. Tento přístup poskytuje lepší úroveň zabezpečení a izolaci mezi tenanty, ale vyžaduje větší složitost správy identit.

Podobně může aplikace řízená událostmi poskytovat různé úrovně izolace:

• Aplikace řízená událostmi přijímá události z více tenantů prostřednictvím jedné sdílené instance služby Azure Event Hubs . Toto řešení poskytuje vysokou úroveň flexibility, protože onboarding nového tenanta nevyžaduje vytvoření vyhrazeného prostředku pro příjem událostí, ale poskytuje nízkou úroveň ochrany dat, protože protíná zprávy z více tenantů ve stejné datové struktuře.
• Tenanti se můžou rozhodnout pro vyhrazené centrum událostí nebo téma Kafka, aby se zabránilo problému s hlučným sousedem a aby splnili své požadavky na izolaci dat, pokud události nesmí být spolusouhlasené s jinými tenanty kvůli zabezpečení a ochraně dat.
• Pokud tenanti potřebují vysokou úroveň odolnosti a provozní kontinuity, měl by víceklient poskytnout možnost zřídit obor názvů služby Event Hubs Premium s povoleným geografickým zotavením po havárii a zónami dostupnosti. Další informace najdete v tématu Azure Event Hubs – Geografické zotavení po havárii.
• Vyhrazená služba Event Hubs s povolenou funkcí Event Hubs Capture by se měla vytvářet pro zákazníky, kteří potřebují archivovat události do účtu služby Azure Storage z důvodu dodržování právních předpisů a povinností. Další informace najdete v tématu Zachycení událostí prostřednictvím služby Azure Event Hubs ve službě Azure Blob Storage nebo Azure Data Lake Storage.
• Jedna víceklientová aplikace může odesílat oznámení do několika interních a externích systémů pomocí služby Azure Event Grid. V tomto případě by se pro každou aplikaci příjemce měla vytvořit samostatné předplatné Event Gridu. Pokud vaše aplikace využívá více instancí Event Gridu k odesílání oznámení velkému počtu externích organizací, zvažte použití domén událostí, které aplikaci umožňují publikovat události do tisíců témat, jako je jedna pro každého tenanta. Další informace najdete v tématu Vysvětlení domén událostí pro správu témat event Gridu.

Složitost implementace

Při navrhování víceklientské řešení je důležité zvážit, jak se systém bude vyvíjet v dlouhodobém horizontu, aby se zabránilo jeho složitosti v průběhu času, dokud nebude nutné přepracovat část nebo celé řešení. Tento návrh vám pomůže vyrovnat se s rostoucím počtem tenantů. Při návrhu systému zasílání zpráv byste měli zvážit očekávaný růst objemů zpráv a tenantů v příštích několika letech a pak vytvořit systém, který může vertikálně navýšit kapacitu, aby udržel krok s předpokládaným provozem a snížil složitost operací, jako je zřizování, monitorování a údržba.

Řešení by mělo automaticky vytvářet nebo odstraňovat potřebné entity zasílání zpráv pokaždé, když je aplikace tenanta zřízená nebo zrušena, aniž by bylo nutné provádět ruční operace.

Konkrétním problémem pro víceklientských datových řešení je úroveň přizpůsobení, kterou podporujete. Veškeré přizpůsobení by mělo být automaticky nakonfigurováno a použito systémem zřizování aplikací (například systémem DevOps), který je založený na sadě počátečních parametrů při každém nasazení jednoklientských nebo víceklientských aplikací.

Složitost správy a provozu

Naplánujte si od začátku, jak máte v úmyslu provozovat, monitorovat a udržovat infrastrukturu zasílání zpráv a událostí a jak váš přístup s více tenanty ovlivňuje vaše operace a procesy. Představte si například následující možnosti:

• Možná budete chtít hostovat systém zasílání zpráv, který vaše aplikace používá ve vyhrazené sadě virtuálních počítačů, jeden pro každého tenanta. Pokud ano, jak plánujete nasadit, upgradovat, monitorovat a škálovat tyto systémy?
• Podobně pokud kontejnerizujete a hostujete systém zasílání zpráv ve sdíleném clusteru Kubernetes, jak plánujete nasazovat, upgradovat, monitorovat a škálovat jednotlivé systémy zasílání zpráv?
• Předpokládejme, že sdílíte systém zasílání zpráv napříč několika tenanty. Jak může vaše řešení shromažďovat a hlásit metriky využití pro jednotlivé tenanty nebo omezovat počet zpráv, které může každý tenant odesílat nebo přijímat?
• Pokud váš systém zasílání zpráv využívá službu PaaS, jako je Azure Service Bus, měli byste položit následující otázku:
  • Jak můžete přizpůsobit cenovou úroveň pro každého tenanta na základě funkcí a úrovně izolace (sdílené nebo vyhrazené), které tenant požaduje?
  • Jak můžete vytvořit identitu pro jednotlivé tenanty a přiřazení role Azure, abyste přiřadili správná oprávnění pouze entitám zasílání zpráv, jako jsou fronty, témata a odběry, ke kterým má tenant přístup? Další informace najdete v tématu Ověření spravované identity pomocí ID Microsoft Entra pro přístup k prostředkům Azure Service Bus.
• Jak budete migrovat tenanty, pokud se potřebují přesunout do jiného typu služby zasílání zpráv, jiného nasazení nebo jiné oblasti?

Náklady

Obecně platí, že čím vyšší je hustota tenantů pro vaši infrastrukturu nasazení, tím nižší jsou náklady na zřízení této infrastruktury. Sdílená infrastruktura ale zvyšuje pravděpodobnost problémů, jako je problém hlučného souseda, proto pečlivě zvažte kompromisy.

Přístupy a vzory, které je potřeba zvážit

Několik vzorů návrhu cloudu z Centra architektury Azure se dá použít na víceklientských systémů zasílání zpráv. Můžete se rozhodnout, že budete dodržovat jeden nebo více vzorů konzistentně, nebo můžete zvážit kombinování a porovnávání vzorů na základě vašich potřeb. Můžete například použít obor názvů služby Service Bus s více tenanty pro většinu vašich tenantů, ale pak můžete nasadit vyhrazený obor názvů service bus s jedním tenantem pro ty tenanty, kteří platí více nebo mají vyšší požadavky, z hlediska izolace a výkonu. Podobně je často vhodné škálovat pomocí razítek nasazení, i když v rámci razítka používáte víceklientský obor názvů služby Service Bus nebo vyhrazené obory názvů.

Model razítka nasazení

Další informace o modelu razítka nasazení a víceklientské architektuře naleznete v části Vzor razítka nasazení přístupů architektury pro víceklientské architektury. Další informace o modelech tenantů najdete v tématu Modely tenantů, které je potřeba zvážit pro víceklientské řešení.

Systém sdíleného zasílání zpráv

Můžete zvážit nasazení systému sdíleného zasílání zpráv, jako je Azure Service Bus, a jeho sdílení napříč všemi vašimi tenanty.

Tento přístup poskytuje nejvyšší hustotu tenantů infrastruktuře, takže snižuje celkové celkové náklady na vlastnictví. Často také snižuje režijní náklady na správu, protože existuje jeden systém zasílání zpráv nebo prostředek pro správu a zabezpečení.

Pokud ale sdílíte prostředek nebo celou infrastrukturu napříč více tenanty, zvažte následující upozornění:

• Mějte vždy na paměti a zvažte omezení, možnosti škálování, kvóty a omezení příslušného prostředku. Například maximální počet oborů názvů služby Service Bus v předplatném Azure, maximální počet služeb Event Hubs v jednom oboru názvů nebo maximální limity propustnosti se můžou stát překážkou, pokud a když vaše architektura roste, aby podporovala více tenantů. Pečlivě zvažte maximální rozsah, kterého potřebujete dosáhnout z hlediska počtu oborů názvů na jedno předplatné Azure nebo front na jeden obor názvů. Než vyberete tento model, porovnejte své aktuální a budoucí odhady se stávajícími kvótami a omezeními zvoleného systému zasílání zpráv.
• Jak je uvedeno v předchozích částech, problém s hlučným sousedem se může stát faktorem, když sdílíte prostředek mezi více tenanty, zejména pokud jsou některé zvlášť zaneprázdněné nebo pokud generují vyšší provoz než jiné. V tomto případě zvažte použití vzoru omezování nebo modelu omezování rychlosti, abyste tyto účinky zmírnit. Můžete například omezit maximální počet zpráv, které může jeden tenant posílat nebo přijímat v jednotce času.
• Možná budete mít potíže s monitorováním aktivity a měřením spotřeby prostředků pro jednoho tenanta. Některé služby, jako je Azure Service Bus, se účtují za operace zasílání zpráv. Proto když sdílíte obor názvů mezi více tenanty, měla by vaše aplikace mít možnost sledovat počet operací zasílání zpráv provedených jménem každého tenanta a náklady na vrácení peněz. Jiné služby neposkytují stejnou úroveň podrobností.

Tenanti můžou mít různé požadavky na zabezpečení, odolnost uvnitř oblasti, zotavení po havárii nebo umístění. Pokud se neshodují s konfigurací systému zasílání zpráv, možná je nebudete moct pojmout jenom s jedním prostředkem.

Model horizontálního dělení

Model horizontálního dělení zahrnuje nasazení několika systémů zasílání zpráv, označovaných jako horizontální oddíly, které obsahují entity zasílání zpráv jednoho nebo více tenantů, jako jsou fronty a témata. Na rozdíl od kolků nasazení neznamenají horizontální oddíly, že je celá infrastruktura duplikovaná. Systémy zasílání zpráv horizontálního dělení můžete bez duplikování nebo horizontálního dělení jiné infrastruktury ve vašem řešení.

Každý systém zasílání zpráv nebo horizontální oddíl může mít různé charakteristiky z hlediska spolehlivosti, skladové položky a umístění. Tenanty můžete například horizontálně dělit napříč několika systémy zasílání zpráv s různými charakteristikami na základě jejich umístění nebo potřeb z hlediska výkonu, spolehlivosti, ochrany dat nebo provozní kontinuity.

Pokud používáte model horizontálního dělení, musíte použít strategii horizontálního dělení, abyste mohli mapovat daného tenanta na systém zasílání zpráv, který obsahuje jeho fronty. Strategie vyhledávání používá mapu k individuaci cílového systému zasílání zpráv na základě názvu nebo ID tenanta. Stejný horizontální oddíl může sdílet více tenantů, ale entity zasílání zpráv používané jedním tenantem se nebudou šířit mezi více horizontálních oddílů. Mapu lze implementovat pomocí jednoho slovníku, který mapuje název tenanta na název nebo odkaz cílového systému zasílání zpráv. Mapa může být uložena v distribuované mezipaměti přístupné ze všech instancí víceklientských aplikací nebo v trvalém úložišti, jako je tabulka v relační databázi nebo tabulka v účtu úložiště.

Model horizontálního dělení se může škálovat na velmi velký počet tenantů. V závislosti na vaší úloze navíc můžete být schopni dosáhnout vysoké hustoty tenantů s horizontálními oddíly, aby náklady mohly být atraktivní. Model horizontálního dělení se dá použít také k řešení kvót, limitů a omezení předplatného a služeb Azure.

Víceklientní aplikace s vyhrazeným systémem zasílání zpráv pro každého tenanta

Dalším běžným přístupem je nasazení jedné víceklientové aplikace s vyhrazenými systémy zasílání zpráv pro každého tenanta. V tomto modelu tenantů máte některé sdílené komponenty, jako jsou výpočetní prostředky, zatímco ostatní služby se zřizují a spravují pomocí přístupu k nasazení s jedním tenantem. Můžete například vytvořit jednu aplikační vrstvu a pak nasadit jednotlivé systémy zasílání zpráv pro každého tenanta, jak je znázorněno na následujícím obrázku.

Horizontálně dělené nasazení vám můžou pomoct zmírnit problém s hlučným sousedem, pokud jste zjistili, že většina zatížení systému je způsobená konkrétními komponentami, které můžete nasadit samostatně pro každého tenanta. Například pro každého tenanta možná budete muset použít samostatný systém zasílání zpráv nebo streamování událostí, protože jedna instance nestačí k tomu, aby udržela krok s provozem vygenerovaným více tenanty. Pokud pro každého tenanta používáte vyhrazený systém zasílání zpráv, může to mít vliv na sdílené komponenty, ale ne na systémy zasílání zpráv jiných tenantů.

Vzhledem k tomu, že pro každého tenanta zřizujete vyhrazené prostředky, můžou být náklady na tento přístup vyšší než model sdíleného hostování. Na druhou stranu je jednodušší účtovat náklady na prostředky vyhrazeného systému na jedinečného tenanta, který ho využívá, při přechodu na tento model tenanta. Tento přístup umožňuje dosáhnout vysoké hustoty pro jiné služby, jako jsou výpočetní prostředky, a snižuje náklady na tyto komponenty.

Při horizontálně děleném nasazení je potřeba přijmout automatizovaný proces pro nasazení a správu služeb víceklientské aplikace, zejména těch, které používá jeden tenant.

Model geodes

Model Geode zahrnuje nasazení kolekce back-endových služeb do sady geografických uzlů. Každá z nich může obsluhovat jakoukoli žádost o libovolného klienta v libovolné oblasti. Tento model umožňuje obsluhovat požadavky ve stylu aktivní-aktivní, což zlepšuje latenci a zvyšuje dostupnost tím, že distribuuje zpracování požadavků po celém světě.

Azure Service Bus a Azure Event Hubs podporují zotavení po havárii metadat v primárních a sekundárních oborech názvů zotavení po havárii a napříč samostatnými oblastmi a zónami dostupnosti, aby byla zajištěna podpora pro nejlepší odolnost uvnitř oblastí. Azure Service Bus a Azure Event Hubs také implementují sadu vzorů federace, které aktivně replikují stejné logické téma, frontu nebo centrum událostí, aby byly dostupné ve více oborech názvů, a nakonec se nacházejí v různých oblastech. Další informace naleznete v následujících zdrojích:

• Replikace zpráv a federace mezi oblastmi
• Vzory úloh replikace zpráv
• Federace více lokalit a více oblastí
• Vzory úloh replikace událostí

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Paul Salvatori | Hlavní zákaznický inženýr, FastTrack pro Azure

Další přispěvatelé:

• John Downs | Hlavní softwarový inženýr
• Clemens Vasters | Hlavní architekt, služby zasílání zpráv a standardy
• Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure

Další kroky

Další informace o vzorech návrhu zasílání zpráv najdete v následujících zdrojích informací:

• Model kontroly deklarací identity
• Model konkurenčních spotřebitelů
• Model Event Sourcing
• Model kanálů a filtrů
• Model vydavatele a odběratele
• Sekvenční vzor convoy