Ahogy a monolitikus alkalmazásról a mikroszolgáltatási architektúrára térünk át, új kihívásokkal nézünk szembe.
Egy monolitikus alkalmazásban általában meglehetősen könnyű meghatározni, hogy a rendszer melyik részében történt a hiba. Valószínűleg a probléma magában a monolit kódjában vagy az adatbázisban van. De amikor elkezdünk egy mikroszolgáltatási architektúrában problémát keresni, már nem minden olyan nyilvánvaló. Meg kell találnunk a kérés teljes útvonalát az elejétől a végéig, és ki kell választanunk több száz mikroszolgáltatás közül. Sőt, sokuk saját tárolóval is rendelkezik, ami logikai hibákat, valamint teljesítmény- és hibatűrési problémákat is okozhat.
Régóta keresek egy olyan eszközt, ami segít megbirkózni az ilyen problémákkal (erről írtam a Habrén: , ), de végül elkészítettem a saját nyílt forráskódú megoldásomat. Ebben a cikkben a szolgáltatásháló-megközelítés előnyeiről beszélek, és megosztok egy új eszközt a megvalósításához.
Az elosztott nyomkövetés gyakori megoldás az elosztott rendszerekben előforduló hibakeresés problémájára. De mi van akkor, ha a hálózati interakciókra vonatkozó információgyűjtésnek ezt a megközelítését még nem implementálták a rendszerben, vagy ami még rosszabb, a rendszer egy részén már megfelelően működik, de részben nem, mivel nem adták hozzá a régi szolgáltatásokhoz ? A probléma pontos kiváltó okának meghatározásához teljes képre van szükség arról, hogy mi történik a rendszerben. Különösen fontos megérteni, hogy mely mikroszolgáltatások vesznek részt a kulcsfontosságú üzleti kritikus utakon.
Itt jöhet a segítségünkre a service mesh megközelítés, amely a hálózati információk gyűjtésének összes gépezetével alacsonyabb szinten fog foglalkozni, mint amennyit maguk a szolgáltatások működtetnek. Ez a megközelítés lehetővé teszi számunkra, hogy az összes forgalmat elfogjuk és menet közben elemezzük. Sőt, az alkalmazásoknak nem is kell tudniuk róla semmit.
Service mesh megközelítés
A szolgáltatásháló-megközelítés fő ötlete egy másik infrastruktúra réteg hozzáadása a hálózathoz, amely lehetővé teszi számunkra, hogy bármit megtegyünk a szolgáltatások közötti interakcióval. A legtöbb implementáció a következőképpen működik: minden mikroszolgáltatáshoz egy további oldalkocsis konténer kerül átlátszó proxyval, amelyen keresztül a szolgáltatás összes bejövő és kimenő forgalma áthalad. És ez az a hely, ahol ügyfeleink egyensúlyozását végezhetjük, biztonsági szabályzatokat alkalmazhatunk, korlátozhatjuk a kérések számát, és fontos információkat gyűjthetünk a szolgáltatások interakciójáról a termelésben.
Решения
Ennek a megközelítésnek már számos megvalósítása létezik: и . Nagyon sok funkciót kínálnak a dobozból. Ugyanakkor az erőforrásokra is nagy ráfordítás jelentkezik. Ráadásul minél nagyobb klaszterben működik egy ilyen rendszer, annál több erőforrásra lesz szükség az új infrastruktúra karbantartásához. Az Avitóban kubernetes-fürtöket üzemeltetünk, amelyek több ezer szolgáltatáspéldányt tartalmaznak (és számuk folyamatosan növekszik). Jelenlegi megvalósításában az Istio ~300 Mb RAM-ot fogyaszt szolgáltatáspéldányonként. A lehetőségek nagy száma miatt a transzparens egyensúlyozás a szolgáltatások teljes válaszidejét is befolyásolja (10ms-ig).
Ennek eredményeként megvizsgáltuk, hogy most pontosan milyen képességekre van szükségünk, és úgy döntöttünk, hogy a fő ok, amiért elkezdtünk ilyen megoldásokat implementálni, az volt, hogy a teljes rendszerből átláthatóan gyűjthetjük a nyomkövetési információkat. Azt is szerettük volna ellenőrizni a szolgáltatások interakcióját, és különféle manipulációkat végezni a szolgáltatások között átvitt fejlécekkel.
Ennek eredményeként arra a döntésre jutottunk: .
Netramesh
egy könnyű szervizhálós megoldás, amely végtelenül skálázható, függetlenül a rendszerben lévő szolgáltatások számától.
Az új megoldás fő célja az alacsony erőforrás-ráfordítás és a magas teljesítmény volt. A főbb jellemzők közül azonnal azt szerettük volna elérni, hogy a Jaeger rendszerünkbe transzparensen küldhessük a nyomkövetési szakaszokat.
Ma a legtöbb felhőmegoldás Golangban van megvalósítva. És persze ennek megvannak az okai. Kényelmes és meglehetősen egyszerű olyan hálózati alkalmazásokat írni Golang nyelven, amelyek az I/O-val aszinkron módon működnek, és szükség szerint skálázhatók a magok között. És ami szintén nagyon fontos, a teljesítmény elegendő a probléma megoldásához. Ezért választottuk mi is Golangot.
termelékenység
Erőfeszítéseinket a maximális termelékenység elérésére összpontosítottuk. A szolgáltatás minden példánya mellett telepített megoldáshoz kis RAM- és CPU-időigényre van szükség. És természetesen a válaszkésleltetésnek is kicsinek kell lennie.
Lássuk, milyen eredményeket értünk el.
RAM
A Netramesh ~10 Mb-ot fogyaszt forgalom nélkül, és maximum 50 Mb-ot, akár 10000 XNUMX RPS-es terhelés mellett példányonként.
Az Istio envoy proxy mindig ~300Mb-ot fogyaszt a több ezer példányt tartalmazó fürteinkben. Ez nem teszi lehetővé a teljes fürtre méretezést.
A Netramesh segítségével ~ 10-szeres memóriafogyasztást kaptunk.
CPU
A CPU-használat terhelés alatt viszonylag egyenlő. Ez az oldalkocsihoz érkezett időegységenkénti kérések számától függ. Értékek 3000 kérésnél másodpercenként csúcsidőben:
Van még egy fontos pont: Netramesh - a vezérlősík nélküli és terhelés nélküli megoldás nem fogyaszt CPU-időt. Az Istio segítségével az oldalkocsik mindig frissítik a szolgáltatás végpontjait. Ennek eredményeként ezt a képet terhelés nélkül láthatjuk:
A szolgáltatások közötti kommunikációhoz HTTP/1-et használunk. A válaszidő növekedése az Istio esetében 5-10 ms-ra nőtt az envoy-n keresztüli proxyzás során, ami elég sok olyan szolgáltatások esetében, amelyek egy ezredmásodperc alatt készek válaszolni. A Netramesh-nél ez az idő 0.5-2 ms-ra csökkent.
Méretezhetőség
Az egyes proxy által felhasznált erőforrások kis mennyisége lehetővé teszi, hogy az egyes szolgáltatások mellett elhelyezhető. A Netramesh-t szándékosan vezérlősík-alkatrész nélkül hozták létre, hogy egyszerűen minden oldalkocsi könnyű legyen. A szervizhálós megoldásokban gyakran a vezérlősík szétosztja a szervizkeresési információkat minden oldalkocsinak. Ezzel együtt információkat kap az időtúllépésekről és az egyensúlyi beállításokról. Mindez sok hasznos dolgot tesz lehetővé, de sajnos méretben feldobja az oldalkocsikat.
Szolgáltatás felfedezése
A Netramesh nem ad hozzá további mechanizmusokat a szolgáltatáskereséshez. Minden forgalom transzparens módon, a netra oldalkocsin keresztül történik.
A Netramesh támogatja a HTTP/1 alkalmazási protokollt. Ennek meghatározásához a portok konfigurálható listája használható. A rendszer általában több porttal rendelkezik, amelyeken keresztül a HTTP-kommunikáció történik. Például a szolgáltatások és a külső kérések közötti interakcióhoz a 80, 8890, 8080 értékeket használjuk, amelyek ebben az esetben egy környezeti változóval állíthatók be. NETRA_HTTP_PORTS.
Ha a Kubernetes-et irányítóként és annak szolgáltatási entitási mechanizmusaként használja a szolgáltatások közötti fürtön belüli kommunikációhoz, akkor a mechanizmus pontosan ugyanaz marad. Először a mikroszolgáltatás a kube-dns segítségével szerzi be a szolgáltatási IP-címet, és új kapcsolatot nyit meg vele. Ez a kapcsolat először a helyi netra-sidecarral jön létre, és az összes TCP-csomag először a netrához érkezik. Ezután a netra-sidecar kapcsolatot létesít az eredeti célállomással. A NAT a pod IP-n a csomóponton pontosan ugyanaz marad, mint a netra nélkül.
Elosztott nyomkövetés és kontextus továbbítás
A Netramesh biztosítja a HTTP-interakciók nyomkövetési szakaszainak küldéséhez szükséges funkciókat. A Netra-sidecar elemzi a HTTP protokollt, méri a kérések késését, és kivonja a szükséges információkat a HTTP fejlécekből. Végül az összes nyomot egyetlen Jaeger rendszerben kapjuk meg. A finom konfiguráláshoz használhatja a hivatalos könyvtár által biztosított környezeti változókat is .
De van egy probléma. Amíg a szolgáltatások nem hoznak létre és küldenek egy speciális uber-fejlécet, addig nem fogunk látni összekapcsolt nyomkövetési szakaszokat a rendszerben. És ez az, amire szükségünk van, hogy gyorsan megtaláljuk a problémák okát. A Netrameshnek itt is van megoldása. A proxy beolvassa a HTTP-fejléceket, és ha nem tartalmazza az uber nyomkövetési azonosítót, létrehoz egyet. A Netramesh emellett egy oldalkocsiban tárolja a bejövő és kimenő kérésekre vonatkozó információkat, és a szükséges kimenő kérések fejléceivel gazdagítja azokat. A szolgáltatásokban mindössze egyetlen fejlécet kell elküldenie X-Request-Id, amely egy környezeti változó segítségével konfigurálható NETRA_HTTP_REQUEST_ID_HEADER_NAME. A Netramesh kontextusméretének szabályozásához a következő környezeti változókat állíthatja be: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (az az idő, ameddig a kontextus tárolásra kerül) és NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (a környezettisztítás gyakorisága).
Lehetőség van arra is, hogy több útvonalat kombináljon a rendszeren, ha megjelöli őket egy speciális session tokennel. A Netra lehetővé teszi a telepítést HTTP_HEADER_TAG_MAP a HTTP-fejlécek megfelelő nyomkövetési span címkékké alakításához. Ez különösen a tesztelésnél lehet hasznos. A funkcionális teszt sikeres elvégzése után láthatja, hogy a rendszer mely részét érintette a megfelelő szekciókulcs szűrése.
A kérelem forrásának meghatározása
A kérés forrásának meghatározásához használhatja azt a funkciót, amely automatikusan hozzáad egy fejlécet a forráshoz. Környezeti változó használata NETRA_HTTP_X_SOURCE_HEADER_NAME Megadhat egy fejlécnevet, amely automatikusan telepítésre kerül. Használva NETRA_HTTP_X_SOURCE_VALUE beállíthatja azt az értéket, amelyre az X-Source fejléce minden kimenő kérésnél be lesz állítva.
Ez lehetővé teszi ennek a hasznos fejlécnek az egyenletes elosztását a hálózaton belül. Ezután használhatja a szolgáltatásokban, és hozzáadhatja a naplókhoz és a metrikákhoz.
Forgalomirányítás és belső Netramesh
A Netramesh két fő összetevőből áll. Az első, a netra-init hálózati szabályokat állít be a forgalom elfogására. Használja a forgalom egészének vagy egy részének felfogására az oldalkocsin, amely a Netramesh második fő összetevője. Beállíthatja, hogy mely portokat kell elfogni a bejövő és kimenő TCP-munkamenetekhez: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Az eszköznek van egy érdekes funkciója is - a valószínűségi útválasztás. Ha a Netramesh-t kizárólag a nyomkövetési tartományok gyűjtésére használja, akkor éles környezetben erőforrásokat takaríthat meg, és változók segítségével engedélyezheti a valószínűségi útválasztást. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0-tól 1-ig). Az alapértelmezett érték 1 (az összes forgalmat elfogják).
Sikeres elfogás után a netra oldalkocsi elfogadja az új kapcsolatot és használja SO_ORIGINAL_DST socket opciót az eredeti cél eléréséhez. A Netra ezután új kapcsolatot nyit az eredeti IP-címmel, és kétirányú TCP-kommunikációt hoz létre a felek között, figyelve az összes áthaladó forgalmat. Ha a port HTTP-ként van megadva, a Netra megpróbálja elemezni és nyomon követni. Ha a HTTP-elemzés sikertelen, a Netra visszatér a TCP-hez, és transzparensen proxyzza a bájtokat.
Függőségi gráf felépítése
Miután nagy mennyiségű nyomkövetési információt kaptam a Jaegerben, szeretnék egy teljes grafikont kapni a rendszer interakcióiról. De ha a rendszere meglehetősen terhelt, és naponta több milliárd nyomkövetési tartomány halmozódik fel, akkor ezek összesítése nem lesz olyan egyszerű feladat. Ennek hivatalos módja van: . A teljes grafikon elkészítése azonban órákat vesz igénybe, és arra kényszeríti, hogy letöltse a teljes adatkészletet a Jaegerből az elmúlt 24 órában.
Ha az Elasticsearch segítségével tárolja a nyomkövetési tartományokat, használhatja , amely percek alatt elkészíti ugyanazt a grafikont az Elasticsearch szolgáltatásaival és képességeivel.
Hogyan kell használni a Netramesh-t
A Netra könnyen hozzáadható bármely orchestratort futtató szolgáltatáshoz. Láthat egy példát .
Jelenleg a Netra nem tudja automatikusan bevezetni az oldalkocsikat a szolgáltatásokba, de vannak tervek a megvalósításra.
A Netramesh jövője
fő cél minimális erőforrás-költség és nagy teljesítmény elérése, alapvető képességek biztosítása a szolgálatok közötti kommunikáció megfigyelhetőségéhez és vezérléséhez.
A jövőben a Netramesh a HTTP-n kívül más alkalmazási rétegbeli protokollokat is támogatni fog. Az L7-es útválasztás a közeljövőben elérhető lesz.
Használja a Netramesh-t, ha hasonló problémákba ütközik, és írjon nekünk kérdéseivel és javaslataival.
Forrás: will.com