Během uplynulého týdne jsem se pustil do vývoje softwaru tím, že jsem zkoumal koncept virtuálních aktérů. Nakonec jsem se podíval na dva různé frameworky: Dapr a Orleans.
Oba projekty jsou velmi stručné a mají spoustu zajímavých případů použití. Oba využívají myšlenku "virtuálních" aktérů. Virtuální aktér je stavová a logická jednotka, která:
- Lze jej jednoznačně identifikovat podle ID
- Je jednovláknový
- Může být v paměti nebo perzistentní – její životní cyklus je řízen rámcem
Opravdu se mi líbí myšlenka virtuálních aktérů a považuji je za velmi užitečné při hledání škálovatelných a spolehlivých nástrojů pro zvládání složitých pracovních postupů. Pokud je každý úkol jednovláknovým virtuálním účastníkem, problém závodních podmínek zmizí.
Protože Orleans a Dapr jsou oba projekty Microsoftu, představuji si den ve stylu Western Story v jídelně Microsoftu.
New orleans
Začal jsem s Orleans, protože už nějakou dobu mám na radaru poté, co jsem o něm viděl pár videí na YouTube. Začalo to opravdu špatně, protože jsem si myslel, že budu používat 4.x verzi všech jejich NuGet balíčků. Nicméně žádná jejich dokumentace nefunguje s balíčkem 4.x. Nakonec jsem použil verzi 3.6.2.
Obilí / Stát / Časovače
Vytvořit zrno, které sleduje svůj vlastní stav a provádí akce, je velmi jednoduché. Dokonce jsem dokázal sledovat dokumentaci o perzistenci zrna a vytvořit si vlastní implementaci IGrainStorage v CosmosDB (SQL API).
Upomínky
Připomínky se také snadno nastavují. Dokud jsem se nepokusil nastavit pro ně reálnou perzistenci. V tuto chvíli se snažím udržovat vše uklizené a ukládat do ComsosDB. Bohužel se mi vůbec nedaří rozchodit balíček Orleans s perzistencí připomínek. Nakonec jsem musel přejít na balíček AzureStorage. Takže teď jsou moje data z poloviny v SQL API účtu a z poloviny v tabulovém API účtu.
Proudy
A tam jsem nedopadl dobře. V Orleans jsou toky identifikovány pomocí GUID a volitelného jmenného prostoru. Jsem si jistý, že existuje dobrý důvod, proč musí být streamy identifikovány podle GUID, ale wow, to je nepraktické.
Jsem ze streamů hodně frustrovaný, protože jsem je snadno vytvořil, ale jakmile projekt zastavím, restartuji a spustím novou událost, všechno spadne.
Následuje velmi cenná informace, protože mi trvalo 8 hodin zpětně analyzovat Orleanský kód a přijít na to:
Když je zrno odběratelem streamu, musí zavolat ResumeAsync na předplatitelském handle ve své metodě OnActivateAsync, jinak dojde k pádu s nerozpoznanou chybou.
Měl jsem také problém s duplicitním odběrem, takže jsem použil kód k odstranění všech odběrů zrna a pak ho znovu vytvořil:
Další Orleanské tipy / tipy
Streams dobře funguje s Azure Event Hubs (přes AddEventHubStreams).
Nepoužívejte / ani jiné speciální znaky v názvu Grain SQL API CosmosDB!
Orleanský závěr
Mám rád Orleans a myslím, že má potenciál. Nicméně má velmi strmou křivku učení. Kvůli mému dlouhodobému boji se streamováním nemám čas studovat, jak clustery/nasazení fungují.
Dapr
Dapr jsem našel tím, že jsem hledal alternativy k Orleans. Je trochu zvláštní, že je to zároveň projekt sponzorovaný Microsoftem. Možná jsou tu, aby zvolili přístup přežití nejsilnějších. Pokud ano, myslím, že Dapr bude přeživší.
Za prvé, návrh Dapr založený na REST/gRPC umožňuje implementovat aktéry v jakémkoli programovacím jazyce. Také mi přišlo triviální spouštět všechno (účastníky, stavy, časovače, připomínky, události) na jedné instanci Redis. Navíc mi trvalo asi třetinu času, než jsem začal používat Dapr. Tak rychlý start je díky vynikající dokumentaci Dapr.
Herci / Časovači / Připomínky
Řekl jsem právě, že dokumentace od Dapru je skvělá? No, je to všude, kromě příkladů v JavaScriptu. Většinu času trávím u Dapru, snažím se přijít na to, jak volat metody na herce. Kód pro ukázku Dapr Javascriptu je následující:
To je zjevně zastaralé. Musel jsem strávit hodně času tím, že jsem tyto tři řádky prováděl testováním/ukázkovým kódem Dapr
Příklady kódu pro dostání/nastavení stavu mají podobné problémy, takže jsem pro ně vytvořil GitHub problém.
Kromě těchto drobných problémů je příprava herců hračka.
Nastavení časovačů a připomínek pro můj casting je také velmi snadné.
Stát
Dapr jsem dokázal velmi snadno nastavit tak, aby s Postgresem přetrval.
Jedna věc, které jsem si všiml, je, že mohou být problémy se škálovatelností při ukládání připomínek. Dapr ukládá všechna upozornění pro konkrétní typ účastníka v jednom JSON poli. Co se stane, když má někdo spoustu připomínek?
Další Dapr Tipy / Tipy
Jedna věc, které jsem si všiml při prohlížení kódu JavaScript SDK, je, že v kódu není téměř žádné komentáře. To téměř znemožňuje něco zjistit. Například v metodě addOrUpdateState správce stavu existuje třetí parametr nazvaný updateValueFactory. Pokud v kódu nejsou žádné komentáře, je téměř nemožné určit, k čemu callback je.
Také si nejsem jistý, jak moc se mi líbí příkaz "dapr init", který se snaží nastavit a spustit pro mě redisový kontejner. Co když už mám redisovou nádobu? Co když chci místo toho použít postgres? Nemohu najít dokumentaci, která by vysvětlovala, jak změnit funkci dapr init.
Poznámka pro každého, kdo má potíže s používáním pubsubu. Musíte použít "dapr run" pro provoz jak pro svého vydavatele, tak pro odběratele:
U aktorů a pubsubů je důležité použít parametr --app-port, aby dapr věděl, na kterém portu vaše služba běží. pubsub události a volání herců jsou posílány vaší službě z Dapr sidecaru přes http hovory, takže musí vědět, kam je poslat:
Otestoval jsem malý Dapr self-hosted "cluster" tím, že jsem spustil svou pubsub subscriber instanci na dvou různých strojích v domácí síti. Prostě to fungovalo!
Závěr Dapr
Pokud chcete vědět více o distribuovaných aplikacích nebo virtuálních aktorech, doporučuji začít s Dapr. Orleans byl původní průkopník, zatímco Dapr byl reboot, který posunul věci na další úroveň.
Původní odkaz:Přihlášení k hypertextovému odkazu je viditelné.
|
Zveřejněno 29.12.2022 14:24:52
|
|
|
|
Pronajímatel|
Zveřejněno 29.12.2022 14:25:28
|
