Megosztás a következőn keresztül:

Architekturális megközelítések az üzenetkezeléshez több-bérlős megoldásokban

  • Cikk

Az aszinkron üzenetkezelés és az eseményvezérelt kommunikáció kritikus fontosságú eszközök egy több belső és külső szolgáltatásból álló elosztott alkalmazás létrehozásakor. Több-bérlős megoldás tervezésekor fontos, hogy előzetes elemzést végezzen a különböző bérlőkre vonatkozó üzenetek megosztásának vagy particionálásának meghatározásához.

Ugyanazon üzenetkezelési rendszer vagy eseménystreamelési szolgáltatás megosztása jelentősen csökkentheti az üzemeltetési költségeket és a felügyelet összetettségét. Az egyes bérlők számára dedikált üzenetkezelési rendszer használata azonban jobb adatelkülönítést tesz lehetővé, csökkenti az adatszivárgás kockázatát, kiküszöböli a Zajos szomszéd problémát, és lehetővé teszi az Azure-költségek egyszerű visszaszámlázását a bérlőknek.

Ebben a cikkben megkülönböztetheti az üzeneteket és az eseményeket, és olyan irányelveket találhat, amelyeket a megoldástervezők követhetnek, amikor eldöntik, hogy melyik megközelítést használják egy üzenetkezelési vagy eseménykezelési infrastruktúra több-bérlős megoldásokban.

Üzenetek, adatpontok és különálló események

Minden üzenetkezelési rendszer hasonló funkciókkal, átviteli protokollokkal és használati forgatókönyvekkel rendelkezik. A modern üzenetkezelési rendszerek többsége például olyan aszinkron kommunikációt támogat, amely változó vagy állandó üzenetsorokat, AMQP- és HTTPS-átviteli protokollokat, legalább egyszer történő kézbesítést stb. használ. A közzétett információk típusának és az ügyfélalkalmazások által történő felhasználásának és feldolgozásának módjával azonban jobban meg tudjuk különböztetni a különböző típusú üzeneteket és eseményeket. Alapvető különbség van az eseményt küldő szolgáltatások és az üzenetet küldő rendszerek között. További információkat találhat az alábbi forrásokban:

esemény

Az események egy állapotról vagy állapotváltozásról szóló, kis méretű értesítések. Az események lehetnek különálló egységek vagy egy sorozat részei. Az események olyan üzenetek, amelyek általában nem közvetítik a közzétevők szándékát, csak tájékoztatás. Az esemény rögzíti a tényeket, és közli azt más szolgáltatásokkal vagy összetevőkkel. Az esemény felhasználója úgy tudja feldolgozni az eseményt, ahogy tetszik, és nem felel meg a közzétevő által támasztott konkrét elvárásoknak. Az eseményeket két fő kategóriába sorolhatjuk:

  • A különálló események információkat tartalmaznak a közzétételi alkalmazás által végrehajtott konkrét műveletekről. Az aszinkron eseményvezérelt kommunikáció használatakor az alkalmazás értesítési eseményt tesz közzé, amikor valami történik a tartományán belül. Egy vagy több felhasználó alkalmazásnak tisztában kell lennie ezzel az állapotváltozással, például egy termékkatalógus-alkalmazás árváltozásával. A felhasználók előfizetnek az eseményekre, hogy aszinkron módon fogadják őket. Ha egy adott esemény bekövetkezik, a fogyasztó alkalmazások frissíthetik a tartományi entitásaikat, ami további integrációs események közzétételét okozhatja.
  • Az adatsoresemények olyan információs adatpontokat tartalmaznak, mint például az elemzéshez használt eszközök hőmérséklet-mérései vagy a kattintáselemzési megoldás felhasználói műveletei, egy folyamatos adatfolyam elemeiként. Az eseményfolyamok egy adott környezethez kapcsolódnak, például a mezőeszköz által jelentett hőmérséklethez vagy páratartalomhoz. Az ugyanahhoz a környezethez kapcsolódó összes eseménynek szigorú időbeli sorrendje van, amely az események eseményfolyam-feldolgozó motorral történő feldolgozásakor számít. Az adatpontokat tartalmazó eseményfolyamok elemzéséhez ezeket az eseményeket egy olyan pufferben kell gyűjteni, amely egy kívánt időkeretet fed le. Vagy egy közel valós idejű megoldással vagy gépi betanított algoritmussal feldolgozhatja ezeket az eseményeket egy kiválasztott számú elemben, majd feldolgozhatja őket. Az események sorozatának elemzése olyan jeleket eredményezhet, mint a küszöbértéket átlépő időablakban mért értékek átlaga. Ezek a jelek ezután különálló, végrehajtható eseményekként állíthatók elő.

A különálló események állapotváltozásokat jelentenek, és végrehajthatók. Az esemény hasznos adatai információt tartalmaznak a történtekről, de általában nem rendelkezik az eseményt kiváltó teljes adatokkal. Egy esemény például értesíti a felhasználókat, hogy egy jelentéskészítő alkalmazás új fájlt hozott létre egy tárfiókban. Előfordulhat, hogy az esemény hasznos adatai általános információkkal rendelkeznek a fájlról, de nem rendelkezik magával a fájllal. A különálló események ideális megoldást jelentenek a skálázható, kiszolgáló nélküli megoldásokhoz.

