Az elmúlt héten a virtuális szereplők fogalmát kutatva kezdtem el a szoftverfejlesztés felé. Végül két különböző keretrendszert kerestem: a Dapr és az Orleans.
Mindkettő nagyon tömör projekt, rengeteg érdekes felhasználási esettel. Mindkettő a "virtual" szereplők fogalmát használja. A virtuális szereplő egy állapot- és logikai egység, amely:
- Azonosítóval egyedileg azonosítható
- Egyszálas
- Lehet memóriában vagy tartós – az életciklusát a keretrendszer kezeli
Nagyon tetszik a virtuális szereplők ötlete, és nagyon hasznosnak találom őket a skálázható és megbízható eszközök építésében a bonyolult munkafolyamatok kezelésére. Ha minden feladat egy szálas virtuális résztvevő, a verseny feltétele eltűnik.
Mivel az Orleans és a Dapr mindketten Microsoft projektek, elképzelek egy napot egy Western Story stílusú összecsapásban a Microsoft menzánjában.
Orleans
Az Orleans-szal kezdtem, mert már egy ideje a látókörömben van, miután láttam néhány videót róla a YouTube-on. Nagyon rosszul indult, mert azt hittem, hogy az összes NuGet csomagjuk 4.x verzióját fogom használni. Azonban semmilyen dokumentációjuk nem működik a 4.x csomaggal. Végül a 3.6.2-es verziót használtam.
Gabona / Állapot / Időzítők
Egy szemcse létrehozása, amely követi a saját állapotát és végrehajtja a műveleteket, nagyon egyszerű. Még a szemcse tartósság dokumentációját is követni tudtam, és létrehoztam saját CosmosDB (SQL API) implementációmat az IGrainStorage-en.
Emlékeztetők
Az emlékeztetők is könnyen beállíthatóak. Egészen addig, amíg meg nem próbáltam beállítani a valós világban lévő kitartást nekik. A kutatásom ezen pontján igyekszem mindent rendben tartani és mindent a ComsosDB-ben tárolni. Sajnos az Orleans emlékeztető kitartási csomagját egyáltalán nem tudom működtetni. Végül át kellett váltanom az AzureStorage csomagra. Most az adataim fele SQL API fiókban, fele a table API fiókban van.
Patakok
Ott nem sikerült jól. Orleansban az áramlásokat egy GUID és opcionális névtér azonosítja. Biztos vagyok benne, hogy van jó oka annak, hogy a streameket GUID kell azonosítani, de hűha, ez nem praktikus.
Nagyon frusztrált vagyok a streamekkel, mert könnyen tudtam létrehozni őket, de amikor megállítom, újraindítom a projektet, és új eseményt indítok el, minden összeomlik.
Ezt követi egy nagyon értékes információ, mivel 8 órába telt, mire visszafejtettem az Orleans kódot:
Ha egy gabona stream előfizető, a grainnek az OnActivateAsync módszerben a ResumeAsync nevet kell hívnia az előfizetési fiókon, különben egy felismerhetetlen hibával összeomlik.
Nekem is volt problémám, hogy ugyanaz az előfizetés duplikálódott, ezért a kódot használtam az összes grain előfizetés törlésére, majd újraalkottam:
Egyéb Orleans-i Értekezések / Tippek
A Streams jól működik az Azure Event Hubs-szal (AddEventHubStreams segítségével).
Ne használj / vagy más különleges karaktereket a CosmosDB SQL API Grain nevében!
Orleans-i következtetés
Szeretem Orleanst, és szerintem van benne potenciál. Viszont nagyon meredek a tanulási görbéje van. A streameléssel való hosszú küzdelmem miatt nincs időm tanulmányozni, hogyan működnek a klaszterek/telepítések.
Dapr
A Dapr-t úgy találtam meg, hogy alternatívákat kerestem Orleans helyett. Furcsa, hogy ez egy Microsoft által támogatott projekt. Talán azért vannak itt, hogy a legalkalmasabb túlélési megközelítést alkalmazzanak. Ha igen, szerintem Dapr túlélő lesz.
Először is, a Dapr REST/gRPC-alapú tervezése lehetővé teszi, hogy a szereplők bármilyen programozási nyelven implementálhassák. Azt is könnyűnek találtam, hogy mindent (résztvevők, státuszok, időzítők, emlékeztetők, események) egyetlen Redis példányon futtatjak. Ráadásul csak körülbelül egyharmadába telt, mire elkezdtem használni a Dapr-t. Az ilyen gyors indulási idő a Dapr kiváló dokumentációjának köszönhető.
Színészek / időzítők / emlékeztetők
Mondtam már, hogy a Dapr dokumentációja nagyszerű? Nos, mindenhol ott van, kivéve a JavaScript példákat. A legtöbb időmet Dapron töltöm, próbálom kitalálni, hogyan hívhatnám a módszereket a színészekre. A Dapr Javascript mintakódja a következő:
Ez egyértelműen elavult. Sok időt kellett szánnom arra, hogy ezeket a három sort átvezessem a Dapr teszt/mintakód felfedezésén
A kód példák az állapot megszerzése/beállításához hasonló problémákat mutatnak, ezért létrehoztam nekik egy GitHub problémát.
A kisebb problémákat leszámítva a színészek beállítása gyerekjáték.
Időzítők és emlékeztetők beállítása a gipszeknek szintén nagyon egyszerű.
Állam
Nagyon könnyen be tudtam állítani a Daprat, hogy a Postgres maradjon.
Egy dolgot észrevettem, hogy skálázhatósági problémák lehetnek az emlékeztetők tárolásával kapcsolatban. A Dapr egyetlen JSON tömbben tárolja az összes értesítést egy adott résztvevőtípusra. Mi történik, ha valakinek rengeteg emlékeztetője van?
Egyéb Dapr Értcsék / Tippek
Egy dolog, amit észrevettem, amikor böngésztem a JavaScript SDK kódját, hogy a kódbázisban egyáltalán nincs sok hozzászólás. Ez szinte lehetetlenné teszi valamit kitalálni. Például az állapotkezelő addOrUpdateState metódudorában van egy harmadik paraméter, amit updateValueFactory-nek hívnak. Ha nincs hozzászólás a kódban, szinte lehetetlen megmondani, mire való visszahívás.
Nem is vagyok biztos benne, mennyire tetszik a "dapr init" parancs, ami megpróbál beállítani és futtatni egy redis konténert nekem. Mi van, ha már van egy Redis tartályom? Mi van, ha helyette a postgres-t akarom használni? Nem találok olyan dokumentációt, amely elmagyarázná, hogyan lehet megváltoztatni a dapr init funkciót.
Egy megjegyzés bárkinek, akinek nehézségei vannak a pubsub használatával. A "dapr run" funkciót kell használni, hogy mind a kiadódat, mind az előfizetődet lehessen futtatni:
Aktorok és pubsub esetén fontos használni a --app-port paramétert, hogy a dapr tudja, melyik porton fut a szolgáltatás. Pubsub eseményeket és színészhívásokat a Dapr sidecar-ról küldenek a szolgáltatásodhoz HTTP hívásokkal, így tudnia kell, hová kell küldeni őket:
Egy kis, Dapr önállóan hosztolt "klasztert" teszteltem azzal, hogy a pubsub előfizető példányomat két különböző gépen indítottam el a hazai hálózatomon. Egyszerűen működött!
Dapr következtetés
Ha több ötletet szeretnél megtudni elosztott alkalmazásokról vagy virtuális aktorokról, azt javaslom, kezdd a Dapr-szal. Orleans volt az eredeti úttörő, míg a Dapr egy reboot volt, amely a dolgokat a következő szintre emelte.
Eredeti link:A hiperlink bejelentkezés látható.
|
Közzétéve 2022. 12. 29. 14:24:52
|
|
|
|
Háziúr|
Közzétéve 2022. 12. 29. 14:25:28
|
