În ultima săptămână, m-am aventurat în dezvoltarea software, cercetând conceptul de actori virtuali. Am ajuns să mă uit la două cadre diferite: Dapr și Orleans.
Ambele sunt proiecte foarte concise, cu o mulțime de cazuri de utilizare interesante. Ambele folosesc ideea de actori "virtuali". Un actor virtual este o unitate de stare și logică care:
- Poate fi identificat în mod unic prin ID
- Este cu un singur filet
- Poate fi în memorie sau persistent – ciclul său de viață este gestionat de cadrul
Îmi place foarte mult ideea actorilor virtuali și îi găsesc foarte utili în explorarea mea de a construi instrumente scalabile și fiabile pentru a gestiona fluxuri de lucru complexe. Dacă fiecare sarcină este un participant virtual cu un singur fir, problema condiției de rasă dispare.
Pentru că Orleans și Dapr sunt ambele proiecte Microsoft, îmi imaginez o zi într-o confruntare în stil Western Story la cantina Microsoft.
Orleans
Am început cu Orleans pentru că a fost pe radarul meu de ceva vreme, după ce am văzut câteva videoclipuri despre el pe YouTube. A început foarte prost pentru că credeam că voi folosi versiunea 4.x a tuturor pachetelor lor NuGet. Totuși, absolut niciuna dintre documentația lor nu funcționează cu pachetul 4.x. Până la urmă am folosit versiunea 3.6.2.
Cereale / Stat / Cronometrate
Crearea unui grain care urmărește propria stare și execută acțiuni este foarte simplă. Am reușit chiar să urmez documentația pentru persistența grainului și să creez propria mea implementare CosmosDB (SQL API) a IGrainStorage.
Mementouri
Memento-urile sunt, de asemenea, ușor de setat. Până când am încercat să configurez persistența din lumea reală pentru ele. În acest moment al cercetării mele, încerc să păstrez totul ordonat și să stochez totul în ComsosDB. Din păcate, nu reușesc deloc să fac pachetul de persistență de reamintiri al Orleans. Până la urmă a trebuit să trec la pachetul AzureStorage. Acum datele mele sunt pe jumătate în contul API SQL și pe jumătate în contul API tabel.
Fluxuri
Acolo nu am mers bine. În Orleans, fluxurile sunt identificate printr-un GUID și un spațiu de nume opțional. Sunt sigur că există un motiv bun pentru care stream-urile trebuie identificate printr-un GUID, dar wow, asta e nepractic.
Sunt foarte frustrat de stream-uri pentru că am reușit să le creez ușor, dar odată ce mă opresc și repornesc proiectul și declanșez un eveniment nou, totul se blochează.
Urmează o informație foarte valoroasă, deoarece mi-a luat 8 ore să descifrez codul Orleans ca să-l descifrez:
Când un grain este abonat stream, acesta trebuie să apeleze ResumeAsync pe handle-ul de abonament din metoda OnActivateAsync, altfel veți avea crash din cauza unei erori neidentificate.
Am avut și problema că același abonament era duplicat, așa că am folosit codul pentru a șterge toate abonamentele cerealelor și apoi l-am recreat:
Alte capcane / sfaturi din Orleans
Streams funcționează bine cu Azure Event Hubs (prin AddEventHubStreams).
Nu folosi / sau alte caractere speciale din numele Grain al API-ului SQL CosmosDB!
Concluzie de la Orleans
Îmi place Orleans și cred că are potențial. Totuși, are o curbă de învățare foarte abruptă. Din cauza luptei mele îndelungate cu streaming-ul, nu am timp să studiez cum funcționează clusterele/implementările.
Dapr
Am găsit Dapr căutând alternative la Orleans. Este puțin ciudat că este și un proiect sponsorizat de Microsoft. Poate că sunt aici pentru a adopta o abordare de supraviețuire a celui mai adaptat. Dacă da, cred că Dapr va fi un supraviețuitor.
În primul rând, designul bazat pe REST/gRPC al lui Dapr permite implementarea actorilor folosind orice limbaj de programare. De asemenea, mi s-a părut trivial să rulez totul (participanți, statusuri, timere, memento-uri, evenimente) într-o singură instanță Redis. Pe lângă asta, mi-a luat cam o treime din timp să încep să folosesc Dapr. Un timp de pornire atât de rapid se datorează documentației excelente oferite de Dapr.
Actori / Cronometrator / Reamintiri
Tocmai am spus că documentația lui Dapr este excelentă? Ei bine, este peste tot, cu excepția exemplelor JavaScript. Îmi petrec cea mai mare parte a timpului pe Dapr, încercând să găsesc modalități de a numi metode actorilor. Codul pentru exemplul Dapr Javascript este următorul:
Este clar că este depășit. A trebuit să petrec mult timp încercând să ghidez aceste trei linii prin explorarea codului de test/exemplu al lui Dapr
Exemplele de cod pentru obținerea/setarea stării au probleme similare, așa că am creat o problemă pe GitHub pentru ele.
Cu excepția acestor probleme minore, prepararea actorilor este floare la ureche.
Setarea cronometelor și a memento-urilor pentru aruncarea mea este, de asemenea, foarte ușoară.
Stat
Am reușit să configurez Dapr să persiste cu Postgres foarte ușor.
Un lucru pe care l-am observat este că pot exista probleme de scalabilitate în modul în care sunt stocate memento-urile. Dapr stochează toate alertele pentru un anumit tip de participant într-un singur tablou JSON. Ce se întâmplă dacă cineva are o mulțime de memento-uri?
Alte capcane / sfaturi legate de Dapr
Un lucru pe care l-am observat când răsfoiam codul pentru SDK-ul JavaScript este că nu există prea multe comentarii în baza de cod. Asta face aproape imposibil să găsești o soluție. De exemplu, în metoda addOrUpdateState a managerului de stat există un al treilea parametru numit updateValueFactory. Dacă nu există comentarii în cod, este aproape imposibil de spus pentru ce este apelul.
De asemenea, nu sunt sigur cât de mult îmi place comanda "dapr init" care încearcă să configureze și să ruleze un container Redis pentru mine. Ce se întâmplă dacă deja am un container Redis? Ce se întâmplă dacă vreau să folosesc postgres în schimb? Nu găsesc documentație care să explice cum să schimbi funcția DAPR Init.
O notă pentru oricine are dificultăți în a folosi pubsub. Trebuie să folosești "dapr run" pentru a rula atât editorul, cât și abonatul:
Pentru actori și pubsub, reține că este important să folosești parametrul --app-port pentru a informa dapr pe ce port rulează serviciul tău. evenimentele pubsub și apelurile actorilor sunt trimise către serviciul tău de pe sidecar-ul Dapr prin apeluri http, deci trebuie să știe unde să le trimită:
Am testat un mic "cluster" Dapr auto-găzduit, lansând instanța mea de abonat pubsub pe două calculatoare diferite din rețeaua mea de acasă. Pur și simplu a funcționat!
Concluzie Dapr
Dacă vrei să afli mai multe idei despre aplicații distribuite sau actori virtuali, îți recomand să începi cu Dapr. Orleans a fost pionierul original, în timp ce Dapr a fost un reboot care a dus lucrurile la un alt nivel.
Link original:Autentificarea cu hyperlink este vizibilă.
|
Postat pe 29.12.2022 14:24:52
|
|
|
|
Proprietarul|
Postat pe 29.12.2022 14:25:28
|