A sorozatesemények állapotot jelentenek és elemezhetők. A különálló események időrend szerint vannak rendezve, és összefüggnek egymással. Bizonyos kontextusokban a fogyasztónak az események teljes sorozatát kell megkapnia, hogy elemezze a történteket, és megtegye a szükséges lépéseket.

Üzenetek

Az üzenetek olyan nyers adatokat tartalmaznak, amelyeket egy szolgáltatás máshol használ fel vagy tárol. Az üzenetek gyakran tartalmaznak olyan információkat, amelyek szükségesek ahhoz, hogy egy fogadó szolgáltatás végrehajtsa a munkafolyamat vagy a feldolgozási lánc lépéseit. Ilyen típusú kommunikációra példa a Parancs minta. A közzétevő arra is számíthat, hogy egy üzenet fogadója(i) végrehajtanak egy műveletsort, és egy aszinkron üzenettel jelentik vissza a feldolgozásuk eredményét. Szerződés áll fenn az üzenet közzétevője és az üzenet fogadója(i) között. A közzétevő például egy üzenetet küld nyers adatokkal, és elvárja a fogyasztótól, hogy hozzon létre egy fájlt az adatokból, és amikor elkészült, küldjön vissza egy válaszüzenetet. Más helyzetekben a feladói folyamat aszinkron, egyirányú üzenetet küldhet, amely egy másik szolgáltatást kér egy adott művelet végrehajtására, de nem számít arra, hogy egy nyugtázási vagy válaszüzenetet kap tőle.

Ez a fajta szerződéses üzenetkezelés egészen más, mint egy közzétevő, aki diszkrét eseményeket tesz közzé a fogyasztói ügynökök célközönsége számára, anélkül, hogy konkrétan elvárják, hogy hogyan fogják kezelni ezeket az értesítéseket.

Példaforgatókönyvek

Íme néhány példa az üzenetek, adatpontok és különálló események több-bérlős forgatókönyveire:

  • Különálló események:
    • A zenemegosztási platform nyomon követi azt a tényt, hogy egy adott bérlő egy adott felhasználója figyelt egy adott zeneszámot.
    • Egy online áruházbeli webalkalmazásban a katalógusalkalmazás a Publisher-Előfizető minta használatával küld egy eseményt más alkalmazásoknak, hogy értesítést küldjön nekik arról, hogy egy elem ára megváltozott.
    • A gyártó vállalat valós idejű információkat küld az ügyfeleknek és harmadik feleknek a berendezések karbantartásával, a rendszerek állapotával és a szerződés frissítéseivel kapcsolatban.
  • Adatpontok:
    • Az épületfelügyeleti rendszer telemetriai eseményeket fogad, például hőmérséklet- vagy páratartalom-adatokat a több ügyfélhez tartozó érzékelőktől.
    • Az eseményvezérelt monitorozási rendszer közel valós idejű módon fogadja és dolgozza fel a diagnosztikai naplókat több szolgáltatásból, például webkiszolgálóról.
    • Egy weblap ügyféloldali szkriptje összegyűjti a felhasználói műveleteket, és elküldi őket egy kattintáselemzési megoldásnak.
  • Üzenetek:
    • A B2B pénzügyi alkalmazás üzenetet kap a bérlő banki rekordjainak feldolgozásának megkezdéséhez.
    • Egy hosszan futó munkafolyamat egy üzenetet kap, amely elindítja a következő lépés végrehajtását.
    • Egy online áruházbeli alkalmazás kosáralkalmazása createOrder parancsot küld a rendelési alkalmazásnak aszinkron, állandó üzenettel.

Főbb szempontok és követelmények

A megoldáshoz választott üzembe helyezési és bérlői modell mély hatással van a biztonságra, a teljesítményre, az adatelkülönítésre, a felügyeletre és az erőforrásköltségek bérlőkre történő keresztszámlázásának képességére. Ez az elemzés tartalmazza az üzenetkezelési és eseménykezelési infrastruktúra számára kiválasztott modellt. Ebben a szakaszban áttekintjük azokat a legfontosabb döntéseket, amelyek a több-bérlős megoldás üzenetkezelési rendszerének tervezésekor kell meghozniuk.

Hangsor

A bérlők száma, az üzenetfolyamok és az eseménystreamek összetettsége, az üzenetek mennyisége, a várt forgalmi profil és az elkülönítési szint a döntéseket az üzenetkezelési vagy eseménykezelési infrastruktúra tervezésekor kell meghozni.

Az első lépés a teljes kapacitástervezés és az üzenetkezelési rendszer számára szükséges maximális kapacitás meghatározása az átviteli sebesség tekintetében a normál vagy csúcsforgalomban várható üzenetek megfelelő kezeléséhez.

