Üzenetreplikáció és régiók közötti összevonás
A névtereken belül a Azure Service Bus támogatja a láncolt üzenetsorok és témakör-előfizetések topológiáinak létrehozását automatikus előtér-beállítással a különböző útválasztási minták implementálásához. Például dedikált üzenetsorokat biztosíthat a partnereknek, amelyekhez engedélyekkel rendelkeznek, és amelyek szükség esetén ideiglenesen felfüggeszthetők, és rugalmasan csatlakoztathatók az alkalmazáshoz privát entitásokhoz. Összetett többszakaszos útválasztási topológiákat is létrehozhat, vagy postaláda stílusú üzenetsorokat is létrehozhat, amelyek kiürítik a témakörök üzenetsorszerű előfizetéseit, és előfizetőnként több tárkapacitást biztosítanak.
Számos kifinomult megoldás esetében az üzeneteket is replikálni kell a névtérhatárok között ezeknek és más mintáknak a megvalósítása érdekében. Előfordulhat, hogy az üzeneteknek több, különböző alkalmazásbérlőhöz társított névterek között vagy több, különböző Azure-régióban kell áthaladnia.
A megoldás több Service Bus-névteret tart fenn különböző régiókban, és üzeneteket replikál az üzenetsorok és a témakörök között, és/vagy olyan forrásokkal és célokkal fog üzeneteket cserélni, mint a Azure Event Hubs, a Azure IoT Hub vagy az Apache Kafka.
Ezek a forgatókönyvek a cikk középpontjában állnak.
Összevonási minták
Számos lehetséges oka lehet annak, hogy miért érdemes üzeneteket áthelyezni Service Bus-entitások, például üzenetsorok vagy témakörök, illetve a Service Bus és más források és célok között.
Az Event Hubs hasonló mintáihoz képest az üzenetsorszerű entitások összevonása összetettebb, mivel az üzenetsorok kizárólagos tulajdonjogot ígérnek a fogyasztóknak egyetlen üzenettel szemben, az üzenetkézbesítés során meg kell őrizniük az érkezési sorrendet, és hogy a közvetítő koordinálja az üzenetek tisztességes elosztását a versengő fogyasztók között.
Vannak olyan gyakorlati akadályok, köztük a KAP-tétel korlátai, amelyek megnehezítik a több régióban egyidejűleg elérhető üzenetsor egységes nézetének biztosítását, és amelyek lehetővé teszik, hogy a regionálisan elosztott, versengő fogyasztók kizárólagos tulajdonjogot vállaljanak az üzenetekért. Egy ilyen földrajzilag elosztott üzenetsorhoz nem csak az üzenetek, hanem az üzenetek kézbesítési állapota is teljes mértékben konzisztens replikációt igényelne, mielőtt az üzenetek elérhetővé válnának a fogyasztók számára. A hipotetikus, regionálisan elosztott üzenetsorok teljes konzisztenciájának célja közvetlenül ütközik azzal a fő céllal, amelyet gyakorlatilag minden Azure Service Bus ügyfél az összevonási forgatókönyvek mérlegelésekor: A megoldások maximális rendelkezésre állása és megbízhatósága.
Az itt bemutatott minták ezért a rendelkezésre állásra és a megbízhatóságra összpontosítanak, ugyanakkor az üzenetek adatvesztésének és duplikált kezelésének legjobb elkerülését is célul tűzik ki.
Rugalmasság a regionális rendelkezésre állási események ellen
Bár a maximális rendelkezésre állás és a megbízhatóság a Service Bus legfontosabb üzemeltetési prioritása, mégis számos módon akadályozható meg, hogy egy gyártó vagy fogyasztó hálózatkezelési vagy névfeloldási problémák miatt beszéljen a hozzárendelt "elsődleges" Service Bustal, vagy ha a Service Bus-entitás átmenetileg nem válaszol vagy hibákat ad vissza. Előfordulhat, hogy a kijelölt üzenetfeldolgozó is elérhetetlenné válik.
Az ilyen feltételek nem olyan "katasztrofálisak", hogy teljesen fel szeretné hagyni a regionális üzembe helyezést, mint egy vészhelyreállítási helyzetben, de egyes alkalmazások üzleti forgatókönyvét már érinthetik a rendelkezésre állási események, amelyek legfeljebb néhány percig vagy akár másodpercig tartanak. Azure Service Bus gyakran használják hibrid felhőkörnyezetekben és a hálózati peremhálózaton található ügyfeleknél, például kiskereskedelmi üzletekben, éttermekben, bankfiókokban, gyártóhelyeken, logisztikai létesítményekben és repülőtereken. Előfordulhat, hogy egy hálózati útválasztási vagy torlódási probléma hatással van arra, hogy egy hely elérje a hozzárendelt Service Bus-végpontot, míg egy másik régióban lévő másodlagos végpont elérhető lehet. Ugyanakkor az ezekről a helyekről érkező üzeneteket feldolgozó rendszerek továbbra is akadálytalanul hozzáférhetnek az elsődleges és a másodlagos Service Bus-végpontokhoz is.
Számos gyakorlati példa van az ilyen hibrid felhőbeli és peremalkalmazásokra, amelyek alacsony üzleti tűréshatárral bírnak a hálózati útválasztási problémák vagy a Service Bus-entitások átmeneti rendelkezésre állási problémáira gyakorolt hatás szempontjából. Ezek közé tartozik a kiskereskedelmi helyeken történő fizetések feldolgozása, a reptéri kapuknál való beszállás és az éttermekben történő mobiltelefon-rendelések, amelyek mindegyike azonnal elérhető, és teljes leállást, amikor a megbízható kommunikációs útvonal nem érhető el.
Ebben a kategóriában három különböző elosztott mintát ismertetünk: "all-active" replikációt, "aktív-passzív" replikációt és "kiömlött" replikációt.
All-Active replikáció
Az "all-active" replikációs minta lehetővé teszi, hogy ugyanannak a logikai témakörnek (vagy üzenetsornak) egy aktív replikája több névtérben (és régióban) is elérhető legyen, és hogy az összes üzenet elérhetővé váljon az összes replikában, függetlenül attól, hogy hol lettek beolvasva. A minta általában megőrzi az üzenetek sorrendjét bármely közzétevőhöz viszonyítva.
Ahogy az ábrán is látható, a minta általában a Service Bus-témakörökre támaszkodik. Egy témakör minden olyan névtérhez, amely részt vesz a replikációs sémában. Ezen témakörök mindegyike rendelkezik egy "replikációs előfizetéssel" azokhoz a témakörökhöz, amelyekre az üzeneteket replikálni kell. A fenti ábrán egyszerűen csak egy témakörpár van, ezért egyetlen replikációs előfizetéssel rendelkezünk a megfelelő másik témakörhöz. Egy három névteret ({n1, n2, n3}) tartalmazó forgatókönyvben az n1 névtér egyik témaköre két replikációs előfizetéssel rendelkezik, egyet a megfelelő témakörhöz az n2-ben , egyet pedig az n3 megfelelő témaköréhez.
Minden replikációs előfizetéshez tartozik egy szabály, amely egy SQL-szűrőkifejezést () és egy SQL-műveletet (replicated <> 1set replicated = 1) kombinál. A szabály szűrője biztosítja, hogy csak azok az üzenetek legyenek jogosultak erre az előfizetésre, amelyeknél az egyéni tulajdonság replication nincs beállítva, vagy nem rendelkezik az értékkel 1 , és a művelet ezt a tulajdonságot közvetlenül ezután az egyes kijelölt üzenetek értékére 1 állítja be. Ennek az az oka, hogy amikor az üzenetet a megfelelő témakörbe másolja, az már nem jogosult az ellenkező irányba történő replikációra, ezért elkerüljük a replikák közötti pattogó üzeneteket.
A megfelelő szabmánnyal rendelkező előfizetések egyszerűen hozzáadhatók bármely témakörhöz az Azure CLI használatával.
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"
Az üzenetsorok modellezéséhez minden témakör csak egy olyan rendszeres előfizetésre korlátozódik (a replikációs előfizetéseken kívül), amelyet az összes felhasználó megoszt.
Az összes aktív replikációs modell az egyes témakörökbe küldött összes üzenet másolatát az egyes témakörökbe helyezi. Ez azt jelenti, hogy az alkalmazáskód minden régióban látni és feldolgozni fogja az összes üzenetet. Ez a minta olyan forgatókönyvekhez alkalmas, amikor az adatokat több régióban osztják meg, vagy ha redundáns feldolgozásra van szükség. Ha minden üzenetet csak egyszer kell feldolgoznia, mint egy normál üzenetsor esetében, az alábbi két minta egyikét kell figyelembe vennie.
Active-Passive replikáció
Az "aktív-passzív" replikációs minta a korábbi minta olyan változata, amelyben az alkalmazás csak az egyik témakört (az "elsődlegeset") használja aktívan az üzenetek küldéséhez és fogadásához, és az üzenetek egy másodlagos témakörbe vannak replikálva abban az esetben, ha az elsődleges témakör elérhetetlenné vagy elérhetetlenné válhat.
A minta és az előző minta közötti fő különbség az, hogy a replikáció egyirányú az elsődleges témakörtől a másodlagos témakörig. A másodlagos témakör soha nem lesz elsődleges, de biztonsági mentési lehetőség, ha az elsődleges témakör átmenetileg nem használható.
A minta használatának az a hátránya, hogy megpróbálja minimalizálni a duplikált feldolgozást. A replikáció során az TimeToLive üzenettulajdonság a replikált üzenetek azon időtartamára van beállítva, amely azt a várt időt tükrözi, amely során az elsődleges kiszolgáló meghibásodása feladatátvételhez vezet. Ha például a használati esethez a fogyasztónak a másodlagosra való átváltására van szükség, legfeljebb 1 percen belül, amikor az elsődleges rendszerből érkező üzenetek lekérése problémákat jelez, a másodlagosnak ideális esetben az összes olyan üzenetnek elérhetőnek kell lennie, amelyet nem tudott elérni az elsődlegesen, de minimális számú olyan üzenetet, amelyet a problémák megjelenése előtt már feldolgozott az elsődlegesről. Ha ezt az TimeToLive időtartamot kétszer( 2 perc) állítjuk be a replikáció során (set sys.TimeToLive = '0:2:0' a szabályműveletben), a másodlagos csak 2 percig őrzi meg az üzeneteket, és elveti a régebbieket. Ez azt jelenti, hogy amikor a fogadó átáll a másodlagosra, gyorsan átolvashatja és elvetheti az utolsónál régebbi üzeneteket, majd feldolgozhatja az első üzenetből, amelyet még nem látott. A tényleges megőrzési időtartam az adott használati esettől függ, valamint attól, hogy milyen gyorsan szeretné és válthat át az alkalmazás másodlagos megőrzési idejére. A TimeToLive beállítás néhány másodperctől napokig tart.
Bár az alkalmazás a másodlagosat használja, közvetlenül is közzéteheti a másodlagos témakört, amely ezután ugyanúgy működik, mint bármely szokásos témakör. A másodlagosra való váltás után a fogyasztó így a replikált üzenetek és üzenetek egyvelegét fogja látni, amelyet közvetlenül a másodlagos helyen tesznek közzé. Az alkalmazásnak ezért először vissza kell váltania a közzétételt az elsődlegesre, és továbbra is engedélyeznie kell a helyileg közzétett üzenetek kiürítését, mielőtt a fogyasztót visszakapcsolná a másodlagosra. Mivel a replikáció automatikusan folytatódik, amint az elsődleges kiszolgáló ismét elérhető lesz, a fogyasztó az adott időszakban új üzeneteket is közzétenne az elsődlegesen, bár valamivel nagyobb késéssel.
Ez a minta olyan forgatókönyvekhez használható, ahol az üzeneteket csak egyszer kell feldolgozni. Az alkalmazásnak együtt kell működnie az elsődleges kiszolgálóról feldolgozott üzenetek nyomon követésében, mert a másodlagos feladatátvételi ablak időtartama alatt duplikált elemeket fog találni, és a visszaváltás során ismét duplikátumokat fog találni. Az ismétlődés megszüntetésére vonatkozó feltételnek az alkalmazás által megadottnak
MessageIdkell lennie. AzEnqueuedTimeUtcérték vízjeljelzőként is használható, de az alkalmazásnak lehetővé kell tennie bizonyos mértékű óraeltolódást (több másodperc) az elsődleges és a másodlagos rendszer között, mint bármely elosztott rendszerben.
Átfedő replikáció
A "kiömlött" replikációs minta lehetővé teszi több Service Bus-entitás aktív/aktív használatát több régióban a Service Bus kifogástalan állapotú forgatókönyvének kezeléséhez, de a fogyasztó túlterhelődik a függőben lévő üzenetek számával, vagy egyenesen nem érhető el. Ennek az lehet az oka, hogy a fogyasztói folyamatot alátámasztó adatbázis lassú vagy nem érhető el. Ez a minta egyszerű üzenetsorokkal és témakör-előfizetésekkel működik.
Ahogy az ábrán látható, a túlcsordulási replikációs minta egy üzenetsor vagy előfizetés társított kézbesíthetetlen levelek üzenetsorából egy másik névtérben lévő párosított üzenetsorba vagy témakörbe replikálja az üzeneteket.
Hibahelyzet nélkül a rendszer párhuzamosan használja a két névteret, amelyek mindegyike a teljes üzenetforgalom egy részhalmazát kapja meg, és a hozzájuk társított fogyasztók kezelik ezt az alkészletet. Miután az egyik fogyasztó magas hibaarányt mutat vagy azonnal leáll, a megfelelő üzenetek a kézbesíthetetlen levelek várólistájára kerülnek a kézbesítési szám túllépése vagy a lejárata miatt. A replikációs feladatok ezután felveszik őket, és újra leküldik őket a párosított üzenetsorba, ahol a rendszer megjeleníti őket az feltehetően kifogástalan állapotú fogyasztónak.
Ha a feldolgozásnak egy bizonyos határidőn belül kell történnie, az TimeToLive üzenetsort és/vagy az üzeneteket úgy kell beállítani, hogy a feldolgozás a másodlagos átfedés által még időben végbe lehessen hajtani, például TimeToLive a megengedett idő felére lehet beállítva.
Az összes aktív mintához hasonlóan az alkalmazás is hozzáadhat egy jelzőt az üzenethez, hogy az üzenet már replikálva lett-e egyszer, így nem pattognak az üzenetsorpárok között, hanem inkább egy kiegészítő üzenetsorba kerülnek, amely az összetett minta kézbesíthetetlen üzenetsoraként működik.
Ez a minta olyan forgatókönyvekhez alkalmas, ahol a legfontosabb szempont a fogyasztók vagy a fogyasztók által használt erőforrások rendelkezésreállási problémáinak elhárítása, valamint a forgalmi csúcsok újraelosztása az egyik párosított üzenetsoron. Védelmet nyújt az egyik névtér elérhetetlenné válásával szemben is, ha a felhasználók mindkét üzenetsorból olvasnak, de a lejárat által
TimeToLiveokozott replikációs késés miatt előfordulhat, hogy az adott időkereten belüli üzenetek a nem elérhető névtérben rekednek.
Késés optimalizálása
A témakörök az információk több felhasználónak való terjesztésére szolgálnak. Bizonyos esetekben, különösen a széles földrajzi elosztással rendelkező fogyasztók esetében hasznos lehet az üzeneteket egy témakörből egy, a fogyasztókhoz közelebbi másodlagos névtérben lévő témakörbe replikálni.
Például amikor adatokat oszt meg a regionális, kontinentális központok között, hatékonyabb, ha az adatokat csak egyszer továbbítják a központok között, és arra, hogy a fogyasztók szerezzék be az adatok másolatát ezekről a központokról.
A replikációs átvitel kötegekben végezhető el, amelyeket a felhasználók gyakran egyenként szereznek be és rendeznek le. Például Észak-Amerika és Európa között 100 ms-os alaphálózati késéssel minden üzenet feldolgozása 200 ms-tal hosszabb időt vesz igénybe, amíg a távoli entitások két fordulója során az üzeneteket lekérte és rendezi, szemben az ugyanabban a régióban lévő entitással.
Ellenőrzés, csökkentés és bővítés
Az üzeneteket a saját megoldásán kívüli ügyfelek küldhetik el Egy Service Bus-üzenetsorba vagy -témakörbe.
Az ilyen üzenetekhez szükség lehet egy adott sémának való megfelelőség ellenőrzésére, valamint a nem megfelelő üzenetek elvetésére vagy kézbesítetlen levelekre. Előfordulhat, hogy egyes üzenetek összetettségét csökkenteni kell az adatok kihagyásával, néhányat pedig a referenciaadatok keresésén alapuló adatok hozzáadásával kell kiegészíteni. A műveletek egyéni funkciókkal is végrehajthatók a replikációs feladatban.
Streamelés üzenetsorba replikáció
Azure Event Hubs ideális megoldás a bejövő események rendkívüli mennyiségének kezelésére. Azonban sem az Event Hubs, sem az Apache Kafka hasonló motorjai nem biztosítanak olyan, szolgáltatás által felügyelt konkurens fogyasztói modellt, amelyben egyszerre több fogyasztó is kezelheti az ugyanabból a forrásból érkező üzeneteket anélkül, hogy duplikált feldolgozást kockáztatnának, és végül rendeznék ezeket az üzeneteket a feldolgozásuk után.
Az üzenetsorba történő streamreplikálás egyetlen Eseményközpont-partíció vagy egy teljes eseményközpont tartalmát egy Service Bus-üzenetsorba továbbítja, ahonnan az üzenetek biztonságosan, tranzakciósan és versengő fogyasztókkal is feldolgozhatók. Ez a replikáció lehetővé teszi az összes többi Service Bus-funkció használatát is ezekhez az üzenetekhez, beleértve a témakörökkel való útválasztást és a munkamenet-alapú demultiplexinget.
Konszolidáció és normalizálás
A globális megoldások gyakran olyan regionális lábnyomokból állnak, amelyek nagyrészt függetlenek, beleértve a saját feldolgozási képességeiket is, de a nemzetek feletti regionális és globális perspektívák megkövetelik az adatintegrációt, és ezért ugyanazon üzenetadatok központi összevonását, amelyeket a helyi szempontból a megfelelő regionális lábnyomokban értékelnek ki.
A normalizálás az összesítési forgatókönyv egyik változata, amely szerint két vagy több bejövő üzenetsorozat ugyanazt az információt hordozza, de különböző struktúrával vagy különböző kódolással, és az üzeneteket át kell kódolni vagy átalakítani, mielőtt felhasználhatók lennének.
A normalizálás magában foglalhatja a titkosítási munkát is, például a végpontok közötti titkosított hasznos adatok visszafejtését, valamint az alsóbb réteg fogyasztói közönségének különböző kulcsokkal és algoritmusokkal történő újratitkosítását.
Felosztás és útválasztás
A Service Bus-témaköröket és azok előfizetési szabályait gyakran használják egy adott célközönség üzenetstreamjének szűrésére, és a célközönség ezt követően beszerezte a szűrt halmazt egy előfizetésből.
Egy olyan globális rendszerben, ahol az üzenetek célközönsége globálisan el van osztva, vagy különböző alkalmazásokhoz tartozik, a replikációval az ilyen előfizetésből érkező üzeneteket át lehet vinni egy üzenetsorba vagy témakörbe egy másik névtérben, a felhasználásuk helyén.
Replikációs alkalmazások Azure Functions
A fenti minták implementálásához méretezhető és megbízható végrehajtási környezet szükséges a konfigurálni és futtatni kívánt replikációs feladatokhoz. Az Azure-ban az állapot nélküli feladatokhoz leginkább megfelelő futtatókörnyezet Azure Functions.
Azure Functions azure-beli felügyelt identitással futtathatók, így a replikációs feladatok integrálhatók a forrás- és célszolgáltatások szerepköralapú hozzáférés-vezérlési szabályaival anélkül, hogy titkos kódokat kellene kezelniük a replikációs útvonal mentén. Az explicit hitelesítő adatokat igénylő replikációs források és célok esetében Azure Functions a hitelesítő adatok konfigurációs értékeit az Azure Key Vault szigorúan hozzáférés-vezérlésű tárolójában tárolhatja.
Azure Functions lehetővé teszi továbbá, hogy a replikációs feladatok közvetlenül integrálhatók az Azure-beli virtuális hálózatokkal és szolgáltatásvégpontokkal az összes Azure-üzenetkezelési szolgáltatás esetében, és azonnal integrálhatók az Azure Monitorral.
A legfontosabb, hogy a Azure Functions előre összeállított, méretezhető eseményindítókkal és kimeneti kötésekkel rendelkezik a Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid és Azure Queue Storage esetében, egyéni bővítmények a RabbitMQ és az Apache Kafka számára. A legtöbb eseményindító dinamikusan alkalmazkodik az átviteli sebesség igényeihez az egyidejűleg végrehajtott példányok számának a dokumentált metrikák alapján történő fel- és leskálázásával.
A Azure Functions használatalapú csomaggal az előre összeállított eseményindítók akár nullára is leskálázhatók, miközben nem érhetők el üzenetek a replikációhoz, ami azt jelenti, hogy nem kell a konfigurációt készen tartani a vertikális felskálázásra. A használatalapú csomag használatának fő hátránya, hogy a replikációs feladatok ebből az állapotból való "felébredése" késése jelentősen magasabb, mint azoknál az üzemeltetési terveknél, amelyeken az infrastruktúra fut.
Mindezenkkel ellentétben az üzenetek és események leggyakoribb replikációs motorjai, például az Apache Kafka MirrorMaker megkövetelik, hogy üzemeltetési környezetet biztosítson, és saját maga skálázza a replikációs motort. Ez magában foglalja a biztonsági és hálózati funkciók konfigurálását és integrálását, valamint a monitorozási adatok áramlásának megkönnyítését, és így sem lesz lehetősége egyéni replikációs feladatokat injektálni a folyamatba.
Replikációs feladatok az Azure Logic Appsszel
A Függvények használatával végzett replikáció nem kódolási alternatíva a Logic Apps használata. A Logic Apps előre definiált replikációs feladatokkal rendelkezik a Service Bushoz. Ezek segíthetnek a különböző példányok közötti replikáció beállításában, és a további testreszabáshoz módosíthatók.
Következő lépések
Ebben a cikkben számos összevonási mintát ismertettünk, és ismertettük a Azure Functions szerepét az Azure esemény- és üzenetreplikációs futtatókörnyezeteként.
Ezután érdemes elolvasnia, hogyan állíthat be replikátoralkalmazást Azure Functions, majd hogyan replikálhat eseményfolyamokat az Event Hubs és más eseménykezelő és üzenetkezelő rendszerek között: