Kas tas Dapr ir kodėl turėtum susipažinti
Mikroservisų architektūra tapo standartu daugelyje organizacijų, bet kartu su ja atėjo ir krūva iššūkių. Kaip užtikrinti patikimą komunikaciją tarp servisų? Kaip valdyti būsenas? Kaip integruoti įvairius cloud providerius neprarandant proto? Štai čia į sceną įžengia Dapr (Distributed Application Runtime) – projektas, kurį Microsoft pristatė 2019-aisiais ir kuris gali iš esmės pakeisti tai, kaip kuriame paskirstytas sistemas.
Dapr nėra dar vienas framework’as, kurį reikia įdiegti į savo kodą. Tai veikiau sidecar pattern’u veikiantis runtime, kuris suteikia standartizuotą API įvairiems paskirstytų sistemų scenarijams. Jis veikia kaip tarpininkas tarp jūsų aplikacijos ir infrastruktūros, leidžiantis keisti technologijas po savimi nekeičiant kodo.
Įsivaizduokite, kad kuriate aplikaciją, kuri šiandien naudoja Redis cache’inimui, bet rytoj norite pereiti prie Memcached arba net cloud providerio sprendimo. Su tradiciniu požiūriu tai reikštų kodo perrašymą. Su Dapr? Tiesiog pakeičiate konfigūraciją. Štai kodėl šis projektas sulaukė tokio didelio dėmesio.
Architektūra ir pagrindiniai komponentai
Dapr veikia kaip atskiras procesas šalia jūsų aplikacijos – tai ir yra tas garsus sidecar pattern’as. Jūsų aplikacija bendrauja su Dapr per HTTP arba gRPC, o Dapr jau rūpinasi viskuo kitu. Tai reiškia, kad galite naudoti bet kokią programavimo kalbą – Python, Go, Java, C#, JavaScript ar net Rust. Dapr visiškai agnostiškas kalbos atžvilgiu.
Pagrindinis Dapr komponentas yra building blocks – tai abstrakčios funkcionalumo dalys, kurias galite naudoti savo aplikacijose. Šiuo metu Dapr siūlo apie dešimt pagrindinių building blocks:
Service invocation leidžia servisams kviesti vienas kitą patikimai, su automatiniais retry mechanizmais ir service discovery. Jums nereikia rūpintis, kur fiziškai yra kitas servisas – Dapr viską išsprendžia.
State management suteikia vieningą API būsenų valdymui. Nesvarbu, ar naudojate Redis, MongoDB, ar AWS DynamoDB – kodas lieka tas pats. Tai neįtikėtinai patogu testuojant lokaliai su vienu store’u ir deployinant į produkciją su kitu.
Pub/sub funkcionalumas leidžia kurti event-driven architektūras nenaudojant specifinių message broker bibliotekų. Dapr palaiko RabbitMQ, Kafka, Azure Service Bus ir dar daugybę kitų.
Praktinis panaudojimas realiuose projektuose
Pradėti su Dapr yra stebėtinai paprasta. Jei dirbate lokaliai, pakanka įdiegti Dapr CLI ir paleisti `dapr init`. Tai sukurs reikiamus Docker konteinerius ir paruoš aplinką darbui. Kubernetes aplinkoje procesas šiek tiek sudėtingesnis, bet vis tiek gana straightforward – naudojate Helm chart’ą arba Dapr Operator.
Tarkime, kuriate e-commerce platformą su mikroservisais. Turite order servisą, payment servisą ir notification servisą. Be Dapr, jums reikėtų:
– Implementuoti HTTP kliento logiką su retry mechanizmais
– Pasirinkti ir integruoti message broker’į
– Sukurti savo distributed tracing sprendimą
– Valdyti secrets kiekvienam servisui atskirai
– Rašyti daug boilerplate kodo
Su Dapr visa tai ateina out-of-the-box. Order servisas gali išsiųsti žinutę į pub/sub topic’ą tiesiog darydamas HTTP POST į `http://localhost:3500/v1.0/publish/ordertopic`. Payment servisas užsiprenumeruoja tą topic’ą per paprastą endpoint’ą savo aplikacijoje. Notification servisas daro tą patį. Jokių priklausomybių nuo konkrečių bibliotekų.
Observability ir debugging galimybės
Vienas iš didžiausių skausmų dirbant su mikroservisais yra debugging. Kaip suprasti, kas nutiko, kai request’as keliauja per penkis skirtingus servisus? Dapr čia labai padeda.
Pirmiausia, Dapr automatiškai prideda distributed tracing naudodamas OpenTelemetry standartą. Jums nereikia nieko specialiai konfigūruoti – tiesiog prijunkite Zipkin ar Jaeger, ir matote visą request’o kelią per sistemą. Tai veikia nepriklausomai nuo to, kokia kalba parašytas kiekvienas servisas.
Dapr Dashboard – tai web UI, kuris leidžia matyti visus jūsų Dapr aplikacijas, jų būsenas, komponentus ir net siųsti test request’us. Lokaliai developinant tai neįkainojama priemonė. Galite greitai patikrinti, ar jūsų pub/sub konfigūracija veikia, ar state store’as prieinamas, ar servisai tarpusavyje bendrauja.
Logging’as taip pat standartizuotas. Visi Dapr sidecar’ai logina į stdout/stderr strukturuotu formatu, kurį lengva parsuoti ir siųsti į centralizuotą logging sistemą kaip ELK stack’ą ar Loki.
Security aspektai ir best practices
Saugumas paskirstytose sistemose – tai ne juokai. Dapr siūlo kelis mechanizmus, kurie padeda užtikrinti, kad jūsų mikroservisai būtų apsaugoti.
mTLS (mutual TLS) yra įjungtas pagal nutylėjimą tarp Dapr sidecar’ų. Tai reiškia, kad visa komunikacija tarp jūsų servisų yra šifruojama ir autentifikuojama. Dapr automatiškai valdo sertifikatus, jų rotaciją ir renewal procesą. Jums nereikia būti security ekspertu, kad tai veiktų.
Secrets management building block’as leidžia saugiai gauti slaptažodžius, API raktus ir kitus jautrius duomenis. Vietoj to, kad hardcode’intumėte juos į konfigūracijas ar environment variables, galite naudoti Dapr API, kuris integruojasi su Kubernetes secrets, Azure Key Vault, AWS Secrets Manager ir panašiais sprendimais.
Access control policies leidžia apibrėžti, kurie servisai gali kviesti kuriuos. Pavyzdžiui, galite nurodyti, kad tik order servisas gali kviesti payment servisą. Tai daroma per paprastas YAML konfigūracijas, ne per sudėtingus network policies.
Praktinis patarimas: pradėkite su default security settings ir tik tada customizuokite pagal poreikius. Dapr defaults yra gana saugūs ir tinka daugumai use case’ų.
Performance ir skalabilumo klausimai
Natūralu klausti: ar tas papildomas sidecar layer’is nesulėtina sistemos? Atsakymas – priklauso, bet dažniausiai overhead’as yra minimalus.
Dapr sidecar’as yra parašytas Go kalba ir optimizuotas performance’ui. Vidutiniškai jis prideda 1-2ms latency HTTP request’ams. gRPC atveju overhead’as dar mažesnis. Daugumai aplikacijų tai visiškai priimtina kaina už visą funkcionalumą, kurį gaunate.
Kas liečia resource consumption, Dapr sidecar paprastai naudoja 20-30MB memory ir minimalų CPU. Tai nėra daug, ypač palyginus su tuo, kiek memory’ės reikalauja tipiška Java aplikacija su visomis savo dependencies.
Skalabilumas – čia Dapr tikrai šviečia. Kadangi kiekvienas servisas turi savo sidecar’ą, nėra centralizuoto bottleneck’o. Kai scale’inate savo aplikaciją horizontaliai, Dapr sidecar’ai scale’inasi kartu. Tai veikia puikiai ir Kubernetes aplinkoje su HPA (Horizontal Pod Autoscaler).
Vienas svarbus aspektas – actor model implementacija. Dapr palaiko virtual actors (panašiai kaip Orleans framework’e), kurie leidžia lengvai kurti stateful, single-threaded objektus paskirstytoje sistemoje. Tai labai galingas pattern’as tam tikroms problemoms spręsti, ir Dapr implementacija yra tikrai efektyvi.
Integracijos su cloud provideriais
Viena iš stipriausių Dapr pusių – tai multi-cloud palaikymas. Galite rašyti aplikaciją, kuri veikia AWS, Azure ar Google Cloud be vendor lock-in.
Dapr turi komponentus daugeliui cloud servisų. Norite naudoti Azure Blob Storage state management’ui? Yra komponentas. AWS SQS pub/sub’ui? Yra komponentas. Google Cloud Pub/Sub? Taip pat yra. Ir svarbiausia – jūsų aplikacijos kodas nesikeičia, keičiasi tik konfigūracijos failas.
Štai realus pavyzdys. Lokaliai developinate su Redis ir RabbitMQ. Konfigūracija atrodo taip:
„`yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.redis
metadata:
– name: redisHost
value: localhost:6379
„`
Kai deploy’inate į Azure, tiesiog pakeičiate type į `state.azure.blobstorage` ir atitinkamus metadata laukus. Kodas lieka identiškas. Tai tikrai game-changer, ypač jei dirbate su multi-cloud strategija arba planuojate migruoti tarp cloud providerių.
Dapr taip pat gerai integruojasi su Kubernetes native features. Galite naudoti ConfigMaps, Secrets, Service Mesh’us kaip Istio ar Linkerd. Dapr neprieštarauja šiems įrankiams – jis juos papildo.
Ateitis ir bendruomenė
Dapr projektas vystosi labai greitai. Nuo 2019 metų jis pasiekė production-ready statusą ir dabar yra CNCF (Cloud Native Computing Foundation) incubating projektas. Tai reiškia, kad už jo stovi ne tik Microsoft, bet ir visa cloud native bendruomenė.
Kas kelis mėnesius išleidžiamos naujos versijos su papildoma funkcionalumu ir performance pagerinimais. Bendruomenė aktyvi – GitHub’e rasite tūkstančius issues, pull request’ų ir diskusijų. Dokumentacija nuolat tobulėja, nors kai kuriose vietose dar galėtų būti išsamesnė.
Vienas įdomių aspektų – Dapr nėra tik Microsoft ekosistemos dalykas. Jį naudoja įmonės kaip Alibaba, Zeiss, Ignition Group ir daugelis kitų. Tai rodo, kad projektas tikrai sprendžia realias problemas.
Ateityje tikėtina, kad Dapr taps dar labiau integruotas su kitais CNCF projektais. Jau dabar yra gera integracija su Prometheus, Grafana, Fluentd. WebAssembly palaikymas taip pat yra roadmap’e, kas galėtų atverti visiškai naujų galimybių.
Ar verta investuoti laiką į Dapr mokymąsi
Grįžtant prie pagrindinio klausimo – ar Dapr verta jūsų laiko? Jei kuriate arba palaikote mikroservisų architektūrą, atsakymas greičiausiai yra taip.
Dapr nėra sidabrinė kulka, kuri išspręs visas problemas. Jis prideda papildomą abstraction layer’į, kurį reikia suprasti ir valdyti. Debugging gali būti sudėtingesnis, kai tarp jūsų kodo ir infrastruktūros yra dar vienas komponentas. Ir kaip su bet kokia technologija, yra learning curve.
Bet privalumai dažnai nusveria trūkumus. Galimybė keisti infrastruktūros komponentus nekeičiant kodo, built-in observability, standartizuoti patterns – visa tai leidžia greičiau kurti ir lengviau palaikyti sistemas. Ypač jei komandoje dirba žmonės su skirtingų kalbų background’u, Dapr suteikia bendrą kalbą ir API.
Jei tik pradėjote kelionę į mikroservisus, Dapr gali padėti išvengti daugelio įprastų klaidų. Jei jau turite veikiančią sistemą, migracija gali būti laipsniška – galite pradėti naudoti Dapr vienam ar keliems building blocks, nekeisdami visos architektūros iš karto.
Galiausiai, Dapr mokymasis – tai investicija į cloud-native skills, kurios tampa vis svarbiesnės. Net jei nuspręsite nenaudoti Dapr produkcijoje, supratimas apie distributed systems patterns, kuriuos jis įgyvendina, bus naudingas bet kurioje paskirstytų sistemų kūrimo situacijoje.
