Megjegyzés fordítás.: A service mesh is a phenomenon that still lacks a stable translation into Hungarian (over 2 years ago, we suggested the term 'szolgáltató hálózat', and later some colleagues began actively promoting the combination 'szolgáltató szita'). Constant discussions about this technology have led to a situation where the marketing and technical components are tightly intertwined. This remarkable material from one of the authors of the original term aims to bring clarity for engineers and others.
Comic by
Bevezetés
If you are a backend engineer working somewhere in the area of backend systems, the term 'service mesh' has probably become firmly entrenched in your consciousness over the past couple of years. Due to a strange twist of fate, this phrase is capturing the industry more and more, while the hype and related promotional offers escalate like a snowball rolling down a slope, showing no signs of slowing down.
Service mesh originated in the murky, biased waters of the cloud native ecosystem. Unfortunately, this means that a significant portion of the related discussions varies from 'low-calorie chatter' to — to use a technical term — outright nonsense. But if we sift through all the noise, we can find that the service mesh has a very real, well-defined, and important function.
In this publication, I will attempt to do exactly that: present an honest, in-depth, engineer-focused guide to service mesh. I intend to answer not only the question: ‘What is it?’, — but also ‘Why?’, valamint ‘Why now?’. Finally, I will try to outline why (in my opinion) this particular technology has generated such a crazy buzz, which is an interesting story in itself.
Who am I?
Hello everyone! My name is . I am one of the creators of — the very first service mesh project and the project that is responsible for the term's emergence szolgáltatási hálózat as such (sorry, guys!). (Translation example.: By the way, at the dawn of this term's appearance, over 2.5 years ago, we had already translated an early material by the same author titled '».) I also head up — a startup focused on creating cool service mesh stuff like Linkerd and .
Valószínűleg sejtik, hogy erről a kérdésről meglehetősen elfogult és szubjektív véleményem van. Mindazonáltal megpróbálom minimalizálni az elfogultságot (kivéve egy részt: »Miért van annyi beszéd a service mesh-ről?«, — amelyben azért megosztom az elfogult gondolataimat). Továbbá mindent megteszek annak érdekében, hogy ez az útmutató a lehető legobjektívebb legyen. A konkrét példákban főként a Linkerd tapasztalataira támaszkodom, figyelembe véve az általam ismert különbségeket (ha vannak) más service mesh típusok megvalósításában.
Rendben, itt az ideje a lényeget átvenni.
Mi az a service mesh?
A hatalmas felhajtás ellenére a service mesh strukturálisan meglehetősen egyszerű. Ez nem más, mint egy halom felhasználói térbeli proxy, amely "közel" található a szolgáltatásokhoz (később beszélünk egy kicsit arról, hogy mi is az a "közel"), plusz egy irányító folyamatok halmaza. A proxy együtt a data plane, míg az irányító folyamatok a control plane. A data plane elfogja a szolgáltatások közötti hívásokat és "mindenféle dolgot" csinál velük; a control plane pedig koordinálja a proxy viselkedését, és hozzáférést biztosít az Ön, azaz az üzemeltető számára az API-hoz, lehetővé téve a hálózat manipulálását és annak egy egészként történő mérését.
Mik ezek a proxyk? Ezek TCP proxyk, amelyek "Layer 7-aware" kategóriába tartoznak (azaz "figyelembe veszik" az OSI modell 7. szintjét) , mint például a HAProxy és az NGINX. Szabadon választhat proxykat; a Linkerd Rustban írt proxyját használja, amelyet egyszerűen -nak hívnak. Kifejezetten a service mesh-hez állítottuk össze. Más mesh-ek más proxykat preferálnak (az Envoy gyakran választott). Mindazonáltal a proxy választása csak a megvalósítás kérdése.
Mire használják ezeket a proxy szervereket? Nyilvánvalóan a szolgáltatások hívásainak proxyzására szolgálnak, és fordítva (szigorúan véve, proxy és fordított proxy funkciót látnak el, kezelve a bejövő és a kimenő hívásokat). És számos funkciót valósítanak meg, amelyek a hívásokra összpontosítanak a szolgáltatások között. Ez a hangsúly a szolgáltatások közötti forgalomra megkülönbözteti a service mesh proxykat az API gateway-ektől vagy az ingress proxyktól (az utóbbiak a klaszterbe érkező, külső világból származó hívásokra összpontosítanak). (Megjegyzés fordítás.: az Ingress vezérlők összehasonlítása a Kubernetes számára, amelyek közül sok már említett Envoy-t használja, ld. .)
Tehát, a data plane ügyével már tisztában vagyunk. A control plane egyszerűbb: ez egy összesítő komponensek halmaza, amely biztosítja az összes mechanikát, amely szükséges a data plane számára, hogy koordináltan működjön, beleértve a szolgáltatások felfedezését, TLS tanúsítványok kibocsátását, metrikák aggregálását stb. A data plane tájékoztatja a control plane-t a viselkedéséről; cserébe a control plane egy API-t biztosít, amely lehetővé teszi a data plane viselkedésének módosítását és nyomon követését, mint egy egységes egészet.
Az alábbiakban a control plane és a data plane vázlata látható a Linkerdben. Ahogy látható, a control plane több különböző komponenst tartalmaz, beleértve egy Prometheus példányt, amely a proxy szerverekről gyűjti a metrikákat, valamint más komponenseket, mint rendelkezés (szolgáltatások felfedezése), identity (tanúsítványközpont, CA) és public-api (végpontok web és CLI számára). Ezzel szemben a data plane egy egyszerű linkerd-proxy az alkalmazás példánya mellett található. Ez egy logikai vázlat; valós körülmények között a telepítés során három replikájuk lehet a control plane minden eleméből és több száz vagy ezer proxy a data plane-ben.
(A kék téglalapok a Kubernetes podok határait jelképezik. Látható, hogy a linkerd-proxy konténerek egy pod-ban találhatók az alkalmazás konténereivel. Ez a felépítés a sidecar-konténer.)
A service mesh architektúra számos fontos következménnyel jár. Először is, mivel a proxy feladata a hívások megfogása a szolgáltatások között, a service mesh csak akkor van értelme, ha az alkalmazás egy szolgáltatás-gyűjteménnyel készült. A mesh lehetővé teszi monolitikus alkalmazásokkal is használható, de ez nyilvánvalóan túlzás egyetlen proxy miatt, és a funkciói valószínűleg nem lesznek szükségesek.
Egy másik fontos következmény az, hogy a service mesh óriási számú proxy-t igényel. Valójában a Linkerd minden szolgáltatás minden példányához linkerd-proxy-t kapcsol, (más megvalósítások proxy-kat adnak hozzá minden csomóponthoz/gépcsoporthoz/virtuális géphez). Minden esetben ez nem kevés. Ez a aktív proxy-használat önmagában számos további bonyodalmat hordoz:
- A data plane proxyinak gyorsaknakkell lenniük, mivel minden egyes hívásra egy pár proxy hívás vonatkozik: egy az ügyfél oldalán, egy pedig a szerver oldalán.
- Ezenkívül a proxy-knak kicsiknak és könnyűsúlyúaknakkell lenniük. Mindegyik memória- és CPU-erőforrást fogyaszt, és ez a fogyasztás vonalban nő az alkalmazással.
- Szüksége lesz egy mechanizmusra a nagyszámú proxik kiépítéséhez és frissítéséhez. Kézi megoldás nem opció.
Általánosságban a service mesh így néz ki (legalábbis madártávlatból): egy csomó userspace proxyt telepít, amelyek "valamit csinálnak" a belső, mikroszolgáltatások közötti forgalommal, és használ egy control plane-t azok monitorozására és kezelésére.
Elérkezett a kérdés ideje: "Miért?"
Mire jó a service mesh?
Azok számára, akik először találkoznak a service mesh ötletével, érthető, ha egy kis izgalmat éreznek. A service mesh felépítése azt jelenti, hogy nemcsak a késleltetést növeli az alkalmazásban, hanem forrást is fogyaszt, és több új mechanizmust ad hozzá az infrastruktúrához. Első lépésként telepíti a service mesh-t, majd hirtelen rájön, hogy száz (ha nem ezer) proxyt kell karbantartania. Megkérdőjelezhető, hogy ki vállalná ezt önként.
A kérdésre a válasz két részből áll. Először is, a proxy-k kiépítésével kapcsolatos működési költségek jelentősen csökkenthetők néhány ökoszisztémában zajló változás révén (erről később bővebben).
Másodszor, egy ilyen mechanizmus valójában remek módja az extra logika bevezetésének a rendszerbe. Nemcsak azért, mert a service mesh segítségével számos új funkciót adhat hozzá, hanem azért is, mert ezt megteheti anélkül, hogy beavatkozna az ökoszisztémába. A service mesh teljes modellje alapvetően ezen posztulátum köré épül: a multiszolgáltatásos rendszerben, függetlenül attól, hogy mit csinálnak az egyes szolgáltatások, a forgalom közöttük tökéletes pont a funkcionalitás hozzáadására.
Például a Linkerd (mint a legtöbb mesh) funkcionalitása 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ályra bontható:
- Funkciók, amelyek a megbízhatóságmegismételt kérésekkel, időtúllépésekkel, kanáriként való megközelítéssel (forgalom megosztása/újrahajlítás) stb. kapcsolatosak.
- Funkciók, amelyek a monitorozássalkapcsolatos. A sikerességi mutatók, késleltetések és a kérések volumenének aggreálása minden szolgáltatás vagy egyes irányok esetén; a szolgáltatások topológiai térképeinek felépítése stb.
- Funkciók, amelyek a biztonság. Mutual TLS, hozzáférés-ellenőrzés stb.
* Linkerd szempontjából a gRPC szinte semmiben sem különbözik a HTTP/2-től: csupán a payload-ban a protobuf formát használja. Fejlesztői szempontból ez a két dolog persze megkülönböztethető.
Ezek közül sok mechanizmus kérés szintjén működik (innen az „L7-proxy” kifejezés). Például, ha a Foo szolgáltatás HTTP-hívást küld a Bar szolgáltatásnak, a linkerd-proxy a Foo oldalán intelligens terheléselosztást végezhet, és a hívásokat a Foo-tól a Bar példányaira irányíthatja a megfigyelt késleltetés függvényében; szükség esetén megismételheti a hívást (ha az idempotens); rögzítheti a választási kódot és a várakozási időt, stb. Hasonló módon a linkerd-proxy a Bar oldalán elutasíthatja a hívást, ha az nem engedélyezett vagy túllépi a hívások limitjét; rögzítheti a késleltetést az ő oldaláról, stb.
A proxik „valamit csinálhatnak” a kapcsolatok szintjén is. Például a linkerd-proxy a Foo oldalán TLS-kapcsolatot indíthat, míg a linkerd-proxy a Bar oldalán megszakíthatja azt, és mindkét fél ellenőrizheti egymás TLS-tanúsítványait. Ez nemcsak a szolgáltatások közötti titkosítást biztosítja, hanem egy kriptográfiailag biztonságos módot a szolgáltatások azonosítására is: a Foo és Bar „bizonyíthatják”, hogy azok, akiknek mondják magukat.
* „Egymás” esetén a kliens tanúsítványát is ellenőrzik (mutual TLS). A „klasszikus” TLS esetében, például egy böngésző és egy szerver között, általában csak az egyik fél (szerver) tanúsítványát ellenőrzik.
Függetlenül attól, hogy kérés vagy kapcsolat szintjén működnek, fontos hangsúlyozni, hogy a szolgáltatás mesh minden funkciója üzemeltetési jellegű. A Linkerd nem képes a payload szeminatikáját átalakítani – például nem tud mezőket hozzáadni egy JSON-részlethez vagy változtatásokat tenni a protobuf-ban. Ezen a fontos aspektuson később fogunk beszélni, amikor az ESB-ről és a middleware-ről lesz szó. Ez az a funkcióhalmaz, amelyet a szolgáltatásmesh kínál. Felmerül a kérdés: miért ne valósítanák meg ezeket közvetlenül az alkalmazásban? És miért kellene egy proxyval foglalkozni?
Miért jó ötlet a service mesh
Bár a service mesh lehetőségei megragadják a képzeletet, a valódi értéke a funkciókban rejlik. Végül is mi
Bár a service mesh lehetőségei lenyűgözőek, valódi értéke nem pusztán a funkcióiban rejlik. Végső soron mi lejjebb a közvetlenül az alkalmazásban megvalósítani (később látni fogjuk, hogy ez a service mesh eredete). Ha ezt a gondolatot egy mondatban szeretnénk kifejezni, a service mesh értéke a következő: olyan funkciókat biztosít, amelyek kritikusak a modern szerver szoftver működéséhez, egységes módon az egész stack számára és függetlenül az alkalmazás kódjától.
Vizsgáljuk meg ezt a mondatot.
«Funkciók, amelyek kritikusak a modern szerver szoftver működéséhez». Ha tranzakciós szerver alkalmazást építesz, amely a nyilvános internethez kapcsolódik, fogadja a külső világ lekérdezéseit, és rövid időn belül válaszol rájuk — például webalkalmazás, API-szerver, és a legtöbb más modern alkalmazás — és ha ezt egy szolgáltatásokból álló készletként valósítod meg, amelyek szinkron módon interakcióba lépnek egymással, és ha folyamatosan modernizálod ezt a szoftvert, új funkciók hozzáadásával, és ha képesnek kell lenned fenntartani ezt a rendszert működőképes állapotban a módosítások során — akkor gratulálok, modern szerver szoftver fejlesztésével foglalkozol. És mindezek a csodálatos funkciók, amelyeket fentebb felsoroltunk, valójában kritikusak számodra. Az alkalmazásnak megbízhatónak, biztonságosnak kell lennie, és képesnek kell lenned megfigyelni, hogy mit csinál. Ezekre a kérdésekre ad választ a service mesh.
(Rendben, az előző bekezdésbe mégis befért a meggyőződésem, hogy ez a megközelítés a modern szerver szoftver fejlesztésének módja. Mások inkább monolitokat, „reaktív mikroszolgáltatásokat” és más dolgokat fejlesztenek, amelyek nem egyeznek meg a fent említett meghatározással. E csoport tagjainak valószínűleg megvan a saját véleményük, ami eltér az enyémtől. Én pedig úgy vélem, hogy „nincsenek igazuk” — bár a service mesh számukra nem túl hasznos).
«Egységes módon az egész stack számára». A service mesh által biztosított funkciók nem csupán kritikusan fontosak. Ezek minden szolgáltatásra vonatkoznak az alkalmazásban, függetlenül attól, hogy milyen nyelven írták őket, milyen keretrendszert használnak, ki írta őket, hogyan lettek telepítve, és minden más szemponttól, amely a fejlesztésükhöz és működtetésükhöz kapcsolódik.
«Függetlenül az alkalmazás kódjátólVégül is, a service mesh nemcsak egységes funkciókat biztosít az egész stack számára, hanem mindezt úgy teszi, hogy nem igényel alkalmazásmódosítást. A service mesh funkcionalitásának alapja, beleértve a konfigurálási, frissítési, üzemeltetési, karbantartási stb. feladatokat, kizárólag a platform szintjén van, és független az alkalmazástól. Az alkalmazás változhat, anélkül hogy a service mesh-t érintené. Viszont a service mesh is változhat, anélkül hogy az alkalmazás bármilyen módon részt venne.
Röviden, a service mesh nem csupán létfontosságú funkciókat biztosít, hanem ezt globális, egységes és alkalmazástól független módon teszi. Ezért bár a service mesh funkcionalitása megvalósítható a szolgáltatás kódjában (például egy, a szolgáltatás minden példányába beépített könyvtár formájában), ez a megközelítés nem fogja garantálni az egységességet és függetlenséget, amelyek olyan értékesek a service mesh szempontjából.
És mindössze annyira van szükség, hogy sok proxy-t adjunk hozzá! Ígérem, nagyon hamar megvizsgáljuk a proxy-k hozzáadásával kapcsolatos üzemeltetési költségeket. De először álljunk meg, és nézzük meg ezt az ötletet a függetlenség szempontjából különböző emberek.
Kinek segít a service mesh?
Bár kellemetlen, de ahhoz, hogy egy technológia fontos részévé váljon az ökoszisztémának, az embereknek el kell fogadniuk. Ki is érdekelt a service mesh-ben? Ki nyer a használatával?
Ha modern szerver szoftvert fejlesztesz, akkor kb. úgy képzelheted el a csapatodat, mint egy csoportot szolgáltatás-tulajdonosokat, akik együtt dolgozzák ki és hajtják végre az üzleti logikát, és platform-tulajdonosokat, akik a szolgáltatások működését biztosító belső platform fejlesztésével foglalkoznak. Kisebb szervezetekben ezek általában ugyanazok az emberek, de a vállalat növekedésével ezek a szerepek általában egyre kifejezettebbé válnak, sőt, alárendelt szerepekre is osztják… (Erről sokat lehetne beszélni, a devops természetének változásáról, a mikroszolgáltatások szervezeti hatásáról, stb. De egyelőre fogadjuk el ezeket a leírásokat tényként).
Ebből a szempontból a szolgáltatás-hálónak a platformtulajdonosok a nyilvánvaló nyertesei. Végső soron a platformcsapat célja, hogy létrehozzon egy belső platformot, ahol a szolgáltatás-tulajdonosok megvalósíthatják az üzleti logikájukat, és ezt úgy tegyék, hogy maximálisan függetlenek maradjanak a működtetés nehézségeitől. A szolgáltatás-háló nemcsak olyan lehetőségeket kínál, amelyek kritikus fontosságúak e cél eléréséhez; mindezt olyan módon teszi, amely nem ró terhet a szolgáltatás-tulajdonosokra.
A szolgáltatás-tulajdonosok is nyernek, bár közvetettebb módon. A szolgáltatás-tulajdonos célja, hogy a lehető leghatékonyabb legyen az üzleti folyamat logikájának megvalósításában, és minél kevesebb időt kell eltöltenie az üzemeltetési kérdések megoldásával, annál jobb. Ahelyett, hogy például a visszaküldési politikák vagy a TLS megvalósításával foglalkoznának, kizárólag az üzleti feladatokra összpontosíthatnak, bízva abban, hogy a platform minden másra gondot visel. Számukra ez nagy előny.
A platform- és szolgáltatás-tulajdonosok közötti ilyen megkülönböztetés szervezeti értékét nehéz túlbecsülni. Azt hiszem, hogy ez hozzájárul fő a szolgáltatás-háló értékéhez.
Ezt az leckét tanultuk meg, amikor az egyik első Linkerd kedvelő elmondta nekünk, miért választották a szolgáltatás-hálót: mert lehetővé tette számukra, hogy „minimalizálják a beszédet”. Íme néhány részlet: egy nagy vállalat srácai áttelepítették platformjukat Kubernetesre. Mivel az alkalmazás érzékeny információkat kezelt, minden kommunikáció titkosítását akarták. Azonban a helyzetet nehezítette a több száz szolgáltatás és fejlesztőcsapat. Az a kilátás, hogy kapcsolatba lépnek mindenkivel, és meggyőzik őket, hogy támogassák a TLS-t a terveikben, egyáltalán nem tetszett nekik. A Linkerd telepítésével áthelyezték a felelősséget a fejlesztőktől (akik számára ez felesleges terhet jelentett) a platformtulajdonosokra, akik számára ez a legfelsőbb prioritás volt. Más szavakkal, a Linkerd nemcsak technikai, hanem inkább szervezeti problémát oldott meg számukra.
Röviden, a szolgáltatás-háló inkább technikai, hanem szocio-technikai problémát jelent. (Köszönöm az előadásért.)
Megoldja-e a szolgáltatás-háló minden problémámat?
Igen. Vagyis, nem!
Ha megnézzük a fent említett három funkcióosztályt: megbízhatóság, biztonság és megfigyelhetőség — világossá válik, hogy a service mesh nem jelent teljes megoldást egyik problémára sem. Bár a Linkerd képes újrapróbálkozásokra (ha tudja, hogy azok idempotensak), nem képes eldönteni, mit adjon vissza a felhasználónak, ha a szolgáltatás véglegesen hibás — ilyen döntéseket az alkalmazásnak kell meghoznia. A Linkerd nyomon tudja követni a sikeres kérések statisztikáit, azonban nem tud betekinteni a szolgáltatásba, és biztosítani annak belső metrikáit — ilyen eszközökkel az alkalmazásnak kell rendelkeznie. Bár a Linkerd képes mTLS-t szervezni, a biztonság teljes körű megoldásai sokkal többet igényelnek.
Azok a funkciók, amelyek a service mesh által a következő területeken kínálva vannak, a platform jellemzői. Ezen alatt olyan funkciókat értek, amelyek:
- Függetlenek az üzleti logikától. Az a mód, ahogyan a Foo és Bar közötti hívások histogramját felépítik, teljes mértékben független attól, miért hogy a Foo hívja a Bart.
- Nehezen valósítható meg helyesen. A Linkerd-ben az újrapróbálkozások paraméterezve vannak különféle bonyolult dolgokkal, mint a retry budgets (újrapróbálkozási költségvetések),mivel a primitív, frontalapú megközelítés az ilyen dolgok megvalósításában biztosan "kéréslavinát" (retry storm) és más, elosztott rendszerekre jellemző problémákat okozna.
- Leghatékonyabb, ha egységesen alkalmazzák. A TLS mechanizmusnak csak akkor van értelme, ha mindenhol alkalmazzák.
Mivel ezek a funkciók a proxy szintjén valósulnak meg (nem az alkalmazás szintjén), a service mesh az platformok.proxy szintjén, nem pedig az alkalmazás szintjén nyújtja őket. Így nem számít, hogy milyen nyelven íródtak a szolgáltatások, milyen keretrendszert használnak, ki írta őket és miért. A proxyk ezeknek a részleteknek a határain kívül működnek, és e funkcionalitás alapvető alapja, beleértve a beállítási, frissítési, üzemeltetési, karbantartási stb. feladatokat, kizárólag a platform szintjén áll.
A service mesh képességeinek példái
Összességében szeretném azt mondani, hogy a service mesh nem egy teljes megoldás a megbízhatóság, észlelhetőség vagy biztonság biztosítására. Ezen területek kiterjedése megköveteli a szolgáltatás tulajdonosok, Ops/SRE csapatok és a vállalat más alanyainak kötelező részvételét. A service mesh csupán egy „átvágást” nyújt a platform szintjén ezen területekhez.
Miért vált népszerűvé a service mesh éppen most?
Valószínűleg most azt kérdezi: rendben, ha a service mesh ennyire jó, miért nem kezdtük el már tíz éve megvalósítani a milliárdnyi proxyt a stackben?
A kérdésre egy banális válasz van: tíz éve mindenki monolitokat épített, és senkinek sem volt szüksége service mesh-re. Ez igaz, de véleményem szerint ebben a válaszban elveszik a lényeg. Még tíz évvel ezelőtt is széles körben beszéltek és alkalmazták a mikroszolgáltatások koncepcióját mint ígéretes módszert a nagyméretű rendszerek létrehozására olyan cégeknél, mint a Twitter, Facebook, Google és Netflix. Az általános vélekedés – legalábbis azokban az iparági részekben, amelyekkel kapcsolatba kerültem – az volt, hogy a mikroszolgáltatások a „helyes mód” nagyméretű rendszerek építésére, még ha borzasztóan nehéz is volt.
Persze, annak ellenére, hogy tíz évvel ezelőtt is voltak cégek, amelyek mikroszolgáltatásokat alkalmaztak, nem helyeztek proxyt mindenhol, ahol csak lehetett, hogy service mesht alakítsanak ki. Azonban ha közelebbről megnézzük, hasonlót tettek: sok ilyen cégnél előírták, hogy speciális belső könyvtárat használjanak a hálózati interakciókhoz (néha vastag kliens könyvtárnak hívják, fat client library).
A Netflixnél volt a Hysterix, a Google-nál a Stubby, a Twitteren pedig a Finagle könyvtár. A Finagle például kötelező volt minden új szolgáltatás számára a Twitteren. Képes volt kezelni mind a kliens, mind a szerver kapcsolatait, lehetővé tette az újrakérések végrehajtását, támogatta a kérések irányítását, a terheléselosztást és a méréseket. Egy konzisztens megbízhatósági és észlelhetőségi réteget biztosított a Twitter teljes stackjéhez, függetlenül attól, hogy mivel foglalkozott a szolgáltatás. Persze, csak a JVM nyelveken működött és azon programozási modell alapult, amelyet az alkalmazás egészére használni kellett. Azonban a funkciói szinte azonosak voltak a service mesh-ével. (A Linkerd első verziója valójában a Finagle volt, proxy formába öltöztetve.)
Tíz évvel ezelőtt tehát nemcsak mikroszolgáltatások léteztek, hanem olyan speciális proto-service-mesh könyvtárak is, amelyek ugyanazokat a problémákat oldották meg, mint amiket a service mesh ma kezel. Azonban maga a service mesh akkor még nem létezett. Mielőtt megjelent volna, még egy elmozdulásnak meg kellett történnie.
És pontosan itt rejlik a mélyebb válasz, amely az elmúlt 10 évben történt egy másik változásban gyökerezik: drámai csökkenés történt a mikroszolgáltatások telepítési költségeiben. Az említett vállalatok, amelyek tíz évvel ezelőtt mikroszolgáltatásokat használtak: Twitter, Netflix, Facebook, Google, óriási méretű és erőforrásokkal rendelkező cégek voltak. Nemcsak szükségük volt rá, hanem volt lehetőségük is nagy mikroszolgáltatáson alapuló alkalmazások létrehozására, telepítésére és üzemeltetésére. A Twitter mérnökeinek energia- és erőfeszítései a monolitikusról a mikroszolgáltatás-alapú megközelítésre való átállás során valóban lenyűgözőek. (Őszintén, ahogyan az a tény is, hogy ez sikerült.) Ilyen jellegű infrastruktúrával kapcsolatos manőverek kisebb cégek számára akkoriban lehetetlenek voltak.
Visszatérve a jelenbe. Ma olyan startupok léteznek, ahol a mikroszolgáltatások és a fejlesztők aránya 5:1 (vagy akár ), és ráadásul sikeresen megbirkóznak velük! Ha egy 5 fős startup képes problémamentesen kezelni 50 mikroszolgáltatást, akkor nyilvánvalóan valami csökkentette a bevezetésük költségeit.
1500 mikroszolgáltatás a Monzónál; minden sor - egy hálózati szabály, amely engedélyezi a forgalmat
A mikroszolgáltatások üzemeltetési költségeinek drámai csökkenése egy folyamat eredménye: a konténerek népszerűségének növekedése és a gyakorló felügyeleti eszközök. Ebben rejlik a mély válasz arra a kérdésre, mi segítette elő a service mesh megjelenését. Ugyanaz a technológia tette vonzóvá a service mesht és a mikroszolgáltatásokat: a Kubernetes és a Docker.
Miért? Nos, a Docker egy jelentős problémát old meg - a csomagolás problémáját. Az alkalmazás és annak (nem hálózati) runtime függőségei konténerbe csomagolásával a Docker az alkalmazást egy helyettesíthető egységgé alakítja, amelyet bárhol el lehet helyezni és futtatni lehet. Ugyanakkor jelentősen leegyszerűsíti az üzemeltetést többnyelvű Stát: mivel je container atomáris végrehajtási egység, a telepítési és üzemeltetési célokból nem számít, hogy mi található benne, legyen az JVM, Node, Go, Python vagy Ruby alkalmazás. Csupán elindítod, és kész is.
A Kubernetes új szintre emeli az egészet. Most, hogy rengeteg "végrehajtható dolog" és számos gép van, amin ezek futtathatók, szükség van egy eszközre, amely képes őket egymáshoz rendelni. Széles értelemben véve sok konténert és sok gépet adsz a Kubernetesnek, és ő rendeli őket egymáshoz (természetesen ez egy dinamikus és folyamatosan változó folyamat: új konténerek vándorolnak a rendszeren, gépek indulnak és állnak le, stb. De a Kubernetes mindezt figyelembe veszi).
A Kubernetes beállítása után az egy szolgáltatás telepítési és üzemeltetési időigénye alig különbözik a tíz szolgáltatásétól (valójában szinte azonos, sőt, akár 100 szolgáltatás esetén is). Ezt kiegészítve a konténerek csomagolási mechanizmusával, amely ösztönzi a többnyelvű megvalósítást, egy sor új alkalmazást kapunk, amelyek mikroszolgáltatások formájában, különböző nyelveken valósulnak meg — pontosan az a környezet, amire a service mesh jól illeszkedik.
Tehát elérkezünk a kérdéshez, hogy miért vált a service mesh ötlet olyan népszerűvé éppen most: a Kubernetes által a szolgáltatások számára biztosított egységesség közvetlenül alkalmazható a service mesh előtt álló üzemeltetési feladatokra. Konténerekbe csomagolod a proxikat, a Kubernetesnek pedig feladatul adod, hogy bárhová elhelyezze őket, és voilà! Egy működő service mesh-t kapsz, amelynek telepítési mechanikáját a Kubernetes irányítja. (Legalábbis madártávlatból. Természetesen a folyamatnak számos árnyalata van.)
Összefoglalva: a service mesh népszerűvé válásának oka, hogy ez jelenleg, nem pedig tíz évvel ezelőtt, abban rejlik, hogy a Kubernetes és a Docker nemcsak jelentősen megnövelték a keresletet iránta, megkönnyítve az alkalmazások megvalósítását többnyelvű mikroszolgáltatás-gyűjteményekként, hanem jelentősen csökkentették is a költségeket az üzemeltetés során, biztosítva a sidecar proxyk telepítési és fenntartási mechanizmusait.
Miért van annyi beszéd a service mesh-ről?
Figyelmeztetés: ebben a részben mindenféle feltételezéseket, sejteket, spekulációkat és belső információkat alkalmazok.
Ha a „service mesh” kifejezésre kerestek, tele fog találkozni egy csomó átdolgozott, alacsony kalóriatartalmú tartalommal, fura projektekkel és torzítások kaleidoszkópjával, amelyek érdemesek az eko-terekre. Minden divatos új technológiánál így van ez, de a service mesh esetében a probléma különösen éles. Miért?
Nos, részben ez az én hibám. Minden erőmmel azon vagyok, hogy népszerűsítsem a Linkerd-t és a service mesh-t, amikor csak lehetőség adódik rá, végtelen blogbejegyzések és hasonló cikkek révén. De nem vagyok elég erős. Ahhoz, hogy igazán választ tudjak adni erre a kérdésre, egy kicsit beszélni kell a helyzet egészéről. És erről nem lehet beszélni, ha nem említünk meg egy projektet: — egy nyílt forráskódú service mesh, amelyet közösen fejleszt a Google, az IBM és a Lyft.
(E három cégnek teljesen különböző szerepei vannak: a Lyft részvétele látszólag csak a név alapján áll; ők az Envoy szerzői, de nem használják az Istio-t és nem vesznek részt a fejlesztésében. Az IBM részt vesz az Istio fejlesztésében és használja is. A Google aktívan részt vesz az Istio fejlesztésében, de a meglátásom szerint valójában nem használja.)
Az Istio projekt két kiemelkedő jellemzővel rendelkezik. Először is, ez a hatalmas marketing erőfeszítések, amelyeket a Google, különösen az Istio népszerűsítésére irányul. Becslésem szerint a service mesh koncepcióját ismerő emberek többsége jelenleg először hallott róla az Istio-nak köszönhetően. A második jellemzője az, hogy mennyire rosszul fogadták az Istio-t. Nyilvánvalóan egy érdekeltségi oldalról nézem ezt a dolgot, de próbálva maximálisan objektív maradni, mégis nem tudom elkerülni, hogy , ami nem túl jellegzetes (bár nem egyedi: eszembe jut a systemd, …) az Open Source projektekhez.
(A gyakorlatban úgy tűnik, hogy az Istio nemcsak a bonyolult és felhasználói élmény (UX) kérdéseivel küzd, hanem a teljesítményével is. Például a Linkerd teljesítményének , amelyet egy harmadik fél végzett, a szakértők olyan helyzeteket találtak, ahol az Istio késleltetési maximumai 100-szor meghaladták a Linkerd-hez viszonyított hasonló értéket, és olyan helyzeteket, amikor a Linkerd sikeresen működött, míg az Istio teljesen leállt.)
Hagyva a saját elméleteimet arról, hogy miért történt ez, úgy vélem, hogy a service mesh körüli nagy felhajtást pontosan a Google részvétele magyarázza. Méghozzá a következő három tényező kombinációja miatt:
- a Google mániákus Istio népszerűsítése;
- az ehhez kapcsolódó elutasító, kritikus hozzáállás a projekttel szemben;
- a Kubernetes közelmúltbeli robbanásszerű népszerűsége, aminek emléke még mindig friss.
Ezek a tényezők együtt egyfajta bódító, oxigén nélküli környezetet alkotnak, ahol a racionális gondolkodás képessége csökken, és csak egy csodálatos változat marad meg: .
A Linkerd vonatkozásában ezt… egy ambivalens jónak írnám le. Arra gondolok, hogy csodálatos, hogy a service mesh a mainstreambe került — ami 2016-ban nem volt jelen, amikor a Linkerd csak megjelent, és valóban nehéz volt felhívni a figyelmet a projektre. Most már ezzel a problémával nincs dolgunk! De a helyzet az, hogy a service mesh ma annyira zavaros, hogy gyakorlatilag lehetetlen megérteni, mely projektek tartoznak valóban a service mesh kategóriájába (nem is beszélve arról, hogy melyik a legjobban illeszkedik egy adott használati esetre). Ez kétségtelenül hátráltat mindenkit (és határozottan, bizonyos esetekben az Istio vagy más projektek jobban megfelelnek, mint a Linkerd, mivel az utóbbi nem univerzális megoldás).
A 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ódi problémáinak megoldására összpontosítsunk, és lényegében várjunk, amíg a felhajtás lecseng. Végül is a hype csökkenni fog, és nyugodtan dolgozhatunk tovább.
Addig mindannyiunknak türelmesnek kell lennie.
Hasznos lesz számomra, mint szerény szoftverfejlesztő számára a service mesh?
A kérdés megválaszolásában segít a következő kérdőív:
Csak az üzleti logika megvalósításával foglalkozik? Abban az esetben a service mesh nem szükséges számunkra. Tehát persze, érdeklődhet iránta, de ideális esetben a service mesh-nek nem szabad közvetlenül befolyásolnia semmit a környezetében. Folytassa azt a munkát, amiért fizetik.
Támogatja a platformot egy olyan cégnél, amely Kubernetes-t használ? Igen, ebben az esetben szüksége van service meshre (persze, ha nem a K8s-t csak monolitok futtatására vagy batch feldolgozásra használja — de akkor szeretném megkérdezni, miért van szüksége a K8s-re). Valószínűleg abban a helyzetben találja magát, hogy számos mikroszolgáltatás van, amelyeket különböző emberek írtak. Ezek mind kölcsönhatásban vannak egymással, és egy futásidejű dependenciákból álló kusza hálózatot alkotnak, amivel meg kell birkóznia. A Kubernetes alkalmazása lehetőséget ad arra, hogy a saját igényeihez igazodó service mesh-t válasszon. Ehhez ismerkedjen meg a lehetőségekkel és jellemzőikkel, majd válaszoljon arra a kérdésre, hogy egyáltalán illik-e bármelyik meglévő projekt az ön számára (ajánlom a Linkerd-t, mint kutatásának kiindulópontját).
Egy platformért felelős a cégnél, amely NEM használ Kubernetes-t, de mikroszolgáltatásokat alkalmaz? Ebben az esetben a service mesh hasznos lehet az ön számára, de a használata nem trivális. Természetesen lehetőség van arra, hogy szimulálja a service mesh működését egy csomó proxy elhelyezésével, de a Kubernetes egyik fontos előnye éppen a telepítési modell: ezen proxy-k kézi karbantartása sokkal több időt, energiát és költséget igényel.
Ön felel a platformért a cégnél, amely monolitokkal dolgozik? Ebben az esetben a service mesh valószínűleg nem szükséges. Ha monolitokkal (vagy akár egy monolitokból álló készletet) kezel, amelyeknek jól meghatározott és ritkán változó kölcsönhatási mintái vannak, akkor a service mesh nem sokat fog tudni ajánlani. Tehát nyugodtan figyelmen kívül hagyhatja, és remélheti, hogy eltűnik, mint egy rémálom...
Zárás
Valószínűleg a service mesht mégsem érdemes "a világ legnagyobb hype technológiájának" nevezni — ezt a kétséges tisztséget valószínűleg a bitcoin vagy az AI bírja. Talán benne van az első öt között. De ha áttörjük a zaj és a zűrzavar rétegeit, világossá válik, hogy a service mesh valódi előnyöket hoz azok számára, akik Kubernetesben alkalmazásokat fejlesztenek.
Szeretném, ha kipróbálná a Linkerd-t — a telepítése a Kubernetes klaszterbe (vagy akár a Minikube-ba a laptopján) , és ön is láthatja, miről beszélek.
GYIK
— Ha figyelmen kívül hagyom a service mesht, eltűnik?
— Meg kell, hogy csalódjak: a service mesh velünk marad hosszú távon.
— De én NEM AKAROM használni a service mesht!
— Hát, nem is kell! Csak olvassa el a fenti kérdőívemet, hogy megértse, érdemes-e legalább az alapjaival megismerkedni.
— Nem ez a régi jó ESB/middleware egy új ruhában?
— A szolgáltatásmesh az üzemeltetési logikával foglalkozik, nem a jelentéssel. a vállalati busz (). E kettős elválasztás segít a szolgáltatásmeshnek elkerülni ugyanazt a sorsot.
— Miben különbözik a szolgáltatásmesh az API-hidakból?
— Erről millió cikk létezik. Csak keresgélj egy kicsit.
— Az Envoy egy szolgáltatásmesh?
— Nem, az Envoy nem szolgáltatásmesh, hanem egy proxy szerver. Használható szolgáltatásmesh létrehozására (és sok minden másra is — ez egy általános célú proxy). De önmagában nem szolgáltatásmesh.
— A Network Service Mesh egy szolgáltatásmesh?
— Nem. A neve ellenére nem szolgáltatásmesh (hogy is lehetne a marketing csodáival?).
— Segít a szolgáltatásmesh a reaktív aszinkron rendszeremnek, amely üzenetsorokon alapul?
— Nem, a szolgáltatásmesh nem segít.
— Melyik szolgáltatásmesht használjam?
— , ez egyértelmű.
— A cikk szörnyű! / Az írót a szemétbe!
— Kérlek, oszd meg a linket minden barátoddal, hogy ők is megbizonyosodhassanak róla!
Köszönetnyilvánítások
Ahogyan a címben is láthatod, ez a cikk Jay Kreps fantasztikus értekezésén alapul,». Tíz évvel ezelőtt találkoztam Jay-jel, amikor interjút készítettem a LinkedIn-en, és azóta is inspirációt nyújt számomra.
Bár szeretem magam „Linkerd fejlesztőnek” hívni, a valóság az, hogy inkább a README.md fájl karbantartója vagyok a projektben. A Linkerd-en ma , , ember dolgozik, és ez a projekt nem valósulhatott volna meg a csodálatos közösség hozzájárulása és felhasználói 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 mélyen belemerült ebbe a szolgáltatásmesh körüli zűrzavarba.
Fejlesztési eszközök, amelyek Kubernetesben futnak
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «»;
- «»;
- «».
Forrás: habr.com
