Jegyzet. ford.: A szervizhálók határozottan felkapott témává váltak a mikroszolgáltatási architektúrát követő alkalmazások mai infrastruktúrájában. Noha az Istio sok DevOps mérnök látókörébe kerül, egy meglehetősen új termékről van szó, amelynek megismerése, bár a nyújtott funkciókat tekintve összetett, jelentős időt vehet igénybe. A német mérnök, Rinor Maloku, aki az Orange Networks távközlési vállalat nagyügyfeleinek felhőalapú számítástechnikájáért felelős, egy csodálatos anyagsorozatot írt, amely lehetővé teszi, hogy gyorsan és mélyre merüljön az Istioban. Történetét azzal kezdi, hogy Istio mire képes, és hogyan láthatja ezt gyorsan a saját szemével.
Azonos — Nyílt forráskódú projekt, amelyet a Google, az IBM és a Lyft csapataival együttműködésben fejlesztettek ki. Megoldja a mikroszolgáltatásokon alapuló alkalmazásokban felmerülő bonyolultságokat, például:
- forgalomirányítás: időtúllépések, újrapróbálkozások, terheléselosztás;
- biztonság: végfelhasználói hitelesítés és engedélyezés;
- megfigyelhetőség: nyomkövetés, megfigyelés, naplózás.
Mindegyik alkalmazás szinten megoldható, utána azonban már nem lesznek "mikro" szolgáltatásai. Az ezeknek a problémáknak a megoldására irányuló minden extra erőfeszítés a vállalati erőforrások pazarlása, amelyeket közvetlenül üzleti értékként lehetne felhasználni. Vegyünk egy példát:
Projektmenedzser: Mennyi ideig tart egy visszajelzési funkció hozzáadása?
Fejlesztő: Két sprint.MP: Micsoda?.. Ez csak NAGY!
R: A CRUD végrehajtása a feladat egyszerű része, de továbbra is hitelesítenünk és engedélyeznünk kell a felhasználókat és a szolgáltatásokat. Mivel a hálózat nem megbízható, ismételt kéréseket kell végrehajtania, valamint az ügyfelekben. Továbbá, hogy megbizonyosodjon arról, hogy az egész rendszer nem omlott össze, időtúllépések és (A két említett mintáról bővebben a cikk későbbi részében olvashat.), valamint a problémák felderítése érdekében monitorozás, nyomon követés, […]MP: Ó, akkor tegyük be ezt a funkciót a Termékszolgáltatásba.
Azt hiszem, az ötlet egyértelmű: hatalmas lépések és erőfeszítések szükségesek egyetlen szolgáltatás hozzáadásához. Ebben a cikkben megnézzük, hogyan távolítja el az Istio a fent említett (az üzleti logika által nem célzott) összes bonyolultságot a szolgáltatásokból.
Megjegyzés: A cikk feltételezi, hogy rendelkezik a Kubernetes gyakorlati ismereteivel. Ellenkező esetben ajánlom elolvasásra és csak ezután folytassa ennek az anyagnak az olvasását.
Istio ötlet
Egy Istio nélküli világban az egyik szolgáltatás közvetlen kéréseket küld a másiknak, és hiba esetén a szolgáltatásnak magának kell kezelnie: új kísérletet kell tennie, időtúllépést kell biztosítania, megszakítót nyitnia stb.
Hálózati forgalom a Kubernetesben
Az Istio ezzel szemben egy speciális megoldást kínál, amely teljesen elkülönül a szolgáltatásoktól és funkcióktól azáltal, hogy zavarja a hálózati interakciót. És így valósítja meg:
- hibatűrés: a válaszban szereplő állapotkód alapján megérti, ha a kérés sikertelen volt, és újra elküldi.
- Canary Rollouts: a kéréseknek csak egy meghatározott százalékát irányítja át a szolgáltatás új verziójára.
- Monitoring és mérőszámok: mennyi időbe telt, mire a szolgáltatás válaszolt?
- Nyomon követés és megfigyelhetőség: Speciális fejléceket ad hozzá minden kéréshez, és nyomon követi őket a fürtön keresztül.
- biztonság: Lekér egy JWT tokent, hitelesíti és engedélyezi a felhasználókat.
Ez csak néhány lehetőség (valójában csak néhány!), hogy felkeltse az érdeklődésed. Most merüljünk el a technikai részletekben!
Építészet
Az Istio elfogja az összes hálózati forgalmat, és szabályokat alkalmaz rá, minden egyes podba egy oldalkocsis konténer formájában intelligens proxyt illesztve. Az összes lehetőséget aktiváló proxy a Adat sík, és ezek segítségével dinamikusan állíthatók Irányító sík.
Adat sík
A podokba behelyezett proxyk lehetővé teszik az Istio számára, hogy könnyedén teljesítse a szükséges követelményeket. Például ellenőrizzük az újrapróbálkozásokat és a megszakító funkciókat.
Az újrapróbálkozások és az áramkör-megszakítás megvalósítása az Envoy-ban
Összefoglalva:
- Követ (egy oldalkocsis konténerben elhelyezett proxyról beszélünk, ami és hogyan kerül elosztásra - kb. fordítás.) kérést küld a B szolgáltatás első példányának, és meghiúsul.
- Envoy Sidecar újra próbálkozik (próbálja újra). (1)
- A sikertelen kérés visszakerül az azt hívó proxyhoz.
- Ez megnyitja a Circuit Breaker-t, és felhívja a következő szolgáltatást a további kérésekhez. (2)
Ez azt jelenti, hogy nem kell használnia a következő Retry könyvtárat, nem kell saját maga implementálnia a Circuit Breaking and Service Discovery-t X, Y vagy Z programozási nyelven. Mindez és még sok más elérhető a doboz Istioban, és nem igényel bármilyen kód megváltozik.
Nagy! Most lehet, hogy szeretne kirándulni Istioval, de még mindig vannak kétségek, nyitott kérdések. Ha ez egy univerzális megoldás az élet minden alkalomra, akkor jogos a gyanúja: elvégre minden ilyen megoldás nem alkalmas semmilyen esetre.
És végül megkérdezi: "Testreszabható?"
Most már készen áll egy tengeri utazásra – és ismerkedjünk meg a Control Plane-el.
Irányító sík
Három összetevőből áll: Pilóta, Keverő и Fellegvár, amelyek együttesen konfigurálják a Küldötteket a forgalom irányítására, házirendek alkalmazására és telemetriai adatok gyűjtésére. Sematikusan az egész így néz ki:
A vezérlősík és az adatsík kölcsönhatása
A küldöttek (azaz adatsík) a következővel vannak konfigurálva (Egyéni erőforrás-meghatározások) az Istio által meghatározott és kifejezetten erre a célra tervezett. Ez azt jelenti számodra, hogy ezek csak egy másik erőforrás a Kubernetesben, ismerős szintaxissal. A létrehozás után ezt az erőforrást felveszi a vezérlősík, és alkalmazza a Küldöttekre.
A szolgáltatások kapcsolata Istióval
Leírtuk az Istio szolgáltatásokhoz való viszonyát, de nem fordítva: hogyan viszonyulnak a szolgáltatások az Istióhoz?
Őszintén szólva, a szolgálatok éppúgy tudnak Istio jelenlétéről, mint a halak a vízről, amikor felteszik maguknak a kérdést: „Mégis mi a víz?”.
ábra : Hogy tetszik a víz? - Amúgy mi az a víz?
Így vehetsz egy működő fürtöt, és az Istio komponensek telepítése után a benne lévő szolgáltatások tovább működnek, és ezen összetevők eltávolítása után minden újra rendben lesz. Nyilvánvaló, hogy ebben az esetben elveszíti az Istio nyújtotta lehetőségeket.
Elég az elméletből – ültessük át ezt a tudást a gyakorlatba!
Istio a gyakorlatban
Az Istiohoz Kubernetes-fürtre van szükség, legalább 4 vCPU-val és 8 GB RAM-mal. A fürt gyors emeléséhez és a cikkben található utasítások követéséhez javaslom a Google Cloud Platform használatát, amely új felhasználókat kínál .
A fürt létrehozása és a Kuberneteshez való hozzáférés beállítása után a konzolsegédprogramon keresztül telepítheti az Istio-t a Helm csomagkezelőn keresztül.
Sisak beszerelés
Telepítse a Helm klienst a számítógépére a leírás szerint . A következő részben sablonok létrehozására fogjuk használni az Istio telepítéséhez.
Telepítés
Töltse le az Istio forrásait innen (az eredeti szerző linkje az 1.0.5-ös verzióra módosult a jelenlegire, azaz 1.0.6-ra – kb. fordítás.), bontsa ki a tartalmat egyetlen könyvtárba, amelyre így fogok hivatkozni [istio-resources].
Az Istio-erőforrások egyszerű azonosítása érdekében hozzon létre egy névteret a K8s-fürtben istio-system:
$ kubectl create namespace istio-system
Fejezze be a telepítést a könyvtárba navigálással [istio-resources] és futtassa a parancsot:
$ helm template install/kubernetes/helm/istio
--set global.mtls.enabled=false
--set tracing.enabled=true
--set kiali.enabled=true
--set grafana.enabled=true
--namespace istio-system > istio.yaml
Ez a parancs az Istio kulcsfontosságú összetevőit egy fájlba írja ki istio.yaml. A standard sablont saját magunknak módosítottuk a következő paraméterek megadásával:
-
global.mtls.enabledbeépítvefalse(azaz az mTLS hitelesítés le van tiltva – kb. fordítás.)randevúzási folyamatunk egyszerűsítésére; -
tracing.enabledlehetővé teszi a kérések nyomon követését a Jaegerrel; -
kiali.enableda Kialit egy klaszterbe telepíti a szolgáltatások és a forgalom megjelenítéséhez; -
grafana.enabledtelepíti a Grafanát az összegyűjtött mutatók megjelenítéséhez.
Alkalmazza a generált erőforrásokat a következő paranccsal:
$ kubectl apply -f istio.yaml
Az Istio telepítése a fürtben befejeződött! Várja meg, amíg a névtérben található összes sor istio-system képes lesz arra Running vagy Completedaz alábbi parancs futtatásával:
$ kubectl get pods -n istio-systemMost készen állunk arra, hogy folytassuk a következő részre, ahol felhozzuk és futtatjuk az alkalmazást.
Sentiment Analysis Application Architecture
Használjuk a már említettekben használt Sentiment Analysis mikroszolgáltatási alkalmazás példáját . Elég összetett ahhoz, hogy a gyakorlatban is megmutassa az Istio lehetőségeit.
Az alkalmazás négy mikroszolgáltatásból áll:
- Szolgáltatás SA-Frontend, amely a Reactjs előtér-alkalmazását szolgálja ki;
- Szolgáltatás SA Web App, amely hangulatelemzési lekérdezéseket szolgál ki;
- Szolgáltatás SA Logicamely teljesíti magát ;
- Szolgáltatás SA Visszajelzés, amely visszajelzést kap a felhasználóktól az elvégzett elemzés pontosságáról.
Ezen a diagramon a szolgáltatások mellett a Belépés-vezérlőt is látjuk, amely Kubernetesben a bejövő kéréseket a megfelelő szolgáltatásokhoz irányítja. Az Istio hasonló koncepciót használ az Ingress Gateway részeként, ennek részletei a továbbiakban.
Alkalmazás indítása az Istio proxyjával
A cikkben említett további műveletekhez klónozza a tárat . Tartalmazza a Kubernetes és az Istio alkalmazását és manifesztjeit.
Oldalkocsik behelyezése
A beillesztés elvégezhető automatikusan vagy kézzel. Az oldalkocsis tárolók automatikus beillesztéséhez be kell állítania a címkét a névtérre istio-injection=enabled, amely a következő paranccsal történik:
$ kubectl label namespace default istio-injection=enabled
namespace/default labeled
Most minden egyes pod, amely az alapértelmezett névtérben lesz telepítve (default) kapja meg oldalkocsis konténerét. Ennek ellenőrzéséhez telepítsünk egy tesztalkalmazást a lerakat gyökérkönyvtárába lépve [istio-mastery] és futtassa a következő parancsot:
$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created
A szolgáltatások üzembe helyezése után a parancs futtatásával ellenőrizze, hogy a podoknak van-e két-két tárolója (magával a szolgáltatással és oldalkocsijával) kubectl get pods és ügyelve arra, hogy az oszlop alatt READY meghatározott értéket 2/2, ami azt jelzi, hogy mindkét tároló fut:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
sa-feedback-55f5dc4d9c-c9wfv 2/2 Running 0 12m
sa-frontend-558f8986-hhkj9 2/2 Running 0 12m
sa-logic-568498cb4d-2sjwj 2/2 Running 0 12m
sa-logic-568498cb4d-p4f8c 2/2 Running 0 12m
sa-web-app-599cf47c7c-s7cvd 2/2 Running 0 12mVizuálisan így néz ki:
Envoy proxy az egyik podban
Most, hogy az alkalmazás működik, engedélyeznünk kell a bejövő forgalom belépését az alkalmazásba.
Ingress Gateway
Ennek eléréséhez (forgalom engedélyezése a fürtben) a legjobb módszer a következőn keresztül Ingress Gateway az Istio-ban, amely a fürt „szélén” található, és lehetővé teszi az Istio olyan funkcióinak engedélyezését, mint az útválasztás, a terheléselosztás, a biztonság és a bejövő forgalom figyelése.
Az Ingress Gateway összetevő és az azt kifelé továbbító szolgáltatás az Istio telepítése során került a fürtre. Egy szolgáltatás külső IP-címének megtudásához futtassa:
$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME TYPE CLUSTER-IP EXTERNAL-IP
istio-ingressgateway LoadBalancer 10.0.132.127 13.93.30.120Továbbra is ezen az IP-n keresztül fogjuk elérni az alkalmazást (KÜLSŐ IP-címen fogom hivatkozni), ezért a kényelem kedvéért az értéket egy változóba írjuk:
$ EXTERNAL_IP=$(kubectl get svc -n istio-system
-l app=istio-ingressgateway
-o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')Ha most megpróbálja elérni ezt az IP-t egy böngészőn keresztül, akkor a Szolgáltatás elérhetetlen hibaüzenet jelenik meg, mert alapértelmezés szerint az Istio blokkolja az összes bejövő forgalmatamíg meg nem határozzák az átjárót.
Átjáró erőforrás
Az átjáró egy CRD (Custom Resource Definition) a Kubernetesben, amelyet az Istio fürtbe történő telepítése után határoznak meg, és lehetővé teszi a portok, protokollok és gazdagépek megadását, amelyekhez engedélyezni akarjuk a bejövő forgalmat.
Esetünkben minden gazdagép számára engedélyezni akarjuk a HTTP-forgalmat a 80-as porton. A probléma a következő definícióval valósul meg ():
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: http-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
Ez a konfiguráció nem szorul magyarázatra, kivéve a választót istio: ingressgateway. Ezzel a választóval megadhatjuk, hogy melyik Belépési átjáróra alkalmazzuk a konfigurációt. Esetünkben ez az Ingress Gateway vezérlő, amely alapértelmezés szerint telepítve volt az Istióban.
A konfiguráció a következő parancs meghívásával kerül alkalmazásra:
$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway createdAz átjáró most lehetővé teszi a hozzáférést a 80-as porthoz, de fogalma sincs, hová irányítsa a kéréseket. Ehhez szüksége lesz Virtuális szolgáltatások.
Virtuális szolgáltatás erőforrás
A VirtualService megmondja a Belépési átjárónak, hogyan irányítsa a fürtön belül engedélyezett kéréseket.
Az alkalmazásunkhoz a http-gateway-n keresztül érkező kéréseket az sa-frontend, sa-web-app és sa-feedback szolgáltatásokhoz kell eljuttatni:
A VirtualServices szolgáltatással konfigurálandó útvonalak
Fontolja meg azokat a kéréseket, amelyeket el kell küldeni az SA-Frontendnek:
- Pontos meccs az úton
/el kell küldeni az SA-Frontendnek, hogy megkapja az index.html-t; - Útvonalak előtaggal
/static/*el kell küldeni az SA-Frontendnek, hogy megkapja a frontendben használt statikus fájlokat, mint például a CSS és a JavaScript; - A reguláris kifejezésnek megfelelő utak
'^.*.(ico|png|jpg)$', SA-Frontendnek kell küldeni, mert Ezek az oldalon megjelenő képek.
A megvalósítás a következő konfigurációval érhető el ():
kind: VirtualService
metadata:
name: sa-external-services
spec:
hosts:
- "*"
gateways:
- http-gateway # 1
http:
- match:
- uri:
exact: /
- uri:
exact: /callback
- uri:
prefix: /static
- uri:
regex: '^.*.(ico|png|jpg)$'
route:
- destination:
host: sa-frontend # 2
port:
number: 80Fontos pontok:
- Ez a virtuális szolgáltatás a beérkező kérésekre vonatkozik http-átjáró;
- В
destinationmeghatározza azt a szolgáltatást, amelyhez a kéréseket küldik.
Megjegyzés: A fenti konfiguráció egy fájlban van tárolva sa-virtualservice-external.yaml, amely az SA-WebApp és az SA-Feedback útválasztási beállításait is tartalmazza, de itt a cikkben lerövidítettük a rövidség kedvéért.
Jelentkezzen a VirtualService telefonszámon:
$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services createdMegjegyzés: Amikor Istio-erőforrásokat alkalmazunk, a Kubernetes API-kiszolgáló aktivál egy eseményt, amelyet az Istio vezérlősík kap, majd ezt követően az új konfigurációt alkalmazza minden egyes pod Envoy proxyjára. És úgy tűnik, hogy az Ingress Gateway vezérlő egy másik, a Vezérlősíkon konfigurált Envoy. Mindez így néz ki a diagramon:
Istio-IngressGateway konfiguráció a kérés útválasztásához
A hangulatelemzés már elérhető itt: http://{EXTERNAL-IP}/. Ne aggódjon, ha a Nem található állapotot kapja: néha egy kicsit tovább tart, amíg a konfiguráció életbe lép, és az Envoy gyorsítótárak frissülnek.
Mielőtt folytatná, játsszon egy kicsit az alkalmazással, hogy forgalmat generáljon (jelenléte szükséges az egyértelműség érdekében a következő műveleteknél - kb. ford.).
Kiali: megfigyelhetőség
A Kiali adminisztrációs felület eléréséhez futtassa a következő parancsot:
$ kubectl port-forward
$(kubectl get pod -n istio-system -l app=kiali
-o jsonpath='{.items[0].metadata.name}')
-n istio-system 20001…és kinyitni admin/adminként bejelentkezve. Itt számos hasznos funkciót találhat, például az Istio komponensek konfigurációjának ellenőrzéséhez, a szolgáltatások megjelenítéséhez a hálózati kérések lehallgatásával gyűjtött információkból, választ kaphat a „Ki kivel lép kapcsolatba?”, „A szolgáltatás melyik verziója tapasztalható” kérdésekre. kudarcok?” stb. Általában fedezze fel a Kiali lehetőségeit, mielőtt a metrikák Grafana segítségével történő megjelenítéséhez kezdene.
Grafana: metrikák megjelenítése
Az Istio-ban összegyűjtött mutatók a Prometheusba kerülnek, és a Grafana segítségével jelenítik meg őket. A Grafana adminisztrációs felületének eléréséhez futtassa az alábbi parancsot, majd nyissa meg :
$ kubectl -n istio-system port-forward
$(kubectl -n istio-system get pod -l app=grafana
-o jsonpath={.items[0].metadata.name}) 3000A menüre kattintva Kezdőlap bal felső sarokban, és válassza ki Istio Service Dashboard a bal felső sarokban kezdje a szervizzel sa-web-appaz összegyűjtött mutatók megtekintéséhez:
Itt egy üres és teljesen unalmas előadásra várunk - a vezetőség ezt soha nem fogja helyeselni. Hozzunk létre egy kis terhelést a következő paranccsal:
$ while true; do
curl -i http://$EXTERNAL_IP/sentiment
-H "Content-type: application/json"
-d '{"sentence": "I love yogobella"}';
sleep .8; doneMost sokkal szebb grafikonok állnak rendelkezésünkre, és rajtuk kívül a csodálatos Prometheus monitorozási és Grafana a mérőszámok megjelenítéséhez, amelyek segítségével megismerhetjük a teljesítményt, az egészségi állapotot, a szolgáltatások fejlődését/romlását az idő múlásával.
Végül nézzük a kérések nyomon követését a szolgáltatásokban.
Jaeger: nyomkövetés
Szükségünk lesz a nyomon követésre, mert minél több szolgáltatásunk van, annál nehezebb a hiba okához eljutni. Nézzünk egy egyszerű esetet az alábbi képről:
Tipikus példa egy véletlenszerű sikertelen kérésre
Jön a kérés, esik - mi az ok? Első szervíz? Vagy második? Mindkettőben vannak kivételek – nézzük meg mindegyik naplóját. Milyen gyakran kaptad magad ezen? A mi munkánk inkább szoftvernyomozók, mint fejlesztők…
Ez egy elterjedt probléma a mikroszolgáltatásokban, és elosztott nyomkövetési rendszerekkel oldják meg, amelyekben a szolgáltatások egyedi fejlécet adnak át egymásnak, majd ezt az információt átirányítják a nyomkövető rendszerbe, ahol összehasonlítják a kérési adatokkal. Íme egy illusztráció:
A TraceId a kérés azonosítására szolgál
Az Istio a Jaeger Tracert használja, amely a gyártótól független OpenTracing API keretrendszert valósítja meg. A Jaeger felhasználói felületet a következő paranccsal érheti el:
$ kubectl port-forward -n istio-system
$(kubectl get pod -n istio-system -l app=jaeger
-o jsonpath='{.items[0].metadata.name}') 16686Most menjen ide és válasszon egy szolgáltatást sa-web-app. Ha a szolgáltatás nem jelenik meg a legördülő menüben, mutasson/generáljon tevékenységet az oldalon, és frissítse a felületet. Ezt követően kattintson a gombra Nyomokat találni, amely a legfrissebb nyomokat mutatja - válasszon bármilyen - részletes információk jelennek meg az összes nyomról:
Ez a nyom mutatja:
- Bejön a kérés istio-belépési átjáró (ez az első interakció az egyik szolgáltatással, és egy nyomkövetési azonosító generálódik a kéréshez), amely után az átjáró elküldi a kérést a szolgáltatásnak sa-web-app.
- Szolgálatban sa-web-app a kérést az Envoy oldalkocsi felveszi, a spanban létrehoz egy "gyermeket" (ezért látjuk nyomokban) és átirányítja a konténerbe sa-web-app. ( - egy logikai munkaegység a Jaegerben, amelynek neve, a művelet kezdési időpontja és időtartama van. A fesztávok egymásba ágyazhatók és rendezhetők. Az ívek irányított aciklikus gráfja nyomvonalat alkot. - kb. fordítás.)
- Itt a kérés feldolgozása a metódus szerint történik érzelemelemzés. Ezeket a nyomokat már az alkalmazás generálja, pl. kódmódosítást igényeltek.
- Ettől a pillanattól kezdve a POST kérés elindul sa-logika. A nyomkövetési azonosítót innen kell továbbítani sa-web-app.
- ...
Megjegyzés: A 4. lépésben az alkalmazásnak látnia kell az Istio által generált fejléceket, és át kell adnia azokat a következő kéréseknek, amint az az alábbi képen látható:
(A) A fejléc továbbítása az Istio feladata; (B) A szolgáltatások felelősek a fejlécekért
Istio elvégzi a munka nagy részét, mert fejléceket generál a bejövő kérésekhez, új spanokat hoz létre minden egyes mellékszolgáltatásban, és továbbítja azokat. A szolgáltatásokon belüli fejlécekkel való munka nélkül azonban a teljes kérés nyomkövetési útvonala elvész.
A következő fejléceket kell figyelembe venni (továbbítani):
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-contextEz egy egyszerű feladat, de a végrehajtás egyszerűsítése érdekében már van - például az sa-web-app szolgáltatásban a RestTemplate kliens továbbítja ezeket a fejléceket, ha egyszerűen hozzáadja a Jaeger és az OpenTracing könyvtárakat .
Vegye figyelembe, hogy a Sentiment Analysis alkalmazás bemutatja a Flask, Spring és ASP.NET Core implementációit.
Most, hogy világossá vált, mit hozunk ki a dobozból (vagy majdnem ki a dobozból), nézzük meg a finomhangolást az útválasztást, a hálózati forgalomkezelést, a biztonságot és még sok mást!
Jegyzet. ford.: erről olvashatsz Rinor Maloku Istio-ról szóló anyagainak következő részében, amelyek fordításai a közeljövőben követik majd a blogunkat. UPDATE (március 14.): már megjelent.
PS a fordítótól
Olvassa el blogunkon is:
- "Vissza a mikroszolgáltatásokhoz az Istióval": , ;
- «";
- «";
- «";
- «".
Forrás: will.com