Egyes szolgáltatásajánlatok, például az Azure Service Bus Premium szint, erőforrás-elkülönítést biztosítanak a CPU és a memória szintjén, hogy minden ügyfél számítási feladatai külön fussanak. Ennek az erőforrás-tárolónak a neve üzenetkezelési egység. Legalább egy üzenetkezelési egység van lefoglalva minden prémium névtérhez. Minden Service Bus Premium-névtérhez 1, 2, 4, 8 vagy 16 üzenetkezelési egységet vásárolhat. Egyetlen számítási feladat vagy entitás több üzenetkezelési egységre is kiterjedhet, és szükség szerint módosíthatja az üzenetkezelési egységek számát. Az eredmény a Service Bus-alapú megoldás kiszámítható és megismételhető teljesítménye. További információ: Service Bus Premium és Standard üzenetkezelési szintek. Hasonlóképpen, az Azure Event Hubs tarifacsomagjai lehetővé teszik a névtér méretezését a bejövő és kimenő események várható mennyisége alapján. A Prémium ajánlat számlázása például feldolgozási egységek (PU-k) alapján történik, amelyek az alapul szolgáló infrastruktúrában lévő elkülönített erőforrások (CPU, memória és tárterület) egy részének felelnek meg. A tényleges betöltési és stream-átviteli sebesség pu-nként a következő tényezőktől függ:

  • Termelők és fogyasztók száma
  • Hasznos adat mérete
  • Partíciók száma
  • Kimenő kérések aránya
  • Az Event Hubs Capture, a Sémaregisztrációs adatbázis és más speciális funkciók használata

További információ: Az Event Hubs Premium áttekintése.

Ha a megoldás jelentős számú bérlőt kezel, és ön úgy dönt, hogy minden bérlőhöz külön üzenetkezelő rendszert vezet be, konzisztens stratégiával kell rendelkeznie az egyes infrastruktúrák üzembe helyezésének, figyelésének, riasztásának és skálázásának automatizálásához, függetlenül egymástól.

Például egy adott bérlő üzenetkezelési rendszere üzembe helyezhető a kiépítési folyamat során egy infrastruktúra mint kód (IaC) eszközzel, például Terraform, Bicep vagy Azure Resource Manager (ARM) JSON-sablonokkal és egy DevOps-rendszerrel, például az Azure DevOps vagy a GitHub Actions használatával. További információkért tekintse meg a több-bérlős megoldások üzembe helyezésének és konfigurálásának architekturális megközelítéseit.

Az üzenetkezelő rendszer mérete az üzenetek maximális átviteli sebességével méretezhető egységenként. Ha a rendszer támogatja a dinamikus automatikus skálázást, a kapacitása a forgalmi feltételek és metrikák alapján automatikusan növelhető vagy csökkenthető a várt szolgáltatásiszint-szerződés teljesítéséhez.

A teljesítmény kiszámíthatósága és megbízhatósága

Ha korlátozott számú bérlő számára tervez és épít ki üzenetkezelési rendszert, egyetlen üzenetkezelési rendszer használata kiváló megoldás lehet a funkcionális követelményeknek való megfelelésre az átviteli sebesség szempontjából, és csökkentheti a teljes tulajdonjogi költséget. A több-bérlős alkalmazások ugyanazokat az üzenetkezelési entitásokat, például üzenetsorokat és témaköröket oszthatják meg több ügyfél között. Vagy használhatnak dedikált összetevőket mindegyikhez a bérlői elkülönítés növelése érdekében. Másrészt, ha ugyanazt az üzenetkezelési infrastruktúrát több bérlő között osztják meg, a teljes megoldást elérhetővé teheti a Zajos szomszéd probléma számára. Az egyik bérlő tevékenysége a teljesítmény és az működőképesség szempontjából árthat a többi bérlőnek.

Ebben az esetben az üzenetkezelő rendszernek megfelelő méretűnek kell lennie, hogy fenntartsa a várt forgalomterhelést csúcsidőben. Ideális esetben támogatnia kell az automatikus skálázást. Az üzenetkezelő rendszernek dinamikusan fel kell méreteznie, amikor a forgalom növekszik, és a forgalom csökkenésekor skálázható fel. Az egyes bérlők dedikált üzenetkezelési rendszere szintén csökkentheti a zajos szomszéd kockázatát, de a sok üzenetkezelési rendszer kezelése növelheti a megoldás összetettségét.

A több-bérlős alkalmazások végül hibrid megközelítést alkalmazhatnak, ahol az alapvető szolgáltatások ugyanazt az üzenetsorokat és témaköröket használják egyetlen megosztott üzenetkezelő rendszerben a belső, aszinkron kommunikáció megvalósítása érdekében. Ezzel szemben más szolgáltatások dedikált üzenetkezelési entitásokat vagy akár dedikált üzenetkezelő rendszert is alkalmazhatnak minden bérlő számára, hogy enyhítsék a Zajos szomszéd problémát, és garantálják az adatok elkülönítését.

