Jegyzet. ford.: A szervizháló olyan jelenség, amelynek még nincs stabil fordítása orosz nyelvre (több mint 2 évvel ezelőtt felajánlottuk a „háló a szolgáltatásokhoz” opciót, és kicsit később néhány kolléga elkezdte aktívan népszerűsíteni a „szolgáltatásszita” kombinációt). . Az erről a technológiáról való folyamatos beszéd olyan helyzethez vezetett, amelyben a marketing és a műszaki összetevők túlságosan szorosan összefonódnak. Ez a csodálatos anyag az eredeti kifejezés egyik szerzőjétől nem csak a mérnökök számára kíván egyértelműséget adni.
Képregény innen
Bevezetés
Ha Ön szoftvermérnök, aki valahol a háttérrendszerek területén dolgozik, a „service mesh” kifejezés valószínűleg már szilárdan rögzült a fejében az elmúlt néhány évben. Egy furcsa egybeesésnek köszönhetően ez a mondat egyre jobban átveszi az uralmat az iparágon, a hype és a kapcsolódó promóciós ajánlatok hógolyóként nőnek, röpködnek a dombról, és nem mutatják a lassulás jeleit.
A szolgáltatásháló a felhő natív ökoszisztémájának zavaros, tendenciózus vizeiben született. Sajnos ez azt jelenti, hogy az ezzel kapcsolatos viták nagy része az „alacsony kalóriatartalmú csevegéstől” a – szakkifejezéssel élve – kirívó baromságig terjed. De ha kiszűri az összes zajt, akkor azt tapasztalhatja, hogy a szervizhálónak nagyon is valóságos, határozott és fontos funkciója van.
Ebben a bejegyzésben ezt próbálom megtenni: őszinte, mélyreható, mérnök-orientált útmutatót nyújtok a szervizhálóhoz. Nem csak a kérdésre válaszolok: "Ami?", - de szintén "Miért?"És "Miért most?". Végül megpróbálom felvázolni, hogy (szerintem) miért váltott ki ekkora felhajtást ez a technológia, ami már önmagában is érdekes történet.
Ki vagyok én?
Sziasztok! A nevem . Én vagyok az egyik alkotó - a legelső service mesh projekt és az a projekt, amely a kifejezés megjelenéséért felelős szervizháló mint olyan (elnézést srácok!). (Megjegyzés ford.: Egyébként a kifejezés megjelenésének hajnalán, több mint 2,5 évvel ezelőtt már lefordítottuk ugyanannak a szerzőnek a korai anyagát "".) én is vezetek egy olyan startup, amely remek szolgáltatási hálókat épít, mint például a Linkerd és .
Valószínűleg sejtheti, hogy nagyon elfogult és szubjektív véleményem van erről a kérdésről. Igyekszem azonban minimálisra csökkenteni az elfogultságot (egy rész kivételével: – Miért beszélnek annyit a szervizhálóról?, - amelyben ennek ellenére megosztom előzetes elképzeléseimet). Minden tőlem telhetőt megteszek azért, hogy ez az útmutató a lehető legobjektívebb legyen. Konkrét példákban elsősorban a Linkerd tapasztalataira támaszkodok, miközben rámutatok azokra a különbségekre (ha vannak ilyenek), amelyeket más típusú szolgáltatásháló megvalósításában ismerek.
Oké, ideje folytatni a finomságokat.
Mi az a szervizháló?
Az összes hype ellenére a szervizháló szerkezetileg meglehetősen egyszerű. Ez csak egy csomó felhasználói terület proxy, amelyek a szolgáltatások "mellett" helyezkednek el (a "közelről" később még beszélünk), plusz egy sor vezérlési folyamat. A proxykat együttesen hívják adatsík, és a szabályozási folyamatokat ún vezérlő sík. Az adatsík elfogja a szolgáltatások közötti hívásokat, és "bármi mást" csinál velük; a vezérlősík, ill. koordinálja a proxy viselkedését és hozzáférést biztosít az Ön számára, pl. operátort az API-hoz, lehetővé téve a hálózat egészének manipulálását és mérését.
Mi ez a proxy? Ez a "Layer 7-aware" kategória TCP-proxyja (azaz "figyelembe véve" az OSI modell 7. rétegét) mint a HAProxy és az NGINX. Tetszés szerint választhat proxyt; A Linkerd egy egyszerű elnevezésű Rust proxyt használ . Kifejezetten a szervizhálóhoz állítottuk össze. Más hálók más proxykat részesítenek előnyben (az Envoy gyakori választás). A proxy kiválasztása azonban csak megvalósítás kérdése.
Mit csinálnak ezek a proxy szerverek? Nyilvánvalóan proxy-ként közvetítik a szolgáltatások felé és onnan érkező hívásokat (szigorúan véve proxyként és fordított proxyként működnek, kezelik a bejövő és kimenő hívásokat egyaránt). És olyan funkciókészletet valósítanak meg, amely a hívásokra összpontosít között szolgáltatások. Ez a szolgáltatások közötti forgalomra való összpontosítás különbözteti meg a szolgáltatásháló-proxyt például az API-átjáróktól vagy a bemeneti proxytól (utóbbiak a fürtbe a külvilágból érkező hívásokra összpontosítanak). (Jegyzet. ford.: A meglévő Kubernetes Ingress vezérlők összehasonlításához, amelyek közül sok a már említett Envoy-t használja, ld. .)
Tehát kitaláltuk az adatsíkot. A vezérlősík egyszerűbb: olyan komponensek halmaza, amelyek az adatsík összehangolt működéséhez szükséges összes mechanikát biztosítják, beleértve a szolgáltatás felderítést, a TLS tanúsítvány kiadását, a mérőszámok összesítését stb. Az adatsík tájékoztatja a vezérlősíkot viselkedése; viszont a vezérlősík olyan API-t biztosít, amely lehetővé teszi az adatsík egészének viselkedésének megváltoztatását és nyomon követését.
Az alábbiakban a Linkerd vezérlősík és adatsík diagramja látható. Amint látható, a vezérlősík számos különböző összetevőt tartalmaz, beleértve a Prometheus példányt, amely a proxyszerverektől gyűjti össze a mérőszámokat, valamint más összetevőket, mint pl. destination (szolgáltatás felfedezése), identity (hitelesítő hatóság, CA) és public-api (végpontok a webhez és a CLI-hez). Ezzel szemben az adatsík egy egyszerű linkerd-proxy az alkalmazáspéldány mellett. Ez csak egy logikai diagram; Valós környezetben az egyes vezérlősík-összetevők három replikája és több száz vagy több ezer proxy lehet az adatsíkon.
(Az ábrán a kék négyzetek a Kubernetes pod-ok határait jelzik. Látható, hogy a linkerd-proxyt tartalmazó tárolók ugyanabban a podban vannak, mint az alkalmazástárolók. Ez a séma az oldalkocsis konténer.)
A szolgáltatásháló architektúrának számos fontos következménye van. Először is, mivel a proxy feladata a szolgáltatások közötti hívások elfogása, a szolgáltatáshálónak csak akkor van értelme, ha az alkalmazás egy szolgáltatáskészlethez készült. háló tud monolitokkal használható, de ez egyértelműen redundáns egyetlen proxy miatt, és nem valószínű, hogy a funkcionalitására lesz kereslet.
Egy másik fontos következmény az, hogy a szervizháló megköveteli hatalmas proxy-k száma. Valójában a Linkerd minden szolgáltatás minden példányához linkerd-proxyt láncol (más megvalósítások minden csomóponthoz/gazdagéphez/VM-hez adnak proxyt. Ez amúgy is sok). A proxy ilyen aktív használata önmagában számos további bonyodalmat hordoz magában:
- Az adatsíkban lévő proxyknak kell lenniük gyors, mert minden híváshoz pár hívás érkezik a proxy felé: egy a kliens oldalon, egy a szerver oldalon.
- A proxyknak is kell lenniük kicsi и könnyűsúlyú. Mindegyik memória- és CPU-erőforrásokat fogyaszt, és ez a fogyasztás lineárisan nő az alkalmazással.
- Szüksége lesz egy mechanizmusra nagyszámú proxy telepítéséhez és frissítéséhez. A manuális végrehajtás nem választható.
Általánosságban a szolgáltatásháló így néz ki (legalábbis madártávlatból): telepítünk egy csomó userspace proxyt, amelyek „csinálnak valamit” a belső, szolgáltatásközi forgalommal, és a vezérlősíkot használják ezek figyelésére és kezelésére.
Itt az ideje a „Miért?” kérdésnek?
Mire való a szervizháló?
Azok számára, akik először találkoztak a szervizháló ötletével, megbocsátható, ha egy kicsit félnek. A szolgáltatásháló kialakítása azt jelenti, hogy nem csak növeli az alkalmazás késését, hanem azt is fogyaszt források és hozzá fogja tenni egy csomó új mechanizmus az infrastruktúrában. Először beállít egy szervizhálót, majd hirtelen azon kapja magát, hogy több száz (ha nem több ezer) proxyt kell kiszolgálnia. Felmerül a kérdés, hogy ki vállalkozik erre?
A kérdésre adott válasz két részből áll. Először is, az e proxy-k telepítésével kapcsolatos tranzakciós költségek jelentősen csökkenthetők az ökoszisztémában végbemenő változások miatt (erről később).
Másodszor, egy ilyen eszköz valójában egy nagyszerű módja annak, hogy további logikát vigyen be a rendszerbe. És nem csak azért, mert sok új funkciót lehet hozzáadni a service mesh segítségével, hanem azért is, mert ez az ökoszisztéma beavatkozása nélkül is megtehető. Valójában a teljes szolgáltatásháló-modell ezen a posztulátumon alapul: egy többszolgáltatásos rendszerben, bármi legyen is az csinálsz egyedi szolgáltatások, forgalom közöttük az ideális pont a funkciók hozzáadásához.
Például a Linkerdben (mint a legtöbb hálóban) a funkcionalitás elsősorban a HTTP-hívásokra összpontosít, beleértve a HTTP/2-t és a gRPC-t*. A funkcionalitás meglehetősen gazdag - három osztályba osztható:
- Kapcsolódó funkciók megbízhatóság. Újrapróbálkozás kérések, időtúllépések, kanári megközelítés (forgalomfelosztás/átirányítás) stb.
- Kapcsolódó funkciók monitoring. A sikerarányok, a késések és a kérések mennyiségének összesítése szolgáltatásonként vagy egyedi célállomásonként; szolgáltatások topológiai térképeinek építése stb.
- Kapcsolódó funkciók Biztonság. Kölcsönös TLS, beléptetés, stb.
* Linkerd szemszögéből a gRPC gyakorlatilag nem különbözik a HTTP/2-től: csak protobuf-ot használ a hasznos terhelésben. Fejlesztői szempontból ez a két dolog természetesen más.
E mechanizmusok közül sok a kérés szintjén működik (ezért az "L7 proxy"). Például, ha a Foo szolgáltatás HTTP-hívást kezdeményez a Bar szolgáltatáshoz, akkor a Foo oldalán lévő linkerd-proxy intelligensen képes terheléselosztani és a megfigyelt késleltetés alapján irányítani a hívásokat Foo-tól a Bar-példányig; szükség esetén (és ha idempotens) megismételheti a kérést; rögzítheti a válaszkódot és az időtúllépést stb. Hasonlóképpen, a Bar oldalon lévő linkerd-proxy elutasíthat egy kérést, ha az nem engedélyezett, vagy ha túllépik a kéréskorlátot; ki tudja javítani a késést a maga részéről stb.
A proxy-k „csinálhatnak valamit” a kapcsolat szintjén is. Például a Foo oldalon lévő linkerd-proxy kezdeményezhet TLS kapcsolatot, a Bar oldalon lévő linkerd-proxy pedig leállíthatja azt, és mindkét fél ellenőrizheti egymás TLS-tanúsítványait*. Ez nem csak a szolgáltatások közötti titkosítást biztosítja, hanem titkosításilag biztonságos módot is a szolgáltatások azonosítására: a Foo and Bar „bizonyíthatja”, hogy azok, akiknek mondják magukat.
* Az "egy barát barátja" azt jelenti, hogy az ügyfél tanúsítványa is ellenőrzött (kölcsönös TLS). A "klasszikus" TLS-ben például a böngésző és a szerver között általában csak az egyik oldal (a szerver) tanúsítványát ellenőrzik.
Függetlenül attól, hogy a kérés vagy a kapcsolat szintjén működnek, fontos hangsúlyozni, hogy minden szolgáltatási háló funkció igen működőképes karakter. A Linkerd nem tudja átalakítani a hasznos terhelés szemantikáját, például mezőket hozzáadni egy JSON-töredékhez, vagy módosítani egy protobuf-ot. Erről a fontos funkcióról később, amikor az ESB-ről és a middleware-ről lesz szó.
Ez a szolgáltatásháló által kínált szolgáltatások összessége. Felmerül a kérdés: miért nem implementálja őket közvetlenül az alkalmazásba? És egyáltalán miért kell proxyval vacakolni?
Miért jó ötlet a szervizháló
Bár a szervizháló képességei magával ragadóak, a fő értéke nem igazán a szolgáltatásokban rejlik. A végén mi Tud implementálja őket közvetlenül az alkalmazásban (később látni fogjuk, hogy ez volt a szervizháló eredete). Egy mondatban kifejezve egy szolgáltatásháló értéke: olyan funkciókat biztosít, amelyek elengedhetetlenek a modern szerverszoftverek konzisztens, veremszintű, alkalmazáskód-agnosztikus módon történő futtatásához.
Elemezzük ezt a javaslatot.
«Kritikus funkciók a modern szerverszoftver futtatásához". Ha nyilvános internetre csatlakoztatott tranzakciós szerveralkalmazást épít, amely fogadja a külvilágtól érkező kéréseket és rövid időn belül válaszol rájuk – például webalkalmazást, API szervert és más modern alkalmazások túlnyomó többségét – és ha olyan szolgáltatások halmazaként valósítja meg, amelyek egymással szinkronban kölcsönhatásba lépnek, és ha folyamatosan frissíti ezt a szoftvert, új funkciókat ad hozzá, és ha a módosítási folyamat során kénytelen ezt a rendszert működőképes állapotban tartani - ebben az esetben, gratulálunk, Ön modern szerverszoftvert hoz létre. És a fent felsorolt nagyszerű funkciók valóban kritikusak az Ön számára. Az alkalmazásnak megbízhatónak és biztonságosnak kell lennie, és látnia kell, mit csinál. A szervizháló ezeket a kérdéseket segít megoldani.
(Oké, az előző bekezdésbe belekerült az a meggyőződésem, hogy ez a megközelítés a szerverszoftver-készítés modern módja. Mások inkább monolitokat, "reaktív mikroszolgáltatásokat" és más olyan dolgokat fejlesztenek, amelyek nem tartoznak a fenti definíció alá. Ezeknek az embereknek valószínűleg van véleményük ami eltér az enyémtől, és viszont úgy gondolom, hogy "tévednek" - bár mindenesetre a szervizháló nem túl hasznos számukra).
«Egységes az egész köteghez". A szervizháló által nyújtott szolgáltatások nem csak kritikusak. Az alkalmazásban lévő összes szolgáltatásra vonatkoznak, függetlenül attól, hogy milyen nyelven írták őket, milyen keretrendszert használnak, ki írta, hogyan telepítették őket, valamint a fejlesztés és használat minden egyéb finomságától.
«Az alkalmazás kódja független". Végül a szolgáltatásháló nemcsak konzisztens funkcionalitást biztosít a teljes veremben, hanem oly módon, hogy az alkalmazás szerkesztését nem igényli. A szolgáltatásháló funkcionalitásának alapvető alapja, beleértve a konfigurálási, frissítési, üzemeltetési, karbantartási stb. feladatokat, tisztán platformszintű, és független az alkalmazástól. Az alkalmazás a szervizháló befolyásolása nélkül változhat. A szolgáltatásháló viszont bármilyen alkalmazási beavatkozás nélkül megváltozhat.
Röviden, a szolgáltatásháló nemcsak létfontosságú funkcionalitást biztosít, hanem globális, egységes és alkalmazás-független módon teszi ezt. És így, bár a szolgáltatásháló funkcionalitása megvalósítható egy szolgáltatás kódjában (például minden szolgáltatáshoz tartozó könyvtárként), ez a megközelítés nem biztosítja azt az egységességet és függetlenséget, amely egy szolgáltatás esetében olyan értékes. szervizháló.
És csak annyit kell tennie, hogy hozzáad egy csomó proxyt! Ígérem, hamarosan megvizsgáljuk a proxy-k hozzáadásával kapcsolatos működési költségeket. De először álljunk meg, és nézzük meg a függetlenség eme gondolatát a különböző nézőpontokból emberek.
Kinek segít a szervizháló?
Bármilyen kényelmetlen is, ahhoz, hogy egy technológia az ökoszisztéma fontos részévé váljon, az embereknek el kell fogadniuk. Tehát kit érdekel a szervizháló? Kinek előnyös a használata?
Ha modern szerverszoftvert fejleszt, nagyjából egy csoportként képzelheti el csapatát szolgáltatás tulajdonosaiakik együtt dolgoznak ki és valósítanak meg üzleti logikát, ill platform tulajdonosokrészt vesz annak a belső platformnak a fejlesztésében, amelyen ezek a szolgáltatások futnak. Kis szervezetekben ezek lehetnek ugyanazok az emberek, de ahogy a cég növekszik, ezek a szerepkörök egyre hangsúlyosabbá válnak, sőt alszerepekre oszlanak... (Sokat lehet itt mondani a devopok változó természetéről, a mikroszolgáltatások szervezeti hatása stb.). n. De most vegyük ezeket a leírásokat természetesnek).
Ebből a szempontból a szolgáltatásháló egyértelmű haszonélvezői a platform tulajdonosai. Hiszen a platform csapatának végső célja egy olyan belső platform létrehozása, amelyen a szolgáltatástulajdonosok üzleti logikát valósíthatnak meg, és ezt úgy teszik, hogy garantálják számukra a maximális függetlenséget a működés zord részleteitől. A szolgáltatásháló nemcsak a cél eléréséhez nélkülözhetetlen képességeket kínálja, hanem oly módon, hogy nem támaszt függőséget a szolgáltatástulajdonosoktól.
A szolgáltatástulajdonosok is részesülnek, igaz, közvetettebb módon. A szolgáltatás tulajdonosának az a célja, hogy a lehető legproduktívabb legyen az üzleti folyamat logikájának megvalósításában, és minél kevésbé kell a működési problémák miatt aggódnia, annál jobb. Ahelyett, hogy kikényszerítenék, mondjuk, az újrapróbálkozási irányelveket vagy a TLS-t, kizárólag az üzletre összpontosíthatnak, és remélhetik, hogy a platform gondoskodik a többiről. Számukra ez nagy előny.
A platformok és szolgáltatások tulajdonosai közötti ilyen megosztottság szervezeti értékét nem lehet túlbecsülni. Szerintem ő is hozzájárul a fő hozzájárulás a szolgáltatásháló értékéhez.
Ezt a leckét akkor tanultuk meg, amikor egy korai Linkerd-rajongó elmondta, miért választották a szervizhálót: mert ez lehetővé tette számukra, hogy „minimálisan beszéljenek”. Íme néhány részlet: az egyik nagy cég srácai áttelepítették platformjukat a Kubernetesre. Mivel az alkalmazás érzékeny információkkal dolgozott, titkosítani akarták a fürtök összes kommunikációját. A helyzetet azonban nehezítette a több száz szolgáltatás és a több száz fejlesztőcsapat jelenléte. Egyáltalán nem tetszett nekik az a lehetőség, hogy mindenkivel felvegyék a kapcsolatot, és meggyőzzék őket arról, hogy a TLS támogatását is belefoglalják a terveikbe. A Linkerd telepítésével migráltak felelősség a fejlesztőktől (akiknek szemszögéből ez fölösleges gond volt) a platformerekig, akiknek ez volt a legfelső szintű prioritás. Más szóval, a Linkerd nem annyira technikai, mint inkább szervezési problémát oldott meg számukra.
Röviden: a szervizháló inkább nem műszaki megoldás, hanem szociotechnikai Problémák. (Köszönöm e kifejezés bevezetéséért.
A szervizháló megoldja az összes problémámat?
Igen. Úgy értem nem!
A szolgáltatások fent vázolt három osztályát – megbízhatóságot, biztonságot és megfigyelhetőséget – áttekintve világossá válik, hogy a szervizháló nem jelent teljes megoldást e problémák egyikére sem. Bár a Linkerd küldhet ismételt kéréseket (ha tudja, hogy azok idempotensek), nem tud dönteni arról, hogy mit adjon vissza a felhasználónak, ha a szolgáltatás végleg leállt – ezeket a döntéseket az alkalmazásnak kell meghoznia. A Linkerd képes statisztikát vezetni a sikeres kérésekről, de nem tud belenézni a szolgáltatásba, és nem tudja megadni a belső mérőszámait – egy alkalmazásnak rendelkeznie kell ilyen eszköztárral. És bár a Linkerd képes mTLS fogadására, a teljes értékű biztonsági megoldások sokkal többet igényelnek.
Ezeken a területeken a szolgáltatásháló által kínált szolgáltatások egy részhalmaza kapcsolódik platform jellemzői. Ez alatt azokat a függvényeket értem, amelyek:
- Független az üzleti logikától. A Foo és Bar közötti hívási hisztogramok felépítésének módja teljesen független attól, hogy vajon miért Foo felhívja Bart.
- Nehéz helyesen megvalósítani. A Linkerdben az újrapróbálkozások paraméterezve mindenféle divatos dologgal, például újrapróbálkozási költségkerettel vannak megadva. (próbáld újra a költségkereteket), hiszen az ilyen dolgok leegyszerűsítése minden bizonnyal az úgynevezett "kéréslavina" kialakulásához vezet. (próbáld újra a vihart) és egyéb elosztott rendszerekre jellemző problémák.
- A leghatékonyabb, ha következetesen alkalmazzák. A TLS-mechanizmusnak csak akkor van értelme, ha mindenhol alkalmazzák.
Mivel ezek a szolgáltatások a proxy rétegben (és nem az alkalmazási rétegben) vannak megvalósítva, a szolgáltatási háló a emelvény, nem alkalmazások. Így nem mindegy, hogy a szolgáltatások milyen nyelven íródnak, milyen keretrendszert használnak, ki és miért írta. A proxyk ezeken a részleteken túlmenően működnek, és e funkcionalitás alapvető alapja, beleértve a konfigurálási, frissítési, üzemeltetési, karbantartási stb. feladatokat is, kizárólag a platform szintjén rejlik.
Példák a szervizháló képességekre
Összefoglalva, a szervizháló nem teljes körű megoldás a megbízhatóság, a megfigyelhetőség vagy a biztonság szempontjából. Ezeknek a területeknek a hatálya magában foglalja a szolgáltatástulajdonosok, az Ops / SRE csapatok és más vállalati érdekelt felek kötelező részvételét. A szervizháló csak platformszinten biztosít „szeletet” ezekhez a területekhez.
Miért vált most népszerűvé a szervizháló?
Valószínűleg most azon tűnődsz: OK, ha a szervizháló olyan jó, miért nem kezdtük el tíz évvel ezelőtt több millió proxy telepítését a veremben?
Van egy banális válasz erre a kérdésre: tíz évvel ezelőtt mindenki monolitokat épített, és senkinek nem volt szüksége szervizhálóra. Ez igaz, de véleményem szerint ez a válasz kihagyja a lényeget. Még tíz évvel ezelőtt is széles körben vitatták és alkalmazták a mikroszolgáltatások koncepcióját, mint a nagyméretű rendszerek létrehozásának ígéretes módját olyan cégeknél, mint a Twitter, a Facebook, a Google és a Netflix. Az általános felfogás - legalábbis az iparág azon részein, amelyekkel kapcsolatba kerültem - az volt, hogy a mikroszolgáltatások a "helyes út" a nagy rendszerek felépítéséhez, még akkor is, ha az baromi nehéz volt.
Természetesen, bár tíz évvel ezelőtt voltak mikroszolgáltatásokat kihasználó cégek, nem ragasztottak mindenhova proxyt, hogy szolgáltatáshálót alkossanak. Azonban, ha jobban megnézzük, valami hasonlót csináltak: ezek közül a cégek közül sok egy speciális belső könyvtár használatát írta elő a hálózatépítéshez (amit néha zsíros kliens könyvtárnak neveznek, kövér kliens könyvtár).
A Netflixnek a Hysterix, a Google-nek Stubby, a Twitternek a Finagle könyvtára volt. A Finagle például kötelező volt a Twitter minden új szolgáltatásához. Kezelte a kapcsolatok kliens és kiszolgáló oldalát is, lehetővé tette az ismételt kéréseket, a támogatott kérések útválasztását, a terheléselosztást és a mérést. Következetes megbízhatósági és megfigyelhetőségi réteget biztosított a teljes Twitter-veremben, függetlenül attól, hogy mit csinál a szolgáltatás. Természetesen csak a JVM nyelveken működött, és olyan programozási modellen alapult, amelyet az egész alkalmazáshoz kellett használni. Funkcionalitása azonban majdnem ugyanaz volt, mint a szervizhálóé. (Valójában a Linkerd első verziója csak a Finagle volt proxy formátumba csomagolva.)
Így tíz évvel ezelőtt nem csak mikroszolgáltatások léteztek, hanem speciális proto-service-mesh könyvtárak is, amelyek ugyanazokat a problémákat oldották meg, mint ma a service mesh. Maga a szervizháló azonban akkor még nem létezett. Még egy műszaknak kellett lennie, mielőtt megjelent.
És itt rejlik a mélyebb válasz, ami egy másik változásban rejtőzik, amely az elmúlt 10 évben történt: a mikroszolgáltatások kiépítésének költségei meredeken csökkentek. A fent említett cégek, amelyek egy évtizeddel ezelőtt mikroszolgáltatásokat használtak – Twitter, Netflix, Facebook, Google – hatalmas léptékű és hatalmas erőforrásokkal rendelkező cégek voltak. Nemcsak szükségük volt, hanem lehetőségük is volt arra, hogy mikroszolgáltatásokon alapuló nagy alkalmazásokat építsenek, telepítsenek és üzemeltetjenek. Elképesztő az az energia és erőfeszítés, amelyet a Twitter mérnökei fektettek abba, hogy a monolitikus megközelítésről a mikroszolgáltatási megközelítésre váltsanak. (Őszintén szólva, ahogy az is, hogy működött.) Ez a fajta infrastrukturális manőverezés akkor a kisebb cégek számára lehetetlen volt.
Térjünk át a jelenbe. Ma már vannak olyan startupok, ahol a mikroszolgáltatások és a fejlesztők aránya 5:1 (vagy akár még ), ráadásul sikeresen megbirkóznak velük! Ha egy 5 fős startup 50 mikroszolgáltatást képes megerőltetés nélkül működtetni, akkor valami egyértelműen csökkentette a megvalósítás költségeit.
1500 mikroszolgáltatás Monzóban; minden vonal egy előírt hálózati szabály, amely lehetővé teszi a forgalmat
A mikroszolgáltatások üzemeltetési költségeinek drámai csökkenése egyetlen folyamat eredménye: a konténerek növekvő népszerűsége и hangszerelők. Pontosan ez a mély válasz arra a kérdésre, hogy mi járult hozzá a szolgáltatásháló megjelenéséhez. Ugyanaz a technológia tette vonzóvá a szolgáltatáshálót és a mikroszolgáltatásokat is: a Kubernetes és a Docker.
Miért? Nos, a Docker megold egy nagy problémát – a csomagolás problémáját. Azáltal, hogy egy alkalmazást és (nem hálózati) futásidejű függőségeit egy tárolóba csomagolja, a Docker az alkalmazást helyettesíthető egységgé alakítja, amely bárhol tárolható és futtatható. Ugyanakkor nagyban leegyszerűsíti a működést. többnyelvű verem: Mivel a konténer egy atomi végrehajtási egység, telepítési és működési célokra nem számít, hogy mi van benne, legyen az JVM, Node, Go, Python vagy Ruby alkalmazás. Csak futtatod és ennyi.
A Kubernetes mindent a következő szintre emel. Most, hogy van egy csomó "végrehajtható dolog" és sok gépen lehet őket futtatni, szükség van egy olyan eszközre, amely össze tudja egyeztetni őket egymással. Tágabb értelemben sok konténert és sok gépet adsz a Kubernetesnek, és az ezeket összeilleszti (persze ez egy dinamikus és folyamatosan változó folyamat: új konténerek mozognak a rendszerben, gépek indulnak és leállnak stb. A Kubernetes mindezt figyelembe veszi ).
A Kubernetes beállítása után az egy szolgáltatás üzembe helyezéséhez és működtetéséhez szükséges idő nem sokban tér el tíz szolgáltatás telepítésének és működtetésének költségeitől (sőt, ez majdnem ugyanannyi 100 szolgáltatás esetében). Ha ehhez hozzáadjuk a tárolókat a többnyelvű megvalósítást ösztönző csomagolómechanizmusként, rengeteg új alkalmazást kapunk, amelyeket több nyelven írt mikroszolgáltatásként implementálunk, éppen olyan környezetben, amelyre a szolgáltatásháló annyira alkalmas.
Elérkeztünk tehát a válaszhoz arra a kérdésre, hogy miért vált most népszerűvé a szervizháló ötlete: a Kubernetes szolgáltatási egységessége közvetlenül alkalmazható a szervizháló előtt álló üzemeltetési feladatokra. A proxykat konténerekbe csomagolod, a Kubernetes feladatot adod, hogy rögzítse őket, ahol csak lehetséges, és íme! Ennek eredményeként szolgáltatáshálót kap, míg a Kubernetes vezérli a telepítés összes mechanikáját. (Legalábbis madártávlatból. Ennek a folyamatnak persze sok árnyalata van.)
Összefoglalva: a szolgáltatásháló most és nem tíz évvel ezelőtt vált népszerűvé az, hogy a Kubernetes és a Docker nemcsak jelentősen növekedett szükség benne az alkalmazások megvalósításának egyszerűsítése többnyelvű mikroszolgáltatások halmazaként, de jelentősen csökkentve is költségeket működéséhez az oldalkocsis proxy parkok kiépítésére és karbantartására szolgáló mechanizmusok biztosításával.
Miért beszélnek annyit a szervizhálóról?
Vigyázat: Ebben a részben mindenféle feltételezéshez, sejtéshez, kitalációhoz és bennfentes információhoz folyamodom.
A "service mesh" kifejezésre keresve egy csomó újrahasznosított, alacsony kalóriatartalmú tartalom, furcsa projektek és egy visszhangkamrához méltó torzítás kaleidoszkópja bukkan fel. Bármilyen divatos új technológia rendelkezik ezzel, de a szervizháló esetében különösen akut a probléma. Miért?
Nos, ez részben az én hibám. Minden tőlem telhetőt megtettem a Linkerd és a szolgáltatási háló népszerűsítése érdekében, számtalan blogbejegyzésen és ehhez hasonló cikken keresztül. De nem vagyok olyan erős. Ahhoz, hogy valóban megválaszoljuk ezt a kérdést, beszélnünk kell egy kicsit az általános helyzetről. És lehetetlen beszélni róla anélkül, hogy egy projektet említenénk: egy nyílt forráskódú szolgáltatásháló, amelyet a Google, az IBM és a Lyft közösen fejlesztettek ki.
(A három vállalat szerepe nagyon eltérő: úgy tűnik, hogy a Lyft szerepe a névre korlátozódik; ők írják az Envoyt, de nem használják vagy vesznek részt az Istio fejlesztésében. Az IBM részt vesz az Istio fejlesztésében, és használja is. A Google erősen részt vesz az Istio fejlesztésében, de amennyire meg tudom mondani, valójában nem használja.)
Az Istio projekt két dologról nevezetes. Először is, ez az a hatalmas marketing erőfeszítés, amelyet különösen a Google fektet a promócióba. Becslésem szerint a legtöbb ember, aki jelenleg ismeri a szolgáltatásháló koncepcióját, először az Istiónak köszönhetően értesült róla. A második jellemző az, hogy Istio milyen rosszul fogadta. Ebben a kérdésben nyilván érdekelt fél vagyok, de igyekszem a lehető legobjektívebb maradni, mégsem tehetek róla. , nem túl konkrét (bár nem egyedi: systemd jut eszembe, ...) nyílt forráskódú projekthez.
(A gyakorlatban úgy tűnik, hogy az Istiónak nem csak a komplexitással és az UX-el van problémája, hanem a teljesítménnyel is. Pl. Egy harmadik fél által végzett vizsgálat során a szakértők olyan helyzeteket találtak, amelyekben az Istio faroklatenciája 100-szor magasabb volt, mint a Linkerdé, valamint olyan helyzeteket, amikor a Linkerd továbbra is sikeresen működött, és az Istio teljesen leállt.)
Eltekintve az elméleteimtől, hogy miért történt ez, úgy vélem, hogy a szolgáltatásháló körüli nem nagy hírverés a Google közreműködésének köszönhető. Nevezetesen a következő három tényező kombinációja:
- az Istio megszállott reklámozása a Google által;
- megfelelő rosszalló, kritikus hozzáállás a projekthez;
- a Kubernetes közelmúltban egekbe szökő népszerűsége, melynek emléke még friss.
Ezek a tényezők együtt egyfajta mámorító, anoxikus környezetté egyesülnek, amelyben a racionális ítélkezési képesség meggyengül, és csak egy csodálatos változatosság marad meg. .
Linkerd szemszögéből ez… vegyes áldásként jellemezném. Úgy értem, nagyszerű, hogy a szolgáltatásháló bekerült a mainstreambe – ami nem volt így 2016-ban, amikor a Linkerd először megjelent, és nagyon nehéz volt felhívni az emberek figyelmét a projektre. Most már nincs ilyen probléma! De a rossz hír az, hogy a szervizháló helyzete ma annyira zavaros, hogy szinte lehetetlen kitalálni, hogy mely projektek tartoznak igazán a service mesh kategóriába (nem beszélve arról, hogy egy adott használati esetre melyik a legjobb). Ez minden bizonnyal mindenkit akadályoz (és bizonyos esetekben biztosan jobb az Istio vagy egy másik projekt, mint a Linkerd, mivel ez utóbbi nem egy univerzális megoldás).
Linkerd oldaláról a stratégiánk az volt, hogy figyelmen kívül hagyjuk a zajt, továbbra is a közösség valós problémáinak megoldására összpontosítunk, és lényegében megvárjuk, amíg a hype elcsitul. Végül a felhajtás alábbhagy, és nyugodtan folytathatjuk a munkát.
Addig mindannyiunknak türelmesnek kell lennünk.
Hasznos lesz nekem, szerény szoftvermérnöknek a szervizháló?
Az alábbi kérdőív segít megválaszolni ezt a kérdést:
Kizárólag az üzleti logika megvalósításával foglalkozik? Ebben az esetben a szervizháló nem lesz hasznos az Ön számára. Ez természetesen érdeklődhet iránta, de ideális esetben a szervizháló nem érinthet közvetlenül semmit a környezetében. Dolgozz tovább azon, amiért fizetnek.
Fenntart egy platformot egy Kubernetes-t használó vállalatnál? Igen, ebben az esetben szükség van egy szervizhálóra (persze, ha nem csak monolit vagy kötegelt feldolgozás futtatására használod a K8-at - de akkor azt szeretném megkérdezni, hogy miért van szükséged K8-ra). Valószínűleg olyan helyzetbe kerül, amikor sok mikroszolgáltatást írtak különböző emberek. Mindannyian kölcsönhatásba lépnek egymással, és futásidejű függőségek szövevényébe kapcsolódnak, és meg kell találni a módját ennek az egésznek a kezelésére. A Kubernetes használata lehetővé teszi, hogy „maga számára” válasszon egy szolgáltatáshálót. Ehhez ismerkedjen meg képességeikkel és szolgáltatásaikkal, és válaszoljon arra a kérdésre, hogy a rendelkezésre álló projektek közül bármelyik megfelel-e Önnek (javaslom, hogy a kutatást a Linkerddel kezdje).
Olyan cégnek működtet platformot, amely NEM Kuberneteset, de mikroszolgáltatásokat használ? Ebben az esetben a szervizháló hasznos lesz az Ön számára, de használata nem triviális. Természetesen megteheti imitál szervizhálót egy csomó proxy tárolásával, de a Kubernetes fontos előnye éppen a telepítési modell: ezeknek a proxyknek a manuális karbantartása sokkal több időt, erőfeszítést és költséget igényel.
Ön felel a platformért egy monolitokkal foglalkozó cégnél? Ebben az esetben valószínűleg nincs szüksége szervizhálóra. Ha olyan monolitokkal (vagy akár monolithalmazokkal) dolgozik, amelyek jól meghatározott és ritkán változó interakciós mintákkal rendelkeznek, akkor a szolgáltatásháló keveset kínál Önnek. Szóval figyelmen kívül hagyhatod, és remélheted, hogy eltűnik, mint egy rossz álom...
Következtetés
Valószínűleg a szolgáltatáshálót még mindig nem szabad „a világ leginkább felkapott technológiájának” nevezni - ez a kétes megtiszteltetés valószínűleg a bitcoint vagy az AI-t illeti. Talán benne van az első ötben. De ha áttöri a zaj és a zaj rétegeit, világossá válik, hogy a szolgáltatásháló valódi előnyökkel jár azoknak, akik alkalmazásokat készítenek a Kubernetesben.
Szeretném, ha kipróbálnád a Linkerdet – telepítsd Kubernetes-fürtbe (vagy akár laptopon a Minikube-ba) és magad is láthatod, miről beszélek.
FAQ
- Ha figyelmen kívül hagyom a szervizhálót, eltűnik?
- Csalódást kell okoznom: a szervizháló már régóta velünk van.
— De NEM AKAROK szervizhálót használni!
- Hát, nem szükséges! Csak olvassa el a fenti kérdőívemet, hogy megtudja, meg kell-e legalább ismerkednie az alapjaival.
— Nem a jó öreg ESB/middleware új mártással?
- A Service mesh a működési logikával foglalkozik, nem a szemantikával. vállalati szolgáltató busz (). Ennek az elválasztásnak a megtartása segít a szolgáltatáshálónak elkerülni ugyanezt a sorsot.
- Miben különbözik egy szolgáltatásháló az API-átjáróktól?
Millió cikk van ebben a témában. Csak google.
Az Envoy egy szolgálati háló?
- Nem, az Envoy nem egy szervizháló, hanem egy proxyszerver. Használható szolgáltatási háló (és még sok más - ez egy általános célú proxy) rendszerezésére. De önmagában ez nem egy szervizháló.
- Network Service Mesh – ez egy szervizháló?
- Nem. A név ellenére ez nem egy szervizháló (hogy tetszenek a marketing csodái?).
- A szervizháló segíteni fog az üzenetsoron alapuló reaktív aszinkron rendszeremen?
- Nem, a szervizháló nem fog segíteni.
- Melyik szervizhálót használjam?
- , nem gondol.
- Szar a cikk! / A szerző – a szappanra!
— Kérlek, oszd meg minden ismerősöddel a linket, hogy meggyőződhessenek erről!
Köszönetnyilvánítás
Ahogy a címből sejthető, ezt a cikket Jay Kreps fantasztikus értekezése ihlette.". Tíz évvel ezelőtt találkoztam Jay-vel, miközben interjút készítettem a Linked In-en, és azóta is inspirációt jelent számomra.
Bár szeretem "Linkerd fejlesztőnek" nevezni magam, a valóság az, hogy inkább a README.md fájl karbantartója vagyok egy projektben. Ma a Linkerden dolgozom , , emberek, és ez a projekt nem jöhetett volna létre a közreműködők és felhasználók csodálatos közössége nélkül.
És végül külön köszönet a Linkerd alkotójának, (primus inter pares), aki velem együtt sok évvel ezelőtt fejest ugrott ebbe a sok felhajtásba a szervizhálóval.
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «";
- «".
Forrás: will.com