A Service Mesh egy jól ismert architektúra minta a mikroszolgáltatások integrálására és a felhő infrastruktúrára való áttérésre. Ma a felhőkonténer világában meglehetősen nehéz nélkülözni. Számos nyílt forráskódú service mesh implementáció elérhető már a piacon, de ezek funkcionalitása, megbízhatósága és biztonsága nem mindig elegendő, különösen, ha országszerte a nagy pénzügyi cégek igényeiről van szó. Ezért a Sbertechnél úgy döntöttünk, hogy testre szabjuk a Service Mesh-t, és szeretnénk beszélni arról, hogy mi a jó a Service Meshben, mi az, ami nem annyira menő, és mit fogunk tenni ellene.
A Service Mesh minta népszerűsége a felhőtechnológiák népszerűségével nő. Ez egy dedikált infrastruktúra réteg, amely leegyszerűsí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 vagy akár több ezer ilyen szolgáltatásból állnak, amelyek mindegyike több ezer másolatot tartalmazhat.
E szolgáltatások interakciója és kezelése a Service Mesh kulcsfontosságú feladata. Valójában ez számos proxy hálózati modellje, amelyeket központilag kezelnek, és nagyon hasznos funkciókat lát el.
Proxy szinten (adatsík):
- Útválasztási és forgalomelosztási szabályzatok hozzárendelése és elosztása
- Kulcsok, tanúsítványok, tokenek kiosztása
- Telemetria gyűjtése, felügyeleti mérőszámok generálása
- Integráció a biztonsági és felügyeleti infrastruktúrával
A vezérlősík szintjén:
- Útválasztási és forgalomelosztási szabályzatok alkalmazása
- Újrapróbálkozások és időtúllépések kezelése, „halott” csomópontok észlelése (áramkör megszakítása), a hibák kezelése és a szolgáltatás rugalmasságának biztosítása egyéb mechanizmusokon keresztül
- Hívás hitelesítés/engedélyezés
- A mutatók csökkenése (megfigyelhetőség)
A technológia fejlesztése iránt érdeklődő felhasználók köre nagyon széles - a kis startupoktól a nagy internetes vállalatokig, például a PayPal-ig.
Miért van szükség Service Mesh-re a vállalati szektorban?
A Service Mesh használatának számos egyértelmű előnye van. Először is, egyszerűen kényelmes a fejlesztők számára: kódíráshoz technológiai platform jelenik meg, ami jelentősen leegyszerűsíti a felhő infrastruktúrába való integrációt, mivel a szállítási réteg teljesen el van szigetelve az alkalmazáslogikától.
Továbbá, A Service Mesh leegyszerűsíti a kapcsolatot a szállítók és a fogyasztók között. Ma már sokkal könnyebb az API-szolgáltatók és a fogyasztók számára, hogy önállóan, speciális integrációs közvetítő és döntőbíró – a vállalati szolgáltatási busz – bevonása nélkül állapodjanak meg az interfészekről és szerződésekről. Ez a megközelítés két mutatót érint jelentősen. Növekszik az új funkcionalitás piacra kerülésének sebessége (time-to-market), ugyanakkor a megoldás költsége is nő, mivel az integrációt önállóan kell elvégezni. A Service Mesh üzleti funkcionalitást fejlesztő csapatok általi használata segít fenntartani az egyensúlyt. Ennek eredményeként az API-szolgáltatók kizárólag a szolgáltatásuk alkalmazáskomponensére koncentrálhatnak, és egyszerűen közzétehetik azt a Service Meshben – az API azonnal elérhető lesz minden ügyfél számára, az integráció minősége pedig készen áll a gyártásra, és nem igényel egyetlen sor további kódot.
A következő előny az a fejlesztő a Service Mesh használatával kizárólag az üzleti funkciókra összpontosít — a termékre, nem pedig a szolgáltatás technológiai elemére. Például már nem kell arra gondolni, hogy egy olyan helyzetben, amikor egy szolgáltatást a hálózaton keresztül hívnak, valahol kapcsolathiba léphet fel. Ezenkívül a Service Mesh segít kiegyenlíteni a forgalmat ugyanannak a szolgáltatásnak a másolatai között: ha az egyik példány „elhal”, a rendszer az összes forgalmat a fennmaradó élő példányokra kapcsolja át.
Service Mesh - ez jó alap az elosztott alkalmazások létrehozásához, amely elrejti az ügyfél elől szolgáltatásai belső és külső hívásainak nyújtásának részleteit. A Service Mesh-t használó összes alkalmazás szállítási szinten el van szigetelve a hálózattól és egymástól is: nincs kommunikáció közöttük. Ebben az esetben a fejlesztő teljes ellenőrzést kap szolgáltatásai felett.
Megjegyzendő Az elosztott alkalmazások frissítése szolgáltatásháló-környezetben könnyebbé válik. Például egy kék/zöld telepítés, amelyben két alkalmazáskörnyezet áll rendelkezésre a telepítéshez, amelyek közül az egyik nincs frissítve, és készenléti módban van. Sikertelen kiadás esetén az előző verzióra való visszaállítást egy speciális útválasztó végzi, amelynek szerepével a Service Mesh jól megbirkózik.. Az új verzió teszteléséhez használhatja kanári kiadás — csak a forgalom vagy a kísérleti ügyfélcsoporttól érkező kérések 10%-a váltson át az új verzióra. A fő forgalom a régi verzióra megy, nem törik el semmi.
Is A Service Mesh valós idejű SLA-vezérlést biztosít számunkra. Az elosztott proxyrendszer nem engedi, hogy a szolgáltatás meghibásodjon, ha az egyik kliens túllépi a hozzá rendelt kvótát. Ha az API átviteli sebessége korlátozott, senki sem tudja túlterhelni azt nagy számú tranzakcióval: a Service Mesh a szolgáltatás előtt áll, és nem engedi a felesleges forgalmat. Egyszerűen visszavág az integrációs rétegben, és maguk a szolgáltatások továbbra is működni fognak anélkül, hogy ezt észrevennék.
Ha egy vállalat csökkenteni szeretné az integrációs megoldások fejlesztésének költségeit, a Service Mesh is segít: Kereskedelmi termékekből válthat nyílt forráskódú verziójára. Enterprise Service Meshünk a Service Mesh nyílt forráskódú verzióján alapul.
Egy másik előny - egyetlen teljes értékű integrációs szolgáltatás elérhetősége. Mivel minden integráció ezen a köztes szoftveren keresztül épül fel, kezelni tudjuk az összes integrációs forgalmat és az alkalmazások közötti kapcsolatokat, amelyek a vállalat üzleti magját képezik. Nagyon kényelmes.
És végül A Service Mesh arra ösztönzi a vállalatokat, hogy egy dinamikus infrastruktúrára térjenek át. Most sokan a konténerezés felé néznek. Monolit mikroszolgáltatásokba vágása, mindezt gyönyörűen megvalósítani - a téma felfutóban van. Ám amikor egy sok éve éles rendszert próbálunk átvinni egy új platformra, azonnal számos problémába ütközünk: mindezt konténerekbe tolni és a platformra telepíteni nem könnyű. És ezeknek az elosztott komponenseknek a megvalósítása, szinkronizálása és interakciója egy másik nagyon összetett téma. Hogyan fognak kommunikálni egymással? Lesznek-e lépcsőzetes hibák? A Service Mesh lehetővé teszi ezen problémák némelyikének megoldását, és megkönnyíti az átállást a régi architektúráról az újra, mivel elfelejtheti a hálózati csere logikáját.
Miért van szüksége a Service Mesh testreszabására?
Cégünkben több száz rendszer és modul létezik egymás mellett, a futásidő nagyon leterhelt. Tehát nem elég egy egyszerű minta, hogy az egyik rendszer felhívja a másikat és megkapja a választ, mert a termelésben többet akarunk. Mi kell még egy vállalati szolgáltatáshálótól?
Eseményfeldolgozási szolgáltatás
Képzeljük el, hogy valós idejű eseményfeldolgozást kell készítenünk – egy olyan rendszert, amely valós időben elemzi az ügyfél cselekedeteit, és azonnal releváns ajánlatot tud tenni számára. Hasonló funkciók megvalósításához használja a eseményvezérelt architektúrának (EDA) nevezett építészeti minta. A jelenlegi szervizhálók egyike sem támogatja natívan az ilyen mintákat, de ez nagyon fontos, különösen egy bank számára!
Elég furcsa, hogy a távoli eljáráshívást (RPC) a Service Mesh minden verziója támogatja, de nem barátkoznak az EDA-val. Mivel a Service Mesh egyfajta modern elosztott integráció, az EDA pedig egy nagyon releváns építészeti minta, amely lehetővé teszi, hogy egyedi dolgokat tegyen az ügyfélélmény szempontjából.
Az Enterprise Service Mesh-ünknek meg kell oldania ezt a problémát. Ezen kívül szeretnénk látni benne a garantált kézbesítés, streaming és komplex eseményfeldolgozás megvalósítását különféle szűrők és sablonok segítségével.
Fájlátviteli szolgáltatás
Az EDA mellett jó lenne, ha fájlok átvitele is lehetséges lenne: vállalati léptékben nagyon gyakran csak a fájlintegráció lehetséges. Különösen az ETL (Extract, Transform, Load) építészeti mintát használják. Ebben általában mindenki kizárólag fájlokat cserél: big data-t használnak, amit nem praktikus külön kérések beküldése. Az Enterprise Service Mesh-ben a fájlátvitel natív támogatásának képessége olyan rugalmasságot biztosít, amelyre az üzleti életnek szüksége van.
Hangszerelési szolgáltatás
A nagy szervezetekben szinte mindig különböző csapatok készítik a különböző termékeket. Például egy bankban egyes csapatok betétekkel, mások hiteltermékekkel dolgoznak, és elég sok ilyen eset van. Ezek különböző emberek, különböző csapatok, akik készítik termékeiket, fejlesztik az API-kat és biztosítják azokat másoknak. És nagyon gyakran szükség van ezeknek a szolgáltatásoknak az összeállítására, valamint összetett logika megvalósítására az API-k sorozatának szekvenciális hívásához. A probléma megoldásához olyan megoldásra van szüksége az integrációs rétegben, amely leegyszerűsíti ezt az összetett logikát (több API meghívása, kérés útvonalának leírása stb.). Ez a hangszerelési szolgáltatás az Enterprise Service Meshben.
AI és ML
Amikor a mikroszolgáltatások egyetlen integrációs rétegen keresztül kommunikálnak, a Service Mesh természetesen mindent tud az egyes szolgáltatások hívásairól. Telemetriát gyűjtünk: ki kit hívott, mikor, mennyi ideig, hányszor stb. Ha több százezer ilyen szolgáltatás van, és több milliárd hívás van, akkor mindez felhalmozódik és Big Data-t képez. Ezeket az adatokat mesterséges intelligencia, gépi tanulás stb. segítségével lehet elemezni, majd az elemzési eredmények alapján hasznos dolgokat lehet tenni. Ennek a Service Mesh-be integrált összes hálózati forgalomnak és alkalmazáshívásoknak az irányítását célszerű lenne legalább részben átadni a mesterséges intelligenciának.
API átjáró szolgáltatás
A Service Mesh-nek általában vannak proxyjai és szolgáltatásai, amelyek megbízható területen belül beszélnek egymással. De vannak külső partnerek is. A fogyasztók ezen csoportjának kitett API-kra vonatkozó követelmények sokkal szigorúbbak. Ezt a feladatot két fő részre osztjuk.
- biztonság. A ddos-okkal kapcsolatos problémák, a protokollok, alkalmazások, operációs rendszerek stb. sebezhetősége.
- Mérleg. Amikor az ügyfelek számára kiszolgálandó API-k száma eléri a több ezret vagy akár a százezreket, szükség van valamilyen felügyeleti eszközre ehhez az API-készlethez. Folyamatosan figyelni kell az API-t: működnek-e vagy sem, milyen állapotúak, milyen forgalom folyik, milyen statisztikák stb. Ezt a feladatot egy API-átjárónak kell kezelnie, miközben a teljes folyamatot kezelhetővé és biztonságossá kell tennie. Ennek az összetevőnek köszönhetően az Enterprise Service Mesh megtanulja a belső és külső API-k egyszerű közzétételét.
Támogatási szolgáltatás meghatározott protokollokhoz és adatformátumokhoz (AS átjáró)
Jelenleg a legtöbb Service Mesh megoldás natív módon csak HTTP és HTTP2 forgalommal, vagy csökkentett módban, TCP/IP szinten működik. Az Enterprise Service Mesh sok más nagyon specifikus adatátviteli protokollal együtt jelenik meg. Egyes rendszerek üzenetközvetítőket használnak, mások adatbázis-szinten vannak integrálva. Ha a cég rendelkezik SAP-val, akkor saját integrációs rendszert is használhat. Ráadásul mindez működik, és fontos része az üzletnek.
Nem mondhatja csak úgy: „Hagyjuk fel az örökséget, és készítsünk új rendszereket, amelyek képesek használni a Service Mesh-et.” Az összes régi rendszer összekapcsolásához az újakkal (mikroszolgáltatási architektúrán), a Service Mesh-t használó rendszereknek szükségük lesz valamilyen adapterre, közvetítőre, átjáróra. Egyetértek, jó lenne, ha dobozban érkezne a szolgáltatással együtt. Az AC átjáró bármilyen integrációs lehetőséget támogat. Képzelje el, csak telepíti az Enterprise Service Mesh-t, és készen áll az összes szükséges protokollra. Ez a megközelítés nagyon fontos számunkra.
Nagyjából így képzeljük el a Service Mesh (Enterprise Service Mesh) vállalati verzióját. A leírt testreszabás megoldja az integrációs platform kész nyílt forráskódú verzióinak használatakor felmerülő problémák nagy részét. A mindössze néhány éve bemutatott Service Mesh architektúra folyamatosan fejlődik, és izgatottak vagyunk, hogy hozzájárulhatunk a fejlesztéséhez. Reméljük, hogy tapasztalataink hasznosak lesznek az Ön számára.
Forrás: will.com