Üzenetkezelési rendszer virtuális gépeken való üzembe helyezésekor ezeket a virtuális gépeket a számítási erőforrásokkal együtt kell elhelyeznie a hálózati késés csökkentése érdekében. Ezeket a virtuális gépeket nem szabad más szolgáltatásokkal vagy alkalmazásokkal megosztani, hogy az üzenetkezelési infrastruktúra ne versenyezzen a rendszererőforrásokkal, például a PROCESSZORRAL, a memóriával és a hálózati sávszélességgel más rendszerekkel. A virtuális gépek a rendelkezésre állási zónákra is kiterjedhetnek, hogy növeljék a régión belüli rugalmasságot és az üzletileg kritikus fontosságú számítási feladatok megbízhatóságát, beleértve az üzenetkezelési rendszereket is. Tegyük fel, hogy úgy dönt, hogy virtuális gépeken üzemeltet egy üzenetkezelő rendszert, például a RabbitMQ-t vagy az Apache ActiveMQ-t. Ebben az esetben javasoljuk, hogy helyezze üzembe egy virtuálisgép-méretezési csoportban, és konfigurálja az automatikus skálázáshoz olyan metrikák alapján, mint a CPU vagy a memória. Így az üzenetkezelési rendszert üzemeltető ügynökcsomópontok száma megfelelően felskálázható és skálázható lesz a forgalmi feltételek alapján. További információ: Az Azure-beli virtuálisgép-méretezési csoportok automatikus skálázásának áttekintése.

Hasonlóképpen, ha egy Kubernetes-fürtön üzemelteti az üzenetkezelő rendszert, fontolja meg csomópontválasztók és -tárolók használatát a podok dedikált csomópontkészleten való végrehajtásának ütemezéséhez, nem pedig más számítási feladatokkal megosztva, a zajos szomszéd probléma elkerülése érdekében. Amikor egy üzenetkezelő rendszert zónaredundáns AKS-fürtön helyez üzembe, podtopológia-eloszlási korlátozások használatával szabályozhatja, hogy a podok hogyan legyenek elosztva az AKS-fürtön a hibatartományok, például régiók, rendelkezésre állási zónák és csomópontok között. Ha külső üzenetkezelő rendszert üzemeltet az AKS-en, a Kubernetes automatikus skálázásával dinamikusan felskálázhatja a feldolgozó csomópontok számát a forgalom növekedésekor. A horizontális pod-automatikus skálázás és az AKS-fürt automatikus skálázása révén a csomópont- és podkötetek dinamikusan, valós időben módosulnak, hogy megfeleljenek a forgalmi feltételeknek, és elkerüljék a kapacitásproblémák által okozott állásidőket. További információ: Fürt automatikus méretezése az Azure Kubernetes Service (AKS) alkalmazásigényeinek megfelelően. Érdemes lehet a Kubernetes páros alapú automatikus skálázását (KEDA) használni, ha egy Kubernetes által üzemeltetett üzenetkezelő rendszer podjainak (például a RabbitMQ-nak vagy az Apache ActiveMQ-nak) a számát szeretné skálázni egy adott üzenetsor hossza alapján. A KEDA használatával a Kubernetes bármely tárolójának méretezhető a feldolgozandó események száma alapján. A KEDA használatával például skálázhatja az alkalmazásokat egy Azure Service Bus-üzenetsor, egy RabbitMQ-üzenetsor vagy egy ActiveMQ-üzenetsor hossza alapján. További információ a KEDA-ról: Kubernetes Eseményvezérelt automatikus skálázás.

Elkülönítés

A több-bérlős megoldások üzenetkezelési rendszerének tervezésekor figyelembe kell venni, hogy a különböző típusú alkalmazások eltérő elkülönítést igényelnek, amely a bérlők teljesítményére, adatvédelmi és naplózási követelményeire épül.

  • Több bérlő is megoszthatja ugyanazokat az üzenetkezelési entitásokat, például üzenetsorokat, témaköröket és előfizetéseket ugyanabban az üzenetkezelési rendszerben. Egy több-bérlős alkalmazás például több bérlő adatait tartalmazó üzeneteket fogadhat egyetlen Azure Service Bus-üzenetsorból . Ez a megoldás teljesítmény- és méretezhetőségi problémákhoz vezethet. Ha egyes bérlők nagyobb mennyiségű megrendelést generálnak, mint mások, az üzenetek elmaradásához vezethet. Ez a probléma, más néven a Zajos szomszéd probléma, csökkentheti a szolgáltatásiszint-szerződést egyes bérlők késése szempontjából. A probléma nyilvánvalóbb, ha a fogyasztói alkalmazás egyenként, szigorú időrendi sorrendben olvassa és dolgozza fel az üzeneteket az üzenetsorból, és ha az üzenet feldolgozásához szükséges idő a hasznos adat elemeinek számától függ. Ha több bérlő között oszt meg egy vagy több üzenetsor-erőforrást, az üzenetkezelési infrastruktúrának és a feldolgozási rendszereknek képesnek kell lenniük a méretezési és átviteli sebességre vonatkozó követelményeken alapuló elvárt forgalom kiszolgálására. Ez az architekturális megközelítés jól alkalmazható azokban a helyzetekben, amikor egy több-bérlős megoldás egyetlen feldolgozói folyamatkészletet fogad, dolgoz fel és küld üzeneteket az összes bérlő számára.
  • Több bérlő ugyanazt az üzenetkezelési rendszert használja, de különböző témakör- vagy üzenetsor-erőforrásokat használ. Ez a megközelítés jobb elkülönítést és adatvédelmet biztosít magasabb költséggel, nagyobb üzemeltetési összetettséggel és alacsonyabb rugalmasságtal, mivel a rendszergazdáknak nagyobb számú üzenetsor-erőforrást kell kiépíteniük, figyelniük és karbantartanak. Ez a megoldás konzisztens és kiszámítható élményt biztosít minden bérlő számára a teljesítmény és a szolgáltatási szintű szerződések tekintetében, mivel megakadályozza, hogy bármely bérlő olyan szűk keresztmetszetet hozzon létre, amely hatással lehet a többi bérlőre.
  • Minden bérlőhöz külön, dedikált üzenetkezelő rendszert használunk. A több-bérlős megoldások például külön Azure Service Bus-névteret használhatnak minden bérlőhöz. Ez a megoldás a maximális elkülönítési fokot biztosítja, nagyobb összetettséggel és üzemeltetési költséggel. Ez a megközelítés garantálja a konzisztens teljesítményt, és lehetővé teszi az üzenetkezelési rendszer finomhangolását adott bérlői igények alapján. Új bérlő bevezetésekor a teljes mértékben dedikált üzenetkezelési rendszer mellett a kiépítési alkalmazásnak is létre kell hoznia egy külön felügyelt identitást vagy egy szolgáltatásnevet, amely megfelelő RBAC-engedélyekkel rendelkezik az újonnan létrehozott névtér eléréséhez. Ha például egy Kubernetes-fürtöt ugyanazon SaaS-alkalmazás több példánya oszt meg, minden bérlőhöz egyet, és mindegyik külön névtérben fut, minden alkalmazáspéldány más szolgáltatásnévvel vagy felügyelt identitással érhet el egy dedikált üzenetkezelő rendszert. Ebben az összefüggésben az üzenetkezelő rendszer lehet egy teljes mértékben felügyelt PaaS-szolgáltatás, például egy Azure Service Bus-névtér vagy egy Kubernetes által üzemeltetett üzenetkezelő rendszer, például a RabbitMQ. Ha töröl egy bérlőt a rendszerből, az alkalmazásnak el kell távolítania az üzenetkezelő rendszert és a bérlő számára korábban létrehozott dedikált erőforrást. Ennek a megközelítésnek a fő hátránya, hogy növeli a működési összetettséget és csökkenti az agilitást, különösen akkor, ha a bérlők száma idővel növekszik.

