Üdv újra!.. A tanfolyam kezdetének előestéjén Újabb hasznos fordítást készítettünk.
A szolgáltatásháló egy konfigurálható, alacsony késleltetésű infrastruktúraréteg, amely az alkalmazásprogramozási interfészek (API-k) közötti nagy mennyiségű, hálózatalapú folyamatok közötti kommunikáció kezeléséhez szükséges. A Service Mesh gyors, megbízható és biztonságos kommunikációt tesz lehetővé a konténeres és gyakran átmeneti alkalmazásinfrastruktúra-szolgáltatások között. A Service Mesh olyan lehetőségeket biztosít, mint a szolgáltatáskeresés, a terheléselosztás, a titkosítás, az átláthatóság, a nyomon követhetőség, a hitelesítés és az engedélyezés, valamint az automatikus leállítási minta támogatása (biztosíték).
A szolgáltatáshálót általában úgy valósítják meg, hogy minden szolgáltatáspéldányhoz biztosítanak egy proxypéldányt, az úgynevezett Oldalkocsi. Oldalkocsi kezelni a szolgáltatások közötti kommunikációt, felügyelni és megoldani a biztonsági problémákat, vagyis mindent, ami az egyes szolgáltatásoktól elvonatkoztatható. Így a fejlesztők írhatnak, karbantarthatnak és szolgálhatnak ki alkalmazáskódot a szolgáltatásokban, a rendszergazdák pedig dolgozhatnak a Service Mesh-el és futtathatják az alkalmazást.
A Google, az IBM és a Lyft Istio jelenleg a leghíresebb service mesh architektúra. A Kubernetes pedig, amelyet eredetileg a Google-nál fejlesztettek ki, mára az egyetlen, az Istio által támogatott konténer-hangszerelési keretrendszer. A gyártók megpróbálják létrehozni az Istio kereskedelmileg támogatott verzióit. Érdekes lesz látni, milyen újdonságokat hozhatnak a nyílt forráskódú projektbe.
Az Istio azonban nem az egyetlen lehetőség, mivel más Service Mesh implementációkat is fejlesztenek. Minta sidecar proxy a legnépszerűbb megvalósítás, amint azt a Buoyant, HashiCorp, Solo.io és mások projektjei is meg tudják ítélni. Vannak alternatív architektúrák is: a Netflix technológiai eszközkészlet egyike azoknak a megközelítéseknek, ahol a Service Mesh funkcionalitás a Ribbon, Hysterix, Eureka, Archaius könyvtárakon, valamint olyan platformokon keresztül valósul meg, mint az Azure Service Fabric.
A Service Mesh saját terminológiával rendelkezik a szolgáltatási összetevőkre és funkciókra vonatkozóan:
- Konténer hangszerelési keret. Ahogy egyre több konténer kerül be az alkalmazási infrastruktúrába, szükség van egy külön eszközre a konténerek figyelésére és kezelésére - egy konténer hangszerelési keretrendszerre. A Kubernetes határozottan elfoglalta ezt a rést, olyannyira, hogy még fő versenytársai, a Docker Swarm és a Mesosphere DC/OS is kínálnak integrációt a Kubernetes-szel alternatívaként.
- Szolgáltatások és példányok (Kubernetes Pods). A példány egy mikroszolgáltatás egyetlen futó példánya. Néha egy példány egy tároló. A Kubernetesben egy példány független tárolók egy kis csoportjából áll, amelyeket podnak neveznek. Az ügyfelek ritkán férnek hozzá közvetlenül egy példányhoz vagy podhoz; gyakrabban férnek hozzá egy szolgáltatáshoz, amely azonos, méretezhető és hibatűrő példányok vagy podok (replikák) halmaza.
- Oldalkocsi Proxy. A Sidecar Proxy egyetlen példányban vagy podban működik. A Sidecar Proxy lényege, hogy irányítsa vagy proxyszerezze a forgalmat, amely abból a tárolóból érkezik, amellyel dolgozik, és visszaadja a forgalmat. Az oldalkocsi kölcsönhatásba lép más Sidecar proxykkal, és egy hangszerelési keretrendszer kezeli. Sok Service Mesh-megvalósítás Sidecar Proxy használatával elfogja és kezeli a példányon vagy podokon be- és kimenő összes forgalmat.
- Szolgáltatás felfedezése. Amikor egy példánynak kommunikálnia kell egy másik szolgáltatással, meg kell találnia (fel kell fedeznie) a másik szolgáltatás egészséges és elérhető példányát. Általában a példány DNS-kereséseket hajt végre. A konténer-rendezési keretrendszer karbantartja azon példányok listáját, amelyek készen állnak a kérések fogadására, és felületet biztosít a DNS-lekérdezésekhez.
- Terhelés elosztás. A legtöbb konténer-hangszerelési keretrendszer terheléselosztást biztosít a 4. rétegben (szállítás). A Service Mesh összetettebb terheléselosztást valósít meg a 7. rétegben (alkalmazásszint), amely gazdag algoritmusokban és hatékonyabb a forgalomkezelésben. A terheléselosztás beállításai módosíthatók az API segítségével, lehetővé téve a kék-zöld vagy a kanári telepítések összehangolását.
- Titkosítás. A Service Mesh képes titkosítani és visszafejteni a kéréseket és válaszokat, eltávolítva ezt a terhet a szolgáltatásokról. A Service Mesh a meglévő állandó kapcsolatok priorizálásával vagy újrafelhasználásával is javíthatja a teljesítményt, csökkentve az új kapcsolatok létrehozásához szükséges költséges számítások szükségességét. A forgalom titkosításának leggyakoribb megvalósítása az kölcsönös TLS (mTLS), ahol egy nyilvános kulcsú infrastruktúra (PKI) állít elő és oszt el tanúsítványokat és kulcsokat a Sidecar Proxy számára.
- Hitelesítés és engedélyezés. A Service Mesh engedélyezheti és hitelesítheti az alkalmazáson kívülről vagy belülről érkező kéréseket, és csak az érvényesített kéréseket küldi el a példányoknak.
- Automatikus leállítási minta támogatása. Service Mesh támogatja , amely elkülöníti az egészségtelen példányokat, majd szükség esetén fokozatosan visszahelyezi őket az egészséges példányok készletébe.
A Service Mesh alkalmazás azon része, amely a példányok közötti hálózati forgalmat kezeli, meghívásra kerül Adat sík. Hozzon létre és telepítsen konfigurációt, amely szabályozza a viselkedést Adat sík, egy különálló Irányító sík. Irányító sík általában tartalmaz egy API-t, CLI-t vagy GUI-t, vagy arra tervezték, hogy csatlakozzon az alkalmazás vezérléséhez.
A Service Mesh-ben lévő vezérlősík elosztja a konfigurációt az oldalkocsi-proxy és az adatsík között.
A Service Mesh architektúrát gyakran használják összetett működési problémák megoldására konténerek és mikroszolgáltatások használatával. Úttörők a területen olyan cégek, mint a Lyft, a Netflix és a Twitter, amelyek stabil szolgáltatásokat nyújtanak felhasználók millióinak szerte a világon. (). A kevésbé igényes alkalmazásokhoz valószínűleg az egyszerűbb architektúrák is elegendőek.
Nem valószínű, hogy a Service Mesh architektúra valaha is meg fogja adni a választ az alkalmazások működésével és kézbesítésével kapcsolatos problémákra. Az építészek és a fejlesztők hatalmas szerszámarzenállal rendelkeznek, és ezek közül csak az egyik a kalapács, amelynek a sok feladat közül csak egyet kell megoldania - a szögek kalapálását. Például számos különböző modellt tartalmaz, amelyek a mikroszolgáltatások segítségével történő problémák megoldásának megközelítési módozatait kínálják.
A Service Mesh architektúrában egyesülő elemek, mint például az NGINX, a konténerek, a Kubernetes és a mikroszolgáltatások, mint építészeti megközelítés, ugyanolyan hatékonyak lehetnek a nem Service Mesh megvalósításokban. Például az Istio-t teljes szolgáltatásháló-architektúrának tervezték, de modularitása azt jelenti, hogy a fejlesztők csak azokat a technológiai összetevőket tudják kiválasztani és megvalósítani, amelyekre szükségük van. Ezt szem előtt tartva fontos a Service Mesh-koncepció világos megértése, még akkor is, ha nem biztos benne, hogy valaha is képes lesz teljes mértékben megvalósítani azt az alkalmazásában.
Forrás: will.com