A Service Mesh egy elterjedt architekturális minta a mikroservices integrációjához és a felhőinfrastruktúrára való áttéréshez. Ma már nehéz elképzelni a felhőalapú konténer világát nélküle. A piacon több open-source Service Mesh megvalósítás is elérhető, de funkcionalitásuk, megbízhatóságuk és biztonságuk gyakran nem elegendő, különösen, amikor nagy országos pénzügyi vállalatok követelményeiről van szó. Ezért a Sbertechnél úgy döntöttünk, hogy testre szabjuk a Service Mesht, és szeretnénk elmondani, mi a jó a Service Meshben, mi az, ami nem annyira, és hogy mit tervezünk ezzel kapcsolatban.
A Service Mesh mintázat népszerűsége együtt nő a felhőtechnológiák elterjedésével. Ez egy dedikált infrastrukturális réteg, amely megkönnyíti a különböző hálózati szolgáltatások közötti interakciót. A modern felhőalkalmazások több száz, sőt ezer ilyen szolgáltatásból állnak, mindegyiknek akár ezer másolata is lehet.
A szolgáltatások közötti interakció és azok irányítása a Service Mesh kulcsfontosságú feladata. Valójában ez egy proxykkal teli hálózati modell, amelyet központilag kezelnek, és számos nagyon hasznos funkciót lát el.
A proxy szinten (data plane):
- Irányítási és forgalomelosztási politikák megadása és terjesztése
- Kulcsok, tanúsítványok, tokenek terjesztése
- Telemetria összegyűjtése, monitoring metrikák kialakítása
- Integráció a biztonsági és monitoring infrastruktúrával
A vezérlési síkon (control plane):
- Irányítási és forgalomelosztási politikák alkalmazása
- Ismétlések és időtúllépések kezelése, "halott" csomópontok meghatározása (circuit breaking), hibakezelés (injecting faults) és a szolgáltatások ellenállásának biztosítása más mechanizmusok révén
- Hívások hitelesítése/engedélyezése
- Metrikák elvetése (observability)
A technológia fejlődésében érdekelt felhasználók köre nagyon széles — a kis startupoktól a nagy internetes vállalatokig, mint például a PayPal.
Miért van szükség a Service Mesh-re a vállalati szektorban
A Service Mesh használata számos nyilvánvaló előnyt kínál. Mindenekelőtt ez kényelmes a fejlesztők számára: a kód írásához technológiai platform jön létre, amely lényegesen megkönnyíti a felhőinfrastruktúrába való integrációt azáltal, hogy a szállítási réteg teljesen el van szigetelve az alkalmazási logikától.
Ezen kívül, A Service Mesh egyszerűsíti a szolgáltatók és fogyasztók közötti viszonyokat. Ma a szolgáltatók és az API-fogyasztók sokkal könnyebben tudnak megállapodni az interfészekről és a szerződésekről önállóan, anélkül, hogy külön integrációs közvetítőt és arbitrát vonnának be – a vállalati szolgáltatási buszt. Ez a megközelítés lényegesen befolyásolja a két mutatót. Növekszik az új funkciók piacra vitele (time-to-market), de ezzel párhuzamosan a megoldás költsége is emelkedik, mivel az integrációt maguknak kell megoldaniuk. A Service Mesh használata a vállalkozási funkciók fejlesztői csapatai által lehetővé teszi a megfelelő egyensúly megtartását. Ennek eredményeként az API-szolgáltatók kizárólag a szolgáltatásuk alkalmazási részére tudnak koncentrálni, és egyszerűen közzétehetik azt a Service Mesh-en – az API azonnal elérhetővé válik minden ügyfél számára, az integráció minősége pedig production ready, és nem igényel további kódot.
A következő előny az, hogy a fejlesztő, a Service Mesh használatával, kizárólag az üzleti funkciókra összpontosít — a termék, nem pedig a technológiai részére a szolgáltatásának. Például már nem kell gondolkodni azon, hogy amikor a szolgáltatást hálózaton keresztül hívják meg, valahol megszakadhat a kapcsolat. Ezen kívül a Service Mesh segít kiegyensúlyozni a forgalmat a ugyanazon szolgáltatás másolatai között: ha az egyik másolat "elhunyt", akkor a rendszer az összes forgalmat az megmaradt életképes másolatokra irányítja.
Szolgáltatás Mesh — ez egy jó alapot ad a elosztott alkalmazások létrehozásához, amely elrejti az ügyfél elől a hívások részleteit a szolgáltatásaihoz, mind belső, mind külső szempontból. Minden alkalmazás, amely a Service Mesh-t használja, a szállítási szinten el van szigetelve a hálózattól és egymástól: nincs kapcsolat közöttük. Ezzel együtt a fejlesztő teljes kontrollt kap a szolgáltatásai felett.
Nem hagyható figyelmen kívül, hogy az elosztott alkalmazások frissítése olyan környezetben, ahol Service Mesh-t használnak, egyszerűbbé válik. Például a kék/zöld telepítés, amelynél két alkalmazáskörnyezet áll rendelkezésre a telepítés céljából, az egyik nem frissül, és várakozó állapotban van. A korábbi verzióra való visszatérés a sikertelen kiadás esetén egy speciális router segítségével történik, amelynek szerepét a Service Mesh kiválóan ellátja.. Az új verzió tesztelésére canary release – a forgalom 10%-át vagy a tesztcsoport ügyfeleinek kéréseit csak az új verzióra irányítják. A fő forgalom a régi verzión marad, így semmi nem törik el.
Ezenkívül A Service Mesh valós idejű SLA-ellenőrzést biztosít számunkra.A disztribúciós proxyk rendszere nem engedi, hogy a szolgáltatás leálljon, amikor valamelyik ügyfél túllépi a neki kiadott kvótát. Ha az API sávszélessége korlátozott, senki sem tudja DDoS-olni nagy mennyiségű tranzakcióval: a Service Mesh a szolgáltatás előtt áll, és nem engedi át a felesleges forgalmat. Ez egyszerűen az integrációs rétegben leütődne, és a szolgáltatások továbbra is működnének, úgy, hogy nem is veszik észre.
Ha a vállalat csökkenteni szeretné az integrációs megoldások fejlesztési költségeit, akkor a Service Mesh is segít: az open-source verziójára át lehet térni a kereskedelmi termékekről.Az Enterprise Service Mesh-ünk az open-source verzión alapul.
Egy másik előny – az integrációs szolgáltatások teljes készlete.Mivel az összes integráció ezen a köztes rétegen keresztül épül fel, képesek vagyunk kezelni az összes integrációs forgalmat és a kapcsolatokat az alkalmazások között, amelyek a vállalat üzleti magját képezik. Ez nagyon kényelmes.
Végül A Service Mesh ösztönzi a vállalatot a dinamikus infrastruktúrára való áttérésre. Most sokan a konténerizáció felé fordulnak. A monolitot mikro-szolgáltatásokra bontani, mindezt szépen bevezetni – ez a téma népszerűségnek örvend. De amikor megpróbálod egy régi, évek óta gyártásban lévő rendszert új sínekre állítani, azonnal számos problémával szembesülsz: minden ezt a konténerekbe beleszorítani és a platformon telepíteni nem egyszerű. Az ezen elosztott komponensek bevezetése, szinkronizálása és interakciója – ez egy újabb rendkívül bonyolult téma. Hogyan fognak kommunikálni egymással? Nem lesznek kaszkádos meghibásodások? A Service Mesh lehetővé teszi ezen problémák egy részének megoldását, és megkönnyíti a régi architektúráról az újra való migrálást azáltal, hogy elfelejthetjük a hálózati váltás logikáját.
Miért szükséges a Service Mesh testreszabása
Cégünknél több száz rendszer és modul működik együtt, a futásidő pedig nagyon megterhelt. Így az a klasszikus minta, amikor egy rendszer hív egy másikat és választ kap, nem elegendő, mert a gyártási környezetben többre van szükségünk. Mi még szükséges a vállalati Service Mesh-től?
Eseményfeldolgozó szolgáltatás
Képzeljük el, hogy real-time eseményfeldolgozást kell megvalósítanunk — egy rendszert, amely valós időben elemzi az ügyfél tevékenységét és azonnal releváns ajánlatot tud tenni. Ilyen funkcionalitás megvalósításához használják az eseményvezérelt architektúra (event-driven architecture, EDA) nevű architekturális mintát. Jelenleg egyetlen Service Mesh sem támogatja ezeket a mintákat natívan, pedig ez nagyon fontos, különösen egy bank számára!
Elég furcsa, hogy a "távoli hívás" Remote Procedure Call (RPC) minden Service Mesh verziót támogat, de az EDA-val nem kompatibilisek. Mert a Service Mesh egyfajta modern elosztott integráció, míg az EDA egy nagyon aktuális architekturális minta, amely lehetővé teszi az ügyfélélmény szempontjából egyedi dolgok megvalósítását.
A mi Enterprise Service Mesh-ünknek ezt a problémát kell megoldania. Ezen kívül szeretnénk, ha a garantált kézbesítést, a folyamatos és komplex eseményfeldolgozást különféle szűrők és minták alkalmazásával látná el.
Fájlátviteli szolgáltatás
Az EDA mellett jó lenne fájlokat is átadni: az Enterprise szintjén gyakran csak fájlintegráció lehetséges. Különösen az ETL (Extract, Transform, Load — „kivonás, átalakítás, betöltés”) architekturális mintát használják. Ebben általában mindenki csak fájlokat cserél: nagy adatokat használnak, amelyeket nem érdemes külön lekérdezésekkel kezelni. A fájlátvitel natív támogatásának lehetősége az Enterprise Service Mesh-ben szükséges rugalmasságot biztosít a vállalat számára.
Orkesztráló szolgáltatás
A nagyobb szervezetekben szinte mindig vannak különböző csapatok, amelyek különböző termékeken dolgoznak. Például egy bankban egyes csapatok a betétek kezelésével foglalkoznak, míg mások a hiteltermékekkel, és ilyen típusú esetekből elegendő van. Ezek különböző emberek, különböző csapatok, akik saját termékeiket alakítják ki, saját API-jukat fejlesztik, és mások számára kínálják. Gyakran felmerül a szükség ezen szolgáltatások összetételére, valamint egy bonyolult API hívás sorozat logikájának megvalósítására. E probléma megoldásához egy integrációs rétegre van szükség, amely lehetővé teszi az összes kompozit logika (több API hívás, kérések útvonalának leírása stb.) egyszerűsítését. Ez az Enterprise Service Mesh orkestrálási szolgáltatása.
AI és ML
Amikor a mikroszolgáltatások egyetlen integrációs rétegen, a Service Mesh-en keresztül kommunikálnak, természetesen mindent tud a szolgáltatások egymás közötti hívásairól. Telemetriát gyűjtünk: ki kit hívott, mikor, mennyi ideig, hányszor és így tovább. Amikor ezek a szolgáltatások számos tízezerre rúgnak, és a hívások száma milliárdokra nő, mindez felhalmozódik és Big Data-t alkot. Ezeket az adatokat AI, gépi tanulás és hasonló eszközök segítségével elemezhetjük, majd a vizsgálat eredményei alapján hasznos dolgot hozhatunk létre. Érdemes lenne legalább részben az mesterséges intelligenciára bízni az összes hálózati forgalom és az API hívások irányítását, amelyeket a Service Mesh-be integrált alkalmazások végeznek.
API Gateway szolgáltatás (API Gateway)
A Service Mesh-ben általában létezik proxy és azok a szolgáltatások, amelyek egymással kommunikálnak a megbízott határokon belül. De léteznek külső partnerek is. Az API-kra vonatkozó követelmények ennek a fogyasztói csoportnak lényegesen szigorúbbak. E feladatot két fő részre osztjuk.
- Biztonság. A ddos-szal, a protokollok, alkalmazások, operációs rendszerek sebezhetőségével kapcsolatos kérdések.
- Méretek. Amikor az API-k száma, amelyeket az ügyfeleknek át kell adni, ezrekre vagy akár százezrekre emelkedik, szükség van egy eszközre, amely kezeli ezt az API-készletet. Folyamatosan figyelemmel kell kísérni az API-kat: működnek-e, milyen állapotban vannak, mekkora forgalom folyik, milyen statisztikák állnak rendelkezésre, stb. Az API Gateway-nek meg kell tudnia oldani ezt a feladatot, irányítva és biztonságossá téve az egész folyamatot. E komponens révén az Enterprise Service Mesh tanul meg bonyodalmak nélkül publikálni belső és külső API-t is.
Speciális protokollok és adatformátumok támogatási szolgáltatása (AS átjáró)
Jelenleg a Service Mesh megoldások többsége natívan csak HTTP és HTTP2 forgalmat tud kezelni, vagy erősen korlátozott módban a TCP/IP szinten. Az Enterprise Service Mesh számos más, nagyon specifikus adatátviteli protokollt is tartalmaz. Egyes rendszerek üzenetbrókereket használhatnak, míg mások adatbázis-szinten integráltak. Ha a vállalatnak van SAP-ja, akkor az is használhat saját integrációs rendszert. Mindez működik, és fontos része az üzletnek.
Nem lehet csak úgy kijelenteni: „Mondjunk le a legacy rendszerekről, és hozzunk létre új rendszereket, amelyek képesek használni a Service Mesh-t”. Az összes régi rendszer újakkal (mikroszolgáltatás-architektúrával) való összekapcsolásához szükség lesz valamilyen adapterre, közvetítőre, átjáróra. Képzelje el, milyen jó lenne, ha ez automatikusan együtt járna a szolgáltatással. Az AS átjáró pontosan bármilyen integrációs lehetőséget támogat. Csak képzelje el, hogy egyszerűen telepíti az Enterprise Service Mesh-t, és máris készen áll minden szükséges protokollal való együttműködésre. Számunkra ez a megközelítés nagyon fontos.
Körülbelül így képzeljük el az Enterprise Service Mesh (vállalati) verzióját. Az előírt testreszabás a legtöbb problémát megoldja, amelyek az integrációs platform kész, open-source verzióinak használatakor merülnek fel. Csak néhány évvel ezelőtt megjelent a Service Mesh architektúra, és továbbra is fejlődik, örömmel hozzájárulunk fejlődéséhez. Reméljük, tapasztalatunk hasznos lesz az Ön számára.
Forrás: habr.com