Tekintse át a következő további szempontokat és észrevételeket:

  • Ha a bérlőknek saját kulcsot kell használniuk az üzenetek titkosításához és visszafejtéséhez, a több-bérlős megoldásnak lehetőséget kell biztosítania arra, hogy minden bérlőhöz külön Azure Service Bus Premium-névteret vezessen be. További információ: Ügyfél által felügyelt kulcsok konfigurálása az Azure Service Bus-adatok inaktív állapotban történő titkosításához.
  • Ha a bérlőknek magas szintű rugalmasságra és üzletmenet-folytonosságra van szükségük, a több-bérlős megoldásnak lehetővé kell tennie egy Service Bus Premium-névtér kiépítését georeduktúra-helyreállítási és rendelkezésre állási zónákkal . További információ: Azure Service Bus Geo-vészhelyreállítás.
  • Ha minden bérlőhöz külön üzenetsor-erőforrásokat vagy dedikált üzenetkezelési rendszert használ, célszerű külön feldolgozói folyamatokat létrehozni, amelyek mindegyike növeli az adatelkülönítés szintjét, és csökkenti a több üzenetkezelési entitás kezelésének összetettségét. A feldolgozó rendszer minden példánya különböző hitelesítő adatokat, például kapcsolati sztring, szolgáltatásnevet vagy felügyelt identitást alkalmazhat a dedikált üzenetkezelő rendszer eléréséhez. Ez a megközelítés jobb biztonsági szintet és elkülönítést biztosít a bérlők között, de az identitáskezelés nagyobb összetettséget igényel.

Hasonlóképpen, az eseményvezérelt alkalmazások különböző elkülönítési szinteket biztosíthatnak:

  • Egy eseményvezérelt alkalmazás több bérlőtől fogad eseményeket egyetlen, megosztott Azure Event Hubs-példányon keresztül. Ez a megoldás magas szintű rugalmasságot biztosít, mivel az új bérlők előkészítése nem igényel dedikált eseménybetöltési erőforrást, de alacsony adatvédelmi szintet biztosít, mivel több bérlőtől származó üzeneteket illeszt be ugyanabban az adatstruktúrában.
  • A bérlők választhatnak egy dedikált eseményközpontot vagy Kafka-témakört, hogy elkerüljék a Zajos szomszéd problémát , és megfeleljenek az adatelkülönítési követelményeknek, amikor az eseményeket nem szabad más bérlőkkel együtt használni a biztonság és az adatvédelem érdekében.
  • Ha a bérlőknek magas szintű rugalmasságra és üzletmenet-folytonosságra van szükségük, a több-bérlőnek lehetővé kell tennie egy Event Hubs Premium-névtér kiépítését, engedélyezve a georeduktúra-helyreállítást és a rendelkezésre állási zónákat . További információ: Azure Event Hubs – Geo-vészhelyreállítás.
  • Dedikált Eseményközpontokat kell létrehozni, amelyeken engedélyezve van az Event Hubs Capture, azoknak az ügyfeleknek, akiknek az eseményeket egy Azure Storage-fiókba kell archiválniuk jogszabályi megfelelőségi okokból és kötelezettségek miatt. További információ: Események rögzítése az Azure Event Hubson keresztül az Azure Blob Storage-ban vagy az Azure Data Lake Storage-ban.
  • Egyetlen több-bérlős alkalmazás több belső és külső rendszernek küldhet értesítéseket az Azure Event Grid használatával. Ebben az esetben minden egyes fogyasztói alkalmazáshoz külön Event Grid-előfizetést kell létrehozni. Ha az alkalmazás több Event Grid-példány használatával küld értesítéseket számos külső szervezetnek, fontolja meg az eseménytartományok használatát, amelyek lehetővé teszik, hogy az alkalmazás eseményeket tegyen közzé több ezer témakörben, például egy-egy bérlőn. További információt az Event Grid-témakörök kezelésével kapcsolatos eseménytartományok ismertetése című témakörben talál.

A megvalósítás összetettsége

Több-bérlős megoldás tervezésekor fontos figyelembe venni, hogy a rendszer közép- és hosszú távon hogyan fog fejlődni, hogy ne nőjön az összetettsége az idő múlásával, amíg át nem kell tervezni a megoldás egy részét vagy a teljes megoldást. Ez az újratervezés segít megbirkózni a bérlők számának növekedésével. Az üzenetkezelési rendszer tervezésekor figyelembe kell vennie az üzenetkötetek és bérlők várható növekedését a következő néhány évben, majd létre kell hoznia egy horizontálisan felskálázható rendszert, hogy lépést tartson az előre jelzett forgalommal, és csökkentse a műveletek összetettségét, például a kiépítést, a monitorozást és a karbantartást.

A megoldásnak automatikusan létre kell hoznia vagy törölnie kell a szükséges üzenetküldő entitásokat minden alkalommal, amikor a bérlői alkalmazás ki van építve vagy ki van építve, manuális műveletek nélkül.

A több-bérlős adatmegoldások esetében különösen fontos a támogatott testreszabási szint. Minden testreszabást automatikusan konfigurálnia és alkalmaznia kell az alkalmazáskiépítési rendszernek (például egy DevOps-rendszernek), amely a kezdeti paraméterek készletén alapul, amikor egy egy-bérlős vagy több-bérlős alkalmazást helyez üzembe.

A felügyelet és a műveletek összetettsége

A kezdetektől tervezze meg, hogyan kívánja üzemeltetni, monitorozni és karbantartani az üzenetkezelési és eseménykezelési infrastruktúrát, valamint hogy a több-bérlős megközelítés hogyan befolyásolja a műveleteket és folyamatokat. Vegyük például a következő lehetőségeket:

  • Előfordulhat, hogy az alkalmazás által használt üzenetkezelő rendszert egy dedikált virtuális gépcsoportban szeretné üzemeltetni, egy-egy bérlő számára. Ha igen, hogyan tervezi üzembe helyezni, frissíteni, monitorozni és méretezni ezeket a rendszereket?
  • Hasonlóképpen, ha megosztott Kubernetes-fürtön tárolja és üzemelteti az üzenetkezelő rendszert, hogyan tervezi az egyes üzenetkezelési rendszerek üzembe helyezését, frissítését, monitorozását és méretezését?
  • Tegyük fel, hogy egy üzenetkezelő rendszert több bérlőn is megoszt. Hogyan gyűjtheti és jelentheti a megoldás a bérlőnkénti használati metrikákat, vagy hogyan szabályozhatja az egyes bérlők által küldött vagy fogadott üzenetek számát?
  • Ha az üzenetkezelő rendszer egy PaaS-szolgáltatást használ, például az Azure Service Bust, tegye fel a következő kérdést:
    • Hogyan szabhatja testre az egyes bérlők tarifacsomagját a bérlő által kért szolgáltatások és elkülönítési szint (megosztott vagy dedikált) alapján?
    • Hogyan hozhat létre bérlőnkénti identitás- és Azure-szerepkör-hozzárendelést, hogy csak a megfelelő engedélyeket rendelje hozzá az üzenetküldési entitásokhoz, például üzenetsorokhoz, témakörökhöz és előfizetésekhez, amelyeket a bérlő hozzáférhet? További információ: Felügyelt identitás hitelesítése a Microsoft Entra-azonosítóval az Azure Service Bus-erőforrások eléréséhez.
  • Hogyan migrálja a bérlőket, ha más típusú üzenetkezelési szolgáltatásra, másik üzembe helyezésre vagy másik régióra kell áttérniük?

Költség

Általában minél nagyobb a bérlők sűrűsége az üzembehelyezési infrastruktúrában, annál alacsonyabb az infrastruktúra kiépítésének költsége. A megosztott infrastruktúra azonban növeli az olyan problémák valószínűségét, mint a Zajos szomszéd probléma, ezért gondosan fontolja meg a kompromisszumokat.

Megfontolandó megközelítések és minták

Az Azure Architecture Center számos felhőtervezési mintája alkalmazható több-bérlős üzenetkezelési rendszerekre. Dönthet úgy, hogy egy vagy több mintát következetesen követ, vagy megfontolhatja a minták keverését és egyeztetését az igényeinek megfelelően. Használhat például egy több-bérlős Service Bus-névteret a legtöbb bérlőjéhez, de egy dedikált, egybérlős Service Bus-névteret is üzembe helyezhet azoknak a bérlőknek, akik többet fizetnek, vagy magasabb követelményekkel rendelkeznek, az elkülönítés vagy a teljesítmény szempontjából. Hasonlóképpen gyakran ajánlott üzembehelyezési bélyegek használatával skálázni, még akkor is, ha több-bérlős Service Bus-névteret vagy dedikált névteret használ egy bélyegen belül.

Üzembehelyezési bélyegek mintája

Az üzembehelyezési bélyegek mintájáról és a több-bérlősségről további információt a több-bérlős architekturális megközelítések Üzembehelyezési bélyegek minta szakaszában talál. A bérlői modellekkel kapcsolatos további információkért tekintse meg a bérlői modelleket, amelyeket érdemes megfontolni egy több-bérlős megoldáshoz.

Megosztott üzenetkezelő rendszer

Érdemes lehet üzembe helyezni egy megosztott üzenetkezelő rendszert, például az Azure Service Bust, és megosztani azt az összes bérlőn.

Az összes bérlő egyetlen megosztott több-bérlős üzenetkezelési rendszerét bemutató ábra.

Ez a megközelítés biztosítja a bérlők legnagyobb sűrűségét az infrastruktúrához, így csökkenti a teljes tulajdonjogi költséget. Emellett gyakran csökkenti a felügyeleti többletterhelést is, mivel egyetlen üzenetkezelő rendszer vagy erőforrás van a felügyelet és a biztonság érdekében.

Ha azonban több bérlő között oszt meg egy erőforrást vagy egy teljes infrastruktúrát, vegye figyelembe a következő kikötéseket:

  • Mindig vegye figyelembe és vegye figyelembe a szóban forgó erőforrás korlátait, skálázási képességeit, kvótáit és korlátait. Előfordulhat például, hogy egy Azure-előfizetésben a Service Bus-névterek maximális száma, az egyetlen névtérben található Event Hubs maximális száma vagy a maximális átviteli sebességkorlátok végül kemény blokkolóvá válhatnak, ha és amikor az architektúra egyre több bérlőt támogat. Gondosan gondolja át, hogy az egyes Azure-előfizetések névtereinek száma vagy az egy névtérre jutó üzenetsorok maximális méretet kell-e elérnie. Ezután hasonlítsa össze a jelenlegi és jövőbeli becsléseit a választott üzenetkezelési rendszer meglévő kvótáival és korlátaival, mielőtt kiválasztaná ezt a mintát.
  • Ahogy a fenti szakaszokban is említettük, a Zajos szomszéd probléma tényezővé válhat, ha egy erőforrást több bérlő között oszt meg, különösen akkor, ha egyes bérlők különösen elfoglaltak, vagy ha nagyobb forgalmat generálnak, mint mások. Ebben az esetben érdemes lehet a szabályozási mintát vagy a sebességkorlátozó mintát alkalmazni a hatások enyhítésére. Korlátozhatja például az egyetlen bérlő által az időegységben küldhető vagy fogadott üzenetek maximális számát.
  • Előfordulhat, hogy nehézségekbe ütközik a tevékenység monitorozása és az egyetlen bérlő erőforrás-felhasználásának mérése. Egyes szolgáltatások, például az Azure Service Bus, az üzenetkezelési műveletekért díjat számítanak fel. Ezért ha több bérlő között oszt meg névteret, az alkalmazásnak képesnek kell lennie nyomon követni az egyes bérlők nevében végzett üzenetkezelési műveletek számát és a nekik járó költségtérítési költségeket. Más szolgáltatások nem biztosítják ugyanazt a részletességi szintet.

A bérlők eltérő követelményekkel rendelkezhetnek a biztonságra, a régión belüli rugalmasságra, a vészhelyreállításra vagy a helyszínre vonatkozóan. Ha ezek nem felelnek meg az üzenetkezelési rendszer konfigurációjának, előfordulhat, hogy nem tudja őket egyetlen erőforrással elszállásolni.

Horizontális particionálási minta

A horizontális skálázási minta magában foglalja több üzenetkezelési rendszer, úgynevezett szegmensek üzembe helyezését, amelyek egy vagy több bérlő üzenetkezelési entitását, például üzenetsorokat és témaköröket tartalmaznak. Az üzembehelyezési bélyegekkel ellentétben a szegmensek nem azt jelentik, hogy a teljes infrastruktúra duplikálva van. Előfordulhat, hogy a megoldás más infrastruktúráinak duplikálása vagy horizontális skálázása nélkül is szilánkos üzenetkezelési rendszereket hoz létre.

Szilánkos üzenetkezelő rendszert bemutató ábra. Az egyik üzenetkezelő rendszer az A és B bérlők üzenetsorait, a másik pedig a C bérlő üzenetsorait tartalmazza.

Minden üzenetkezelési rendszer vagy szegmens különböző tulajdonságokkal rendelkezhet a megbízhatóság, az SKU és a hely szempontjából. A bérlőket például több különböző tulajdonságokkal rendelkező üzenetkezelési rendszeren is skálázhatja, a helyük vagy az igényeik alapján a teljesítmény, a megbízhatóság, az adatvédelem vagy az üzletmenet folytonossága szempontjából.

A horizontális skálázási minta használatakor horizontális skálázási stratégiát kell használnia ahhoz, hogy egy adott bérlőt leképezhessen az üzenetsorokat tartalmazó üzenetkezelő rendszerbe. A keresési stratégia egy térképet használ a célüzenet-kezelő rendszer felosztásához a bérlő neve vagy azonosítója alapján. Előfordulhat, hogy több bérlő ugyanazt a szegmenst használja, de az egyetlen bérlő által használt üzenetkezelési entitások nem lesznek több szegmensben elosztva. A térkép egyetlen szótárral valósítható meg, amely leképozza a bérlő nevét a célüzenet-kezelő rendszer nevére vagy hivatkozására. A térkép tárolható egy elosztott gyorsítótárban, amely egy több-bérlős alkalmazás összes példánya számára elérhető, vagy egy állandó tárolóban, például egy relációs adatbázisban lévő táblában vagy egy tárfiók táblájában.

A horizontális skálázási minta nagy számú bérlőre méretezhető. Emellett a számítási feladattól függően előfordulhat, hogy a bérlők nagy sűrűségű szegmenseket tudnak létrehozni, így a költségek vonzóak lehetnek. A horizontális skálázási minta az Azure-előfizetések és szolgáltatáskvóták, korlátok és korlátozások kezelésére is használható.

Több-bérlős alkalmazás dedikált üzenetkezelési rendszerrel minden bérlőhöz

Egy másik gyakori módszer egy több-bérlős alkalmazás üzembe helyezése minden bérlőhöz dedikált üzenetkezelési rendszerekkel. Ebben a bérlői modellben van néhány megosztott összetevő, például a számítási erőforrások, míg más szolgáltatások kiépítése és kezelése egy bérlős, dedikált üzembe helyezési megközelítéssel történik. Létrehozhat például egy alkalmazásszintet, majd üzembe helyezheti az egyes bérlők egyedi üzenetkezelési rendszereit az alábbi ábrán látható módon.

Diagram az egyes bérlők különböző üzenetkezelési rendszereiről.

A horizontálisan particionált üzemelő példányok segíthetnek a zajos szomszédokkal kapcsolatos problémák megoldásában, ha azt észlelte, hogy a rendszer terhelésének nagy része az egyes bérlők számára külön üzembe helyezhető összetevőknek köszönhető. Előfordulhat például, hogy minden bérlőhöz külön üzenet- vagy eseménystreamelési rendszert kell használnia, mivel egyetlen példány nem elegendő a több bérlő által generált forgalom fenntartásához. Ha minden bérlőhöz dedikált üzenetkezelési rendszert használ, ha egy bérlő nagy mennyiségű üzenetet vagy eseményt okoz, az hatással lehet a megosztott összetevőkre, más bérlők üzenetkezelési rendszereire azonban nem.

Mivel minden bérlőhöz dedikált erőforrásokat épít ki, ennek a megközelítésnek a költsége magasabb lehet, mint egy megosztott üzemeltetési modell. Ezzel szemben a bérlői modell bevezetésekor egyszerűbb a dedikált rendszer erőforrásköltségeinek visszaszámlázása az azt használó egyedi bérlőre. Ez a megközelítés lehetővé teszi, hogy nagy sűrűséget érjen el más szolgáltatások, például a számítási erőforrások esetében, és csökkenti ezeknek az összetevőknek a költségeit.

Horizontálisan particionált üzembe helyezés esetén automatizált folyamatot kell bevezetnie a több-bérlős alkalmazások szolgáltatásainak üzembe helyezéséhez és kezeléséhez, különösen azokat, amelyeket egyetlen bérlő használ.

Geodéziai minta

A Geode-minta magában foglalja a háttérszolgáltatások gyűjteményének üzembe helyezését egy földrajzi csomópontok halmazában. Mindegyik bármilyen kérést kiszolgálhat bármely régióban lévő ügyfél számára. Ez a minta lehetővé teszi a kérések aktív-aktív stílusban történő kiszolgálását, amely javítja a késést és növeli a rendelkezésre állást a kérésfeldolgozás világszerte történő elosztásával.

A Geode-mintát ábrázoló diagram, amelyben több régióban üzembe helyezett üzenetkezelési rendszerek szinkronizálódnak.

Az Azure Service Bus és az Azure Event Hubs támogatja a metaadatok vészhelyreállítását az elsődleges és másodlagos vészhelyreállítási névterekben, valamint a különböző régiókban és rendelkezésre állási zónákban, hogy támogatást nyújtson a régión belüli legjobb rugalmassághoz. Emellett az Azure Service Bus és az Azure Event Hubs olyan összevonási mintákat implementál, amelyek aktívan replikálják ugyanazt a logikai témakört, üzenetsort vagy eseményközpontot, hogy több névtérben is elérhetők legyenek, amelyek végül különböző régiókban találhatók. További információkat találhat az alábbi forrásokban:

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

  • Paolo Salvatori | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

Egyéb közreműködők:

Következő lépések

Az üzenetkezelési tervezési mintákról az alábbi forrásokban talál további információt: