Megjegyzés fordítás.: a cikk szerzője (Luc Perkins) – fejlesztői képviselő a CNCF-nél, amely otthona olyan nyílt forráskódú projekteknek, mint a Linkerd, SMI (Service Mesh Interface) és a Kuma (ugyebár, te is elgondolkodtál rajta, miért nincs itt az Istio?). Ismét megpróbálva jobb megértést hozni a DevOps közösségbe a 'szolgáltatási hálózat' népszerűsített hype-ján, 16 jellegzetes lehetőséget sorol fel, amelyeket az ilyen megoldások kínálnak.
Ma – az egyik legforróbb téma a szoftvermérnöki területen (és ez joggal van így!). Rendkívül ígéretesnek tartom ezt a technológiát, és vágyom arra, hogy tanúja legyek a széleskörű elterjedésének (persze, amikor ennek értelme van). Mindazonáltal még mindig titokzatos aurával övezi a legtöbb ember számára. Ráadásul azok is, akik jól ismerik ezt, gyakran nehezen tudják megfogalmazni annak előnyeit és pontosan mit is jelent (beleértve az alázatos szolgámat is). A cikkben megpróbálom javítani a helyzetet, felsorolva a különböző használati forgatókönyveket a 'szolgáltatási hálózat' számára*.
* Megjegyzés: a cikkben a 'szolgáltatási hálózat' fordítást fogom alkalmazni a még mindig új "service mesh" kifejezésre.
De először szeretnék néhány megjegyzést tenni:
- Sosem dolgoztam szolgáltatási hálózattal és nem használtam azokat olyan projekteken kívül, amelyeket a saját tanulásom érdekében indítottam. Ugyanakkor én írtam rengeteg dokumentációt a Twitter belső szolgáltatási hálózatához 2015-ben (akkor még nem is nevezték 'szolgáltatási hálózatnak'), és részt vettem egy weboldal és dokumentáció fejlesztésében a , szóval ez valamit jelent.
- A listám példás és nem teljes. Előfordulhatnak olyan használati forgatókönyvek, amelyeket nem ismerek, és idővel biztosan új variációk is megjelennek, a technológia fejlődésével és népszerűségének növekedésével.
- Azt is figyelembe kell venni, hogy nem minden meglévő szolgáltatási hálózati megvalósítás támogatja az összes felsorolt használati esetet. Ezért a 'a szolgáltatási hálózat képes…' kifejezéseimet úgy kell olvasni, mint 'a különböző, esetleg az összes népszerű szolgáltatási hálózati megvalósítás képes…'.
- A példák sorrendje ilyen szempontból nem lényeges.
Rövid lista:
- szolgáltatások felfedezése;
- titkosítást;
- hitelesítés és jogosultságkezelés;
- terheléselosztás;
- áramkör megszakítás;
- automatikus skálázás;
- kanáris bevezetések;
- türkiz-kék telepítések;
- egészségellenőrzés;
- terheléscsökkentés;
- forgalom tükörzés;
- izoláció;
- lekérdezési frekvencia korlátozás, újrapróbálkozások és időtúllépések;
- telemetria;
- audit;
- vizualizáció.
1. Szolgáltatások felfedezése
TL;DR: Csatlakozzon más szolgáltatásokhoz a hálózaton egyszerű nevekkel.
A szolgáltatásoknak képesnek kell lenniük automatikusan "megtalálni" egymást megfelelő nevekkel - például, service.api.production, pets/staging vagy cassandra. A felhőalapú környezetek rugalmasságukkal tűnnek ki, és egy név mögött számos szolgáltatás példány rejtőzhet. Nyilvánvaló, hogy ilyen helyzetben fizikailag lehetetlen minden IP-címet hardveresen definiálni.
Ráadásul, amikor egy szolgáltatás találkozik egy másikkal, képesnek kell lennie arra, hogy kéréseket küldjön ennek a szolgáltatásnak, anélkül, hogy attól kellene tartania, hogy ezek a nem működő példányokhoz kerülnek. Más szavakkal, a service mesh-nek nyomon kell követnie minden szolgáltatás példányának működését, és a gazdagépek listáját naprakészen kell tartania.
Minden service mesh egyedien valósítja meg a szolgáltatások felfedezésének mechanizmusát. Jelenleg a legelterjedtebb módszer a DNS Kubernetes-hez hasonló külső folyamatok delegálása. A múltban a Twitternél ilyen célokra a névrendszert használtuk. . Ezenkívül a service mesh technológia lehetővé teszi a felhasználói névadási mechanizmusok megjelenését (bár még nem találkoztam egyetlen SM megvalósítással sem, amelynek ilyen funkciója lenne).
2. Titkosítás
TL;DR: Szabaduljon meg a titkosítatlan forgalomtól a szolgáltatások között, és a folyamat legyen automatizált és skálázható.
Jó tudni, hogy a kiberbűnözők nem tudnak behatolni a belső hálózatába. A hálózati tűzfalak ezt remekül kezelik. De mi történik, ha egy hacker mégis bejut? A belső szolgáltatási forgalommal bármit megtehet? Reméljük, hogy ez mégsem következik be. Az ilyen forgatókönyv megakadályozása érdekében zero-trust (nulla bizalom) hálózatot kell megvalósítani, amelyben minden forgalom a szolgáltatások között titkosított. A legtöbb modern szolgáltatási hálózat ezt kölcsönös (kölcsönös TLS, mTLS) segítségével valósítja meg. Egyes esetekben az mTLS egész felhőkben és klaszterekben működik (gondolom, hogy egyszer majd a bolygók közötti kommunikáció is hasonlóan működik majd).
Természetesen, az mTLS szolgáltatásrács esetében nem kötelező. Minden szolgáltatás saját magáról gondoskodhat a TLS tekintetében, de ez azt jelenti, hogy meg kell találni a módját a tanúsítványok generálásának, azok elosztásának a szolgáltatás gazdagépein, és a kódot be kell építeni az alkalmazásba, amely betölti ezeket a tanúsítványokat a fájlokból. Igen, és ne feledje az ezen tanúsítványok időszakos frissítését sem. A szolgáltatásrácsok automatizálják az mTLS-t olyan rendszerek segítségével, mint a , amelyek automatizálják a tanúsítványok kiadásának és rotációjának folyamatát.
3. Hitelesítés és engedélyezés
TL;DR: Állapítsa meg, ki a kérés kezdeményezője, és határozza meg, mit jogosult a továbbiakban tenni, mielőtt a kérés eléred a szolgáltatást.
A szolgáltatások gyakran tudni akarják, ki végzi a kérést (hitelesítés), és ezen információ alapján eldöntik, mit engedélyeztek az adott alany számára (engedélyezés). Ebben az esetben a „ki” helyett állhat:
- Más szolgáltatások. Ezt „peer” hitelesítésnek hívják. Például, egyweb
szolgáltatás szeretne hozzáférni egydbszolgáltatáshoz. A szolgáltatásrácsok általában mTLS segítségével oldják meg az ilyen problémákat: a tanúsítványok ebben az esetben szükséges azonosítóként szolgálnak.Néhány felhasználó. Ezt „kérés hitelesítésének” hívják. - Például a felhasználó haxor69szeretne venni egy új lámpát. A szolgáltatásrácsok különböző mechanizmusokat kínálnak, például:
JSON Web TokenekSokan közülünk így dolgoztunk a kód alkalmazásában. Érkezik egy kérés, megnézzük a táblázatot ., megtaláljuk a felhasználót és összehasonlítjuk a jelszót, majd ellenőrizzük a "permissions" oszlopot és így tovább. A szolgáltatásrács esetében ez még azelőtt történik, hogy a kérés elérné a szolgáltatást.
Miután megállapítottuk, hogy ki küldte a kérést, meg kell határoznunk, hogy az adott alanynak mit engedélyeztek. Egyes szolgáltatásrácsok lehetővé teszik alapvető irányelvek (arról, hogy ki mit tehet) megadását YAML-fájlok formájában vagy parancssoron, míg mások integrációt kínálnak olyan keretrendszerekkel, mint azOpen Policy Agent.A végcél az, hogy a szolgáltatásai bármilyen kérést elfogadjanak, magabiztosan feltételezve, hogy megbízható forrásból származnakez a cselekvés engedélyezve van.
4. Terheléselosztás TL;DR: A terhelést oszd el a szolgáltatás példányai között meghatározott minta alapján. és Ez engedélyezett.
4. Terheléselosztás
TL;DR: Ossza el a terhelést a szolgáltatás példányai között egy meghatározott minta szerint.
A „szolgáltatás” a szolgáltatási szekcióban gyakran összetett az azonos példányok sokaságából. Például ma a szolgáltatás cache öt példányból áll, de holnapra a számuk akár tizenegyre is nőhet. A beérkező kéréseknek cache, célnak megfelelően kell eloszlaniuk. Például a késleltetés minimalizálása vagy a működő példányra való eljutás valószínűségének maximalizálása. Leggyakrabban a körkörös kiszolgálási algoritmus (Round-robin) használatos, de sok más módszer is létezik - például a súlyozott (weighted) kérések (előnyben részesíthetők a kívánt célok), a gyűrűs (ring) hash-elés (konzisztens hash-elés használata a upstream hosztokhoz) vagy a legkevesebb kérés módszere (előnyben részesítve a legkevesebb kérésű példányt).
A klasszikus terheléselosztók más funkciókkal is rendelkeznek, mint például HTTP cache-elés és DDoS védelem, de ezek nem nagyon relevánsak az east-west típusú forgalom szempontjából (azaz a forgalom, amely a datacenteren belül halad - a fordító megjegyzése) (tipikus alkalmazási terület a service mesh). Természetesen nem kötelező service mesh-t használni terheléselosztásra, azonban ez lehetővé teszi a terheléselosztási politikák központosított irányító réteg általi meghatározását és ellenőrzését, így megszüntetve a külön terheléselosztók futtatásának és konfigurálásának szükségességét a hálózati stackben.
5. Áramkörmegszakítás (circuit breaking)
TL;DR: Állítsa le a forgalmat a problémás szolgáltatás irányába, és ellenőrizze a sérülést a legrosszabb forgatókönyvek esetén.
Ha valamilyen okból a szolgáltatás nem képes kezelni a forgalmat, a service mesh több megoldási lehetőséget is kínál (másokról a vonatkozó részekben fogunk beszélni). Az áramkörmegszakítás a legszigorúbb módja a szolgáltatás forgalomról való leválasztásának. Azonban önmagában nem sok értelme van - szükséges egy tartalék terv. A kérés teljesítését végző szolgáltatások számára lehet előirányozni visszahatást () a kérések kezelésére (csak ne feledje el beállítani a service mesh-ét ehhez!), vagy például a státuszoldal színének pirosra festését és a felhasználók átirányítását egy másik „lebukott bálnás” oldalra („Twitter is down”).
A szolgáltatási hálózatok nemcsak azt teszik lehetővé, hogy mikor történjen meg a leállítás és mit Ezután következik. Ebben az esetben a „mikor” bármilyen kombinációt magában foglalhat, például egy adott időszak alatt tett lekérdezések összesített számát, a párhuzamos kapcsolatok számát, a függőben lévő lekérdezéseket, az aktív újrapróbálkozásokat stb.
Valószínűleg nem akarja visszaélni a circuit breaking-gel, de jó tudni, hogy van egy tartalék terv vészhelyzet esetére.
6. Automatikus méretezés
TL;DR: Növelje vagy csökkentse a szolgáltatás példányainak számát a megadott kritériumok szerint.
A service mesh-ek nem tervezők, ezért nem valósítanak meg automatikus méretezést. Azonban információkat tudnak szolgáltatni, amelyek alapján a tervezők döntenek. Mivel a service mesh-ek hozzáférnek a szolgáltatások közötti forgalomhoz, széleskörű információkkal rendelkeznek arról, hogy mi történik: mely szolgáltatások ütköznek problémákba, melyekkal a teljesítményük alacsony (az erőforrások pazarolják el) stb.
Például a Kubernetes a szolgáltatásokat a pod-ok CPU és memória használata szerint méretezi (lásd a „” — ford. megj.), de ha úgy dönt, hogy méretezést hajt végre bármely más mutató alapján (jelen esetben a forgalommal kapcsolatos), speciális metrikára lesz szüksége. Az útmutatók megmutatja, hogyan kivitelezhető ez az , és , de magának a folyamatnak a bonyolultsága miatt szeretnénk, ha a service mesh egyszerűsítené azt, lehetővé téve számunkra, hogy csak olyan feltételeket adjunk meg, mint például „növelje a szolgáltatás példányainak számát auth, ha a várakozó lekérdezések száma meghaladja a küszöbértéket egy percig”.
7. Kanári telepítések
TL;DR: Új funkciókat vagy a szolgáltatás új verzióit tesztelje a felhasználók egy részhalmazán.
Mondjuk, hogy fejleszt egy SaaS-terméket, és el kívánja indítani annak új, menő verzióját. Tesztelte a staging környezetben, és tökéletesen működött. Ennek ellenére vannak bizonyos aggályai a valódi körülmények közötti viselkedésével kapcsolatban. Más szavakkal, ellenőriznie kell az új verziót valós feladatokon, anélkül, hogy veszélyeztetné a felhasználók bizalmát. A kanári telepítések tökéletesen alkalmasak erre. Lehetővé teszik egy új funkció bemutatását a felhasználók egy bizonyos csoportja számára, amely lehet a leglojalitásabb felhasználókból, a termék ingyenes verziójával dolgozókból, vagy azokból, akik hajlandók „kísérleti nyulakként” részt venni.
A szolgáltatásmesh-ek megvalósítják ezt, lehetővé téve a kritériumok meghatározását, amelyek jelzik, hogy ki és mely verziót fog látni az alkalmazásból, és ennek megfelelően irányítják a forgalmat. A szolgáltatások számára semmi sem változik. Az 1.0 verzió úgy véli, hogy minden kérés a felhasználóktól érkezik, akiknek ezt a verziót kellene látniuk, míg az 1.1 verzió ugyanezt gondolja a saját felhasználóiról. Ön közben változtathatja a forgalom százalékát a régi és az új verzió között, átirányítva a növekvő számú felhasználót az új verzióra, ha az stabilan működik, és a „kísérleti” felhasználói jóváhagyják.
8. Kék-zöld telepítések
TL;DR: Indítson el egy új menő funkciót, de készüljön fel arra, hogy azonnal visszaállítsa az előzőt.
Az elképzelés az, hogy egy új „kék” szolgáltatást indítunk el, párhuzamosan a régi, „zöld” szolgáltatással. Ha minden jól megy, és az új szolgáltatás jól teljesít, akkor a régi fokozatosan lekapcsolható. (Sajnos egyszer csak ez az új „kék” szolgáltatás is megismétli a „zöld” sorsát és eltűnik…) A kék-zöld telepítések különböznek a kanáriaktól abban, hogy az új funkció mindenki számára elérhető felhasználók (nem pedig egy részük); az elképzelés itt az, hogy legyen egy „backup”, ha esetleg valami nem a tervek szerint alakul.
A szolgáltatásmesh nagyon kényelmes módot kínál a "kék" szolgáltatás tesztelésére és az azonnali átkapcsolásra a működő "zöld" szolgáltatásra, ha problémák merülnek fel. Arról nem is beszélve, hogy emellett rengeteg információt is ad (lásd az alábbi "Telemetria" részt) a "kék" működéséről, amely segít megérteni, készen áll-e a teljes körű üzemeltetésre.
Megjegyzés fordítás.: Részletesebben a Kubernetes különböző telepítési stratégiáiról (beleértve a canary, blue/green és másokat) olvashat a .
9. Egészségellenőrzés
TL;DR: Figyelje az aktív szolgáltatás példányokat, és reagáljon azokra, amelyek nem működnek.
Egészségellenőrzés (health check) segít eldönteni, hogy a szolgáltatás példányok készen állnak-e a forgalom fogadására és feldolgozására. Például HTTP-szolgáltatások esetében az egészségellenőrzés úgy nézhet ki, mint egy GET kérés egy végpontra. /healthVálasz 200 OK azonosítani fogja, hogy az példány egészséges, bármilyen más válasz pedig azt, hogy nem kész a forgalom fogadására. A szolgáltatásmesh lehetővé teszi, hogy megadja az ellenőrzés módját, és azt a gyakoriságot, amellyel ezt az ellenőrzést el kell végezni. Ezt az információt később más célokra is fel lehet használni - például terheléselosztásra és circuit breaking-re.
Így az egészségellenőrzés nem egy önálló felhasználási forgatókönyv, hanem általában más célok elérésére szolgál. Ezen kívül, az egészségellenőrzések eredményeitől függően külső (más szolgáltatásmesh célokkal szemben) intézkedések is szükségesek lehetnek: például állapotfrissítés, GitHub kérdés létrehozása vagy JIRA jegy kitöltése. A szolgáltatásmesh kényelmes mechanizmust kínál ennek automatizálására.
10. Terheléscsökkentés (load shedding)
TL;DR: Irányítsa át a forgalmat ideiglenes terheléscsúcs esetén.
Ha egy szolgáltatás túlterhelt a forgalom miatt, akkor ideiglenesen átirányíthat egy részt ebből a forgalomból egy másik helyre (vagyis "eldobhatja", "átvezetheti" (shed) oda). Például egy tartalék szolgáltatásba vagy adatközpontba, vagy egy tartósba téma. Ennek eredményeként, a szolgáltatás továbbra is részben feldolgozza a kéréseket, ahelyett, hogy leállna és egyáltalán nem dolgozna fel. A terheléscsökkentés előnyösebb, mint a lánc megszakítása, de azért nem kívánatos túlzottan visszaélni vele. Megakadályozza a láncreakciós hibákat, amelyek miatt a downstream szolgáltatások leállnak.
11. Párhuzamosítás / forgalom tükörözése
TL;DR: Küldjön egy kérést egyszerre több helyre.
Időnként szükség van arra, hogy egy kérést (vagy egyes kiválasztott kéréseket) egyszerre több szolgáltatásnak küldjön. Egy tipikus példa az, amikor a production forgalom egy részét a staging szolgáltatásra küldjük. A production fő webszervere egy kérést küld a mögöttes szolgáltatásnak products.production és csak ehhez. A service mesh intelligensen lemásolja ezt a kérést és továbbítja a products.staging, amiről a webszerver egyáltalán nem tud.
Egy másik kapcsolódó forgatókönyv a service mesh használatában, amelyet a forgalom párhuzamosítására építhetünk, az . Ez magában foglalja ugyanazoknak a kéréseknek a különböző verziókra történő küldését, és annak ellenőrzését, hogy minden verzió ugyanúgy viselkedik-e. Eddig még nem találkoztam olyan service mesh megvalósítással, amely beépített regressziós tesztelő rendszert, mint például , tartalmazott, de magának az ötletnek van potenciálja.
12. Izoláció
TL;DR: Törjön le a service mesh-t mini-hálózatokra.
Szintén ismert, mint szegmentálás, az izoláció a service mesh logikusan elkülönített szegmensekre való felosztásának művészete, amelyek semmit sem tudnak egymásról. Az izoláció némileg hasonlít a virtuális magánhálózatok létrehozásához. Az alapvető különbség azonban az, hogy továbbra is használhatja a service mesh minden előnyét (mint a szolgáltatások felfedezése), de a további biztonsággal. Például, ha egy támadó bejut a szolgáltatásba az egyik alhálózatban, nem tudja majd látni, milyen szolgáltatások futnak a másik alhálózatokban, vagy elfogni azok forgalmát.
Ezen kívül az előnyök szervezeti jellegűek is lehetnek. Lehet, hogy szeretné a szolgáltatásokat alhálózatokra bontani a cég struktúrája szerint, és megszabadítani a fejlesztőket a service mesh egészének fejben tartásából adódó kognitív terheléstől.
13. Kérések ütemezésének korlátozása, újrapróbálkozások és időkorlátok
TL;DR: Már nem kell a kódalapba beépíteni a kérések kezelésével kapcsolatos sürgős feladatokat.
Mindegyik dolog külön használati esetté is sorolható, de úgy döntöttem, hogy összefoglalom őket egy közös jegyében: átvállalják a kérések életciklusának kezelését, amit általában az alkalmazáskönyvtárak végeznek. Ha Ruby on Rails alapú webkiszolgálót fejlesztenél (amely nincs integrálva a szolgáltatási hálózattal), és hátszolgáltatásokkal végrehajtott kéréseket kezel, , a programnak magának kell eldöntenie, mit tegyen, ha N kérés sikertelenül zárul le. Meg kell határozni, hogy ezek a szolgáltatások mekkora forgalmat képesek kezelni, és ezeket a paramétereket külön könyvtárral kell 'hardcode'-olni. Ezen túlmenően a programnak el kell döntenie, mikor kell feladni és hagyni, hogy a kérés lejárjon (timeout). És bármelyik fent említett paraméter megváltoztatásához le kell állítani a webkiszolgálót, át kell konfigurálni és újra kell indítani.
E feladatok szolgáltatási hálózatra való átvitele nemcsak azt jelenti, hogy a szolgáltatásfejlesztőknek nem kell ezekkel foglalkozniuk, hanem azt is, hogy a kérés életciklusát globálisan lehet tekinteni. Ha egy bonyolult szolgáltatási lánc áll fenn, például A → B → C → D → E, figyelembe kell venni a kérés teljes életciklusát. Ha a C szolgáltatásban a timeoutokat szeretnénk meghosszabbítani, érdemes ezeket egyszerre csinálni, nem részletekben: a kód frissítése után várva a pull kérés jóváhagyására és a CI rendszerben a frissített szolgáltatás telepítésére.
14. Telemetria
TL;DR: Gyűjtsd össze az összes szükséges (és kevésbé szükséges) információt a szolgáltatásoktól.
A telemetria egy általános szakkifejezés, amely magában foglalja a metrikákat, a disztribúciós nyomozást és a naplókat. A szolgáltatási hálózatok mechanizmusokat kínálnak e három típusú adat gyűjtésére és feldolgozására. Itt a dolgok kissé elmosódottá válnak, mivel a lehetséges variációk száma túl nagy. A metrikák gyűjtésére vannak és más eszközök, a naplók gyűjtésére használható , , és mások. (például ClickHouse a mi K8s-hez - megj. ford.), a disztribúciós nyomozáshoz van stb. Minden szolgáltatási hálózat támogathat bizonyos eszközöket, és nem támogathat másokat. Érdekes lesz látni, hogy az valamilyen konvergenciát tud-e biztosítani.
Ebben az esetben a service mesh technológiájának előnye, hogy a sidecar konténerek elvileg összegyűjthetik az összes korábban említett adatot a szolgáltatásaiktól. Más szavakkal, egy egységes telemetria-gyűjtési rendszert kapunk, és a service mesh képes minden ezt az információt különböző módokon feldolgozni. Például:
- naplókat 'kémkedni' egy adott szolgáltatástól a CLI-n;
- nyomon követni a kérelmek számát a service mesh vezérlőpultján;
- összegyűjteni a diszperzített nyomkövetéseket, és azokat egy olyan rendszerbe irányítani, mint a Jaeger.
Figyelem, szubjektív vélemény: Általánosságban a telemetria az a terület, ahol a service mesh erőteljes beavatkozása nem kívánatos. Az alapinformációk összegyűjtése és néhány 'arany metrika', mint a sikeres kérések arányának és a késleltetések nyomon követése normális, de reméljük, hogy nem leszünk tanúi a Frankenstein-stackek felbukkanásának, amelyek megpróbálnák helyettesíteni a specializált rendszereket, amelyek közül néhány már remekül teljesítette a szerepét és jól tanulmányozott.
15. Audit
TL;DR: Aki elfelejti a történelem leckéit, meg van áldva azzal, hogy megismétli azokat.
Az audit a fontos események megfigyelésének művészete a rendszerben. A service mesh esetében ez azt jelentheti, hogy nyomon követjük, ki tett kéréseket a konkrét szolgáltatások adott endpointjaival kapcsolatban, vagy hány alkalommal történt meg egy esemény a múlt hónapban, amely a biztonsággal kapcsolatos.
Nyilvánvaló, hogy az audit nagyon szorosan kapcsolódik a telemetriához. A különbség az, hogy a telemetria általában olyan dolgokkal asszociálódik, mint a teljesítmény és a technikai szilárdság, míg az audit jogi és egyéb kérdésekkel is foglalkozhat, amelyek túllépnek a szigorúan technikai szférán (például a GDPR - az EU általános adatvédelmi rendeletének való megfelelés).
16. Megjelenítés
TL;DR: Éljen a React.js – a különös interfészek kimeríthetetlen forrása.
Lehetséges, hogy van megfelelőbb kifejezés, de én nem tudom. Egyszerűen a service mesh vagy annak egyes komponenseinek grafikus megjelenítésére gondolok. Ezek a megjelenítések tartalmazhatnak mutatókat, mint az átlagos késleltetések, a sidecar konténerek konfigurációjára vonatkozó információk, a szolgáltatásellenőrzések eredményei és az értesítések.
A szolgáltatás-orientált környezetben történő munka sokkal erősebb kognitív terhet jelent, mint a Monolitus. Ezért a kognitív nyomást minden áron csökkenteni kell. Egy banális grafikus felület a service mesh-hez, amely lehetővé teszi a gombra kattintást és a kívánt eredmény elérését, döntő fontosságú lehet ennek a technológiának a népszerűségének növelésében.
Nem szerepel a listán
Eredetileg több használati esetet akartam felvenni a listára, de végül úgy döntöttem, hogy ezt nem teszem. Itt vannak együtt az én döntésem okai:
- Multi-datacenter. Az én értelmezésemben ez nem annyira használati eset, hanem egy szűk és konkrét alkalmazási terület a szolgáltatási hálózatok vagy egy funkciósorozat, mint például a szolgáltatások felfedezése.
- Ingress és egress. Ez egy kapcsolódó terület, de én (lehet, hogy mesterségesen) korlátoztam magam az „east-west forgalom” használati esetére. Az Ingress és egress külön cikket érdemelne.
Zárás
Eddig ennyi! Ismét, ez a lista eléggé feltételes és valószínűleg hiányos. Ha úgy érzi, hogy valamit kihagytam, vagy tévedtem, lépjen kapcsolatba velem Twitteren (). Kérem, tartsák be a tiszteletteljes kommunikáció szabályait.
Fejlesztési eszközök, amelyek Kubernetesben futnak
A cikk címillusztrációjának alapjául a „” (szerző: Gregory MacKinnon) című cikkből származó kép szolgál. Ez mutatja, hogy az alkalmazásokból (zöld szín) a szolgáltatás-hálózathoz átkerült funkciók hogyan biztosítják a köztük lévő összefüggéseket (kék szín).
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «».
Forrás: habr.com
