I løbet af den sidste uge har jeg kastet mig ud i softwareudvikling ved at undersøge konceptet virtuelle aktører. Jeg endte med at undersøge to forskellige frameworks: Dapr og Orleans.
Begge er meget præcise projekter med masser af interessante anvendelsestilfælde. Begge bruger idéen om "virtuelle" skuespillere. En virtuel aktør er en tilstands- og logikenhed, der:
- Den kan entydigt identificeres ved ID
- Den er enkeltgevindet
- Kan være in-memory eller persistent – dens livscyklus styres af frameworket
Jeg kan virkelig godt lide idéen om virtuelle aktører og finder dem meget hjælpsomme i min udforskning af at bygge skalerbare og pålidelige værktøjer til at håndtere komplekse arbejdsgange. Hvis hver opgave er en enkelttrådet virtuel deltager, forsvinder racebetingelsesproblemet.
Fordi Orleans og Dapr begge er Microsoft-projekter, forestiller jeg mig en dag i en Western Story-stil opgør i Microsofts kantine.
Orleans
Jeg startede med Orleans, fordi det har været på min radar i et stykke tid efter at have set nogle videoer om det på YouTube. Det startede virkelig dårligt, fordi jeg troede, jeg ville bruge 4.x-versionen af alle deres NuGet-pakker. Dog fungerer absolut ingen af deres dokumentation med 4.x-pakken. Jeg endte med at bruge version 3.6.2.
Korn / Tilstand / Timere
At skabe et korn, der følger sin egen tilstand og udfører handlinger, er meget enkelt. Jeg kunne endda følge dokumentationen for kornpersistens og lave min egen CosmosDB (SQL API) implementering af IGrainStorage.
Påmindelser
Påmindelser er også nemme at sætte op. Indtil jeg prøvede at konfigurere reel persistens for dem. På nuværende tidspunkt i min research prøver jeg at holde alt ryddeligt og gemme alt i ComsosDB. Desværre kan jeg slet ikke få Orleans' påmindelses-persistence-pakke til at virke. Jeg endte med at skifte til AzureStorage-pakken. Så nu er mine data halvdelen i SQL API-kontoen og halvdelen i tabellen API-kontoen.
Streams
Det var der, jeg ikke gik godt. I Orleans identificeres flows ved en GUID og et valgfrit navnerum. Jeg er sikker på, at der er en god grund til, at streams skal identificeres med en GUID, men wow, det er upraktisk.
Jeg er meget frustreret over streams, fordi jeg nemt kunne oprette dem, men når jeg stopper og genstarter mit projekt og udløser en ny begivenhed, crasher alt.
Dette efterfølges af en meget værdifuld oplysning, da det tog mig 8 timer at reverse engineere Orleans-koden for at finde ud af det:
Når et korn er en stream-abonnent, skal kornet kalde ResumeAsync på abonnementshåndtaget i sin OnActivateAsync-metode, ellers crasher du med en ukendt fejl.
Jeg havde også problemet med, at det samme abonnement blev duplikeret, så jeg brugte koden til at slette alle kornets abonnementer og genskabte det så:
Andre Orleans-fælder / tips
Streams fungerer godt med Azure Event Hubs (via AddEventHubStreams).
Brug ikke / eller andre specialtegn i Grain-navnet på CosmosDB SQL API'ET!
Orleans-konklusion
Jeg kan godt lide Orleans, og jeg synes, det har potentiale. Dog har det en meget stejl indlæringskurve. På grund af min lange kamp med streaming har jeg ikke tid til at studere, hvordan klynger/udrulninger fungerer.
Dapr
Jeg fandt Dapr ved at lede efter alternativer til Orléans. Det er lidt mærkeligt, at det også er et Microsoft-sponsoreret projekt. Måske er de her for at tage en overlevelses-den-stærkeste-tilgang. Hvis ja, tror jeg, Dapr vil være en overlever.
For det første tillader Daprs REST/gRPC-baserede design, at aktører kan implementeres ved hjælp af ethvert programmeringssprog. Jeg syntes også, det var trivielt at køre alt (deltagere, statusser, timere, påmindelser, events) på en enkelt Redis-instans. Derudover tog det mig kun omkring en tredjedel af tiden at begynde at bruge Dapr. Så hurtig opstartstid skyldes Daprs fremragende dokumentation.
Skuespillere / Timere / Påmindelser
Sagde jeg lige, at Daprs dokumentation er fantastisk? Nå, det er overalt, undtagen JavaScript-eksempler. Jeg bruger det meste af min tid på Dapr, hvor jeg prøver at finde ud af, hvordan man kalder metoder på skuespillere. Koden til Dapr Javascript-eksemplet er som følger:
Dette er tydeligvis forældet. Jeg måtte bruge meget tid på at lokke disse tre linjer gennem Daprs test-/eksempelkode-udforskning
Kodeeksemplerne til at hente/sætte status har lignende problemer, så jeg lavede et GitHub-problem til dem.
Bortset fra de små problemer er det en leg at sætte skuespillere op.
At sætte timere og påmindelser til mit cast er også meget nemt.
Stat
Jeg kunne konfigurere Dapr til at fortsætte med Postgres meget nemt.
En ting, jeg har bemærket, er, at der kan være skalerbarhedsproblemer med, hvordan påmindelser gemmes. Dapr gemmer alle advarsler for en specifik deltagertype i et enkelt JSON-array. Hvad sker der, hvis nogen har en masse påmindelser?
Andre Dapr-grøft / tips
En ting jeg lagde mærke til, da jeg gennemgik koden til JavaScript SDK'en, er, at der slet ikke er mange kommentarer i kodebasen. Det gør det næsten umuligt at finde ud af noget. For eksempel findes der i state managerens addOrUpdateState-metode en tredje parameter kaldet updateValueFactory. Hvis der ikke er kommentarer i koden, er det næsten umuligt at vide, hvad callbacken er til.
Jeg er heller ikke sikker på, hvor meget jeg kan lide kommandoen "dapr init", når jeg prøver at sætte og køre en redis-container for mig. Hvad hvis jeg allerede har en redis-beholder? Hvad hvis jeg i stedet vil bruge Postgres? Jeg kan ikke finde dokumentation, der forklarer, hvordan man ændrer DAPR init-funktionen.
En note til alle, der har problemer med at bruge pubsub. Du skal bruge "dapr run" for at drive både din udgiver og abonnent:
For aktører og pubsub skal du bemærke, at det er vigtigt at bruge parameteren --app-port for at lade dapr vide, hvilken port din tjeneste kører på. pubsub-events og actor-opkald sendes til din service fra Dapr-sidecaren via http-opkald, så den skal vide, hvor de skal sendes hen:
Jeg testede en lille Dapr selvhostet "cluster" ved at starte min pubsub-abonnentinstans på to forskellige maskiner på mit hjemmenetværk. Det virkede bare!
Dapr-konklusion
Hvis du vil vide flere idéer om distribuerede applikationer eller virtuelle aktører, anbefaler jeg, at du starter med Dapr. Orleans var den oprindelige pioner, mens Dapr var en reboot, der tog tingene til næste niveau.
Originalt link:Hyperlink-login er synlig.
|
Opslået på 29/12/2022 14.24.52
|
|
|
|
Udlejer|
Opslået på 29/12/2022 14.25.28
|
