Kezdő cloudosként egy céges projektben erősen a dapr toolkit felé hajlok, mint orchestration réteg, ha valakinek van tapasztalata vele, vagy jobb jelöltje, ne fogja vissza magát.
Amire szükségünk van:
- Maximális számolási teljesítmény a lényeg (hibatűrés, georedundancia stb csak másodlagos, de esetleg később opció kell hogy legyen)
- Input request stream - output request stream a követelmény, semmit nem kell tárolni, legfeljebb statisztikákat, logokat
- Jelenleg több százas datacenter géppark szolgál ki minket, erről állunk át valamilyen cloudos technológiára
- 100% on-prem futtatási lehetőség, lehetőleg csak ingyenes open source eszközökkel, de burst terheléseket Azure-ba lehessen küldeni (muszáj Azure-t használni)
- Elég rugalmasan átkonfigurálható mikroszerviz hálózat kell nekünk (pl kiderülhet hogy egy gépen belülre kell költöztetni eddig különélő szerviz komponenseket stb)
- A mikroszervizek c++ ban lesznek írva, Grpc-n kommunikálnak (ez jól egybevág a dapr megoldásaival)
Ahogy elképzeljük:
- Grpc-n beérkező kéréseket fogunk szétosztani (1 MB - max 10 GB, tipikusan 50 MB)
- ehhez Grpc toolkit-tel generált c++ szervizeket haszálunk
- Ezekhez csak dapr sidecar-ok fognak direktben kapcsolódni, azok egymással is Grpcvel beszélnek (ahogy az dapr-ban standard)
- vegyesen Redis alapú pub/sub megoldást használunk, és direkt (aszinkron) szerviz-szerviz hívásokat
- a feladatok nagy részét pub-sub queue-re rácsatlakoztatott c++ feldolgozók végzik, amik egy eredmény queue-be teszik a kész resultokat
Ami nem világos:
- dapr elég jó-e erre
- a vázolt megoldás elég jó-e erre
Előre is köszi a hozzászólásokat.
- 163 megtekintés
Hozzászólások
A belinkelt projekt nem orchestration réteg. Ha komolyan gondolod (értsd: éles alkalmazást akarsz futtatni), akkor fog kelleni mellé (alája) valami orchestration is. Namost lehet pl. Docker Swarmozni, de ha igazi mikroservice architektúrás valamit csinálsz, meg többszáz gépes nagyságrendű DC-d van (ez nekem azt mondja, hogy nem 3-4 gépben meg 5-10 konténerben gondolkodsz), akkor elég hamar el fogsz oda jutni, hogy Kubernetest akarsz orchestrationnek, mert hiába egyszerű a Swarm, mint a kő, az a cipő hamar szorítani fog. Javaslom az ismerkedést.
Ezek a tételek pl. alapból "kezelve vannak" orchestration szinten, ha k8s-re építed az architektúrádat:
- 100% on-prem futtatási lehetőség, lehetőleg csak ingyenes open source eszközökkel, de burst terheléseket Azure-ba lehessen küldeni (muszáj Azure-t használni)
- Elég rugalmasan átkonfigurálható mikroszerviz hálózat kell nekünk (pl kiderülhet hogy egy gépen belülre kell költöztetni eddig különélő szerviz komponenseket stb)
Maximális számolási teljesítmény a lényeg - itt azért lehetnek gondjaitok az on-prem vs public cloud szolgáltatók terén. Persze nagyban függ ez attól is, hogy most milyen CPU-kat használtok. Ha throughputra gyúrtok, és masszívan párhuzamosítható a feladat, akkor gond egy szál se. Ha viszont a single thread teljesítmény is fontos (latencyre is gyúrtok), akkor a nagy cloud szolgáltatók által használt CPU-fajták nem biztos, hogy a legjobb eredményt adják, vagy legalábbis meglepődés lehet a vége.
A belinkelt cucc mindenképpen érdekesen hangzik. Viszont nálam a vörös fény ott gyullad fel, hogy ez egy 100% MS-projektnek látszik. A top10 contributor MS-alkalmazott. Szóval a "hozott koloncokat" meg kell alaposabban vizslatni, nehogy az egyik mancs beengedése után érkezzen a szokásos MS-only világ (.NET/C#/stb), mint a viccben, amikor "akárhogy raktam össze, végül mindig tank jött ki belőle".
semmit nem kell tárolni, legfeljebb statisztikákat, logokat
Valójában a legfontosabb dolog egy microservice architektúrájú alkalmazás üzemeltethetőségében az observability: metrics/(performance) monitoring, logging, tracing.
Update: kicsit megnéztem közelebbről ezt a belinkelt cuccot. A funkciók egy része úgy működik benne, hogy az adott feladatra (pl. pub/sub, stateful tárolás, secretek elérése, stb) elérhető elterjedtebb cloud és on-prem megoldásokra megpróbáltak ráhúzni valamit generikus interfészt, neked az alkalmazásodban csak azt kell használni, és így az implementációt cserélgetheted az alkalmazásod alatt, nem kell belenyúlni az alkalmazásba. Ez nagyon jól hangzik, de az ördög mindig a részletekben van: mennyire csereszabatosak az eltérő implementációk, mennyire bugos az egész, mekkora meló ez pl. az alkalmazásoddal együtt tesztelni. Vannak kétségeim, hogy ez tényleg ennyire jól használható, mint ahogy elsőre tűnik.
Meg érdemes megnézni, hogy mi az, ami GA:
https://docs.dapr.io/reference/components-reference/supported-state-sto…
https://docs.dapr.io/reference/components-reference/supported-pubsub/
- A hozzászóláshoz be kell jelentkezni
Köszi szépen a választ!
Throughputra gyúrunk, latency nem számít (hosszú, akár több órás jobokat kell számolni).
Természetesen az egészet Kubernetes + Linux alapon csináljuk, ezt elfelejtettem beleírni, annyira triviális volt.
Az orchestrationt mi a mikroszervizek fölött definiáljuk mint szervezési réteg, a Kubernetes egy üzemeltetési komponens csupán.
Szerintem a Microsoft ellenesség ideje eléggé lejárt. Ez az MS nem az, mint régen.
A .NET/c# is igazi multiplatform technológia lett, Linux is 100%-osan supportált platform.
Nagyon jó minőségű multiplatformos, és elég nagy teljesítményű kódot lehet benne írni: jó választás, ha nem maximálisan
teljesítménykritikus alkalmazásról van szó (itt arról).
Ugyanúgy a dapr is bár MS eredetű projekt, free source, forkolható licensz - innentől nagyjából mindegy is, hogy melyik cég van mögötte.
A rétegződés tehát ilyesmi lenne:
- Linux
- Kubernetes
- infrastruktúra komponensek:
-- KEDA (fel- és leskálázáshoz)
-- helyi pubsub queue (Redis?)
-- dapr központi komponensek
- konténerekben futva: [dapr sidecar+ saját c++ mikroszervizek]
- A hozzászóláshoz be kell jelentkezni
Az orchestration komoly problema komplex rendszerek felett.
A K8s nem igazan lat tobbet, mint egy-egy microservice. Ha a megoldasotok annyi, hogy van egy microservice, amely 1e6 peldanyban futkos, es csak a szamossaguk fontos, akkor nincs nagy gond.
Nem teljesen vilagos a futtatando rendszer komplexitasa. A [dapr sidecar+ saját c++ mikroszervizek] takarhat mar komolyabb dolgokat is. Ha mondjuk van 15 fele microservice, amelyek keresztbe-kasul egyuttmukodnek egyutt skalazodnak stb., az mar nem szimpla K8s.
Tehat, szervezned / latnod kell valami magasabb retegbeli entitasokat (egyszeruseg kedveert hivjuk ezeket applikacionak), akkor szukseged van valami masra/tobbre, mint amit a K8s nyujt. Kelleni fog egy "egyszerubb" resource orchestration reteg, amely ismeri az egyes applikaciok igenyeit, majd kisakkozza azokat a K8s segitsegevel. A open source azert fejlodik ezen a teren (pl. CNCF), de nem biztos, hogy talalsz 100%-os megoldast, eros kompromisszumokat leszel kenytelen kotni.
Ha meg magasabb szintu entitast definialnal (hivjuk mondjuk szolgaltatasnak, amelyet tobb applikacio egyuttesen nyujt), akkor egy meg komolyabb, retegre lesz szukseged (foleg, ha meg dinamikus is).
Szabvany nincs nagyon cloud nativ (k8s) rendszerekhez egyelore, de lassan talan sikerul. Jo sok penzert vannak profi megoldasok...
Erdemes lehet megnezni egy-egy vendor teljes rendszeret, termek es szolgaltataspalettajat. Ez is sulyos penzekbe kerulhet, de lehet, hogy megeri.
- A hozzászóláshoz be kell jelentkezni
Köszi szépen a választ!
Igen, nekünk pont ez lesz: 1-2 tucat együttműködő mikroservice, amelyek közül van, amiből 100 gépnyi kell, másból csak 1/2.
Én is pont úgy éreztem, ahogy írod (kell föléje egy orchestration réteg), én ezt véltem a dapr-ban megtalálni.
Elég rugalmasan, kívülről átkonfigurálhatónak tűnik a service-service hálózat a dapr-al, anélkül, hogy bele lennének égetve a szervizekbe a kapcsolatok (konfig vezérelt architektúra).
A cloud szolgáltatókkal az a gondunk, hogy
a) vendor lock-in,
b) ekkora méretnél, CPU intenzív feladatoknál jóval olcsóbb lehet, ha a feladat konstans terhelésű részét magunk oldjuk meg bérelt datacenterrel, csak a burst terhelést toljuk ki Azure-ba, szóval erősen az on-premet preferáljuk,
c) néha (törvényi előírások miatt) kliens maga akar futtatni lokálisan egy kulcsrakész copy-t a rendszerből (nem hagyhatja el az adat az országot), tehát cloud ilyen helyeken kizárt.
- A hozzászóláshoz be kell jelentkezni
Hat, ahogy nezem, jobban jarsz, ha egy beszalitohoz fordulsz. Az orchestration reteg kulon tudomany. Ha nem ez a fo teruletetek, akkor cipot a cipoboltbol (inkabb cipeszmestertol, ahogy a piac es az ipar jelenleg all)...
"magunk oldjuk meg bérelt datacenterrel, csak a burst terhelést toljuk ki Azure-ba" - Na, ez meg erdekesebbe teheti a problemat. Ha szeretnetek on-prem es HCP kevereket, raadasul mindezt dinamikusan (profi rendszereknel figyelembe veszik mikor melyik olcsobb pl.) akkor egy olyan megoldas kell, amely ad egy teljes orchestration reteget a sajat domainre, es egyuttmukodik a HCP orchestratoraval (hacsak nincs valami kulon megallapodasotok, amire szuksegetek lesz: "nem hagyhatja el az adat az országot").
Szep feladat. Ha kijottok egy jo megoldassal, abbol meg is lehet gazdagodni :)
- A hozzászóláshoz be kell jelentkezni