Huomautus. käännös: Palveluverkoista on ehdottomasti tullut kuuma aihe nykypäivän infrastruktuurissa mikropalveluarkkitehtuuria seuraaville sovelluksille. Vaikka Istio saattaa olla monien DevOps-insinöörien tutkassa, se on melko uusi tuote, johon tutustuminen voi viedä huomattavan paljon aikaa, vaikka se onkin monimutkainen ominaisuuksiltaan. Saksalainen insinööri Rinor Maloku, joka vastaa tietoliikenneyhtiö Orange Networksin suurasiakkaiden pilvipalveluista, on kirjoittanut upean materiaalisarjan, jonka avulla pääset nopeasti ja syvälle Istioon. Hän aloittaa tarinansa siitä, mitä Istio voi tehdä ja kuinka voit nähdä sen nopeasti omin silmin.
Sama — Open Source -projekti, kehitetty yhteistyössä Googlen, IBM:n ja Lyftin tiimien kanssa. Se ratkaisee monimutkaiset ongelmat, joita syntyy esimerkiksi mikropalveluihin perustuvissa sovelluksissa, kuten:
- liikenteen hallinta: aikakatkaisut, uudelleenyritykset, kuormituksen tasapainotus;
- Безопасность: loppukäyttäjän todennus ja valtuutus;
- havaittavuus: jäljitys, seuranta, kirjaus.
Ne kaikki voidaan ratkaista sovellustasolla, mutta sen jälkeen palvelusi eivät ole enää "mikroja". Kaikki ylimääräinen ponnistelu näiden ongelmien ratkaisemiseksi on yrityksen resurssien tuhlausta, joka voitaisiin käyttää suoraan liiketoiminnan arvon tuottamiseen. Harkitse esimerkkiä:
Projektipäällikkö: Kuinka kauan palauteominaisuuden lisääminen kestää?
Kehittäjä: Kaksi sprinttiä.MP: Mitä?.. Se on vain RAAKAA!
V: CRUD:n tekeminen on helppo osa tehtävää, mutta meidän on silti tunnistettava ja valtuutettava käyttäjät ja palvelut. Koska verkko on epäluotettava, sinun on toteutettava toistuvia pyyntöjä sekä asiakkaissa. Varmista myös, että koko järjestelmä ei kaatunut, aikakatkaisut ja (Katso myöhemmin artikkelista lisätietoja molemmista mainituista malleista.)ja ongelmien havaitsemiseksi, seuranta, jäljitys, […]MP: Oi, laitetaan tämä ominaisuus sitten tuotepalveluun.
Mielestäni idea on selvä: yhden palvelun lisääminen vaatii valtavasti vaiheita ja vaivaa. Tässä artikkelissa tarkastellaan, kuinka Istio poistaa palveluista kaiken yllä mainitun monimutkaisuuden (joka ei kohdistu liiketoimintalogiikkaan).
Huomata: Artikkelissa oletetaan, että sinulla on toimivaa tietoa Kubernetesista. Muuten suosittelen lukemista ja vasta sitten jatka tämän materiaalin lukemista.
Istio idea
Maailmassa ilman Istiota palvelu tekee suoria pyyntöjä toiselle, ja vikatilanteessa palvelun tulee hoitaa se itse: tehdä uusi yritys, varata aikakatkaisu, avata katkaisija jne.
Verkkoliikenne Kubernetesissa
Istio puolestaan tarjoaa erikoisratkaisun, joka on täysin erillinen palveluista ja toiminnoista häiritsemällä verkkovuorovaikutusta. Ja näin se toteuttaa:
- vikasietoisuus: vastauksen tilakoodin perusteella se ymmärtää, jos pyyntö epäonnistui, ja lähettää sen uudelleen.
- Canary Rollouts: ohjaa vain kiinteän prosenttiosuuden pyynnöistä palvelun uuteen versioon.
- Valvonta ja mittarit: kuinka kauan kesti ennen kuin palvelu vastasi?
- Jäljitys ja havainnointi: Lisää erityiset otsikot jokaiseen pyyntöön ja jäljittää ne klusterin poikki.
- Безопасность: Hakee JWT-tunnuksen, todentaa ja valtuuttaa käyttäjät.
Nämä ovat vain muutamia mahdollisuuksista (todella vain muutama!) kiehtoa sinua. Sukellaan nyt teknisiin yksityiskohtiin!
Arkkitehtuuri
Istio sieppaa kaiken verkkoliikenteen ja soveltaa siihen sääntöjä lisäämällä jokaiseen koteloon sivuvaunukontin muodossa olevan älykkään välityspalvelimen. Välityspalvelimet, jotka aktivoivat kaikki mahdollisuudet, muodostavat a Datataso, ja niitä voidaan säätää dynaamisesti Ohjaustaso.
Datataso
Podeihin asennettavien välityspalvelinten avulla Istio pystyy helposti saavuttamaan tarvitsemamme vaatimukset. Tarkastetaan esimerkiksi uudelleenyritykset ja katkaisijatoiminnot.
Kuinka uudelleenyritykset ja piirikatkaisut toteutetaan Envoyssa
Yhteenvetona:
- Lähettiläs (puhumme sivuvaunukontissa sijaitsevasta välityspalvelimesta, jota jaetaan ja miten - noin käännös.) lähettää pyynnön palvelun B ensimmäiselle esiintymälle ja epäonnistuu.
- Envoy Sidecar yrittää uudelleen (yritä uudelleen). (1)
- Epäonnistunut pyyntö palautetaan sen kutsuneelle välityspalvelimelle.
- Tämä avaa katkaisijan ja kutsuu seuraavan palvelun myöhempiä pyyntöjä varten. (2)
Tämä tarkoittaa, että sinun ei tarvitse käyttää seuraavaa Retry-kirjastoa, sinun ei tarvitse tehdä omaa Circuit Breaking- ja Service Discovery -toteutusta X-, Y- tai Z-ohjelmointikielellä. Kaikki tämä ja paljon muuta on saatavilla laatikko Istiossa eikä vaadi kaikki koodin muutokset.
Loistava! Nyt saatat haluta lähteä matkalle Istion kanssa, mutta vielä on epäilyksiä, avoimia kysymyksiä. Jos tämä on universaali ratkaisu kaikkiin elämäntilanteisiin, sinulla on oikeutettu epäilys: loppujen lopuksi kaikki tällaiset ratkaisut eivät itse asiassa sovellu mihinkään tapaukseen.
Ja lopuksi kysyt: "Onko se muokattavissa?"
Nyt olet valmis merimatkalle - ja tutustutaan Control Planeen.
Ohjaustaso
Se koostuu kolmesta osasta: Lentäjä, Mikseri и Linnoitus, jotka yhdessä määrittävät lähettiläät reitittämään liikennettä, valvomaan käytäntöjä ja keräämään telemetriatietoja. Kaavamaisesti kaikki näyttää tältä:
Ohjaustason vuorovaikutus datatason kanssa
Lähettäjät (eli datataso) on konfiguroitu (Custom Resource Definitions), jotka Istio on määritellyt ja erityisesti suunniteltu tähän tarkoitukseen. Tämä tarkoittaa sinulle sitä, että ne ovat vain toinen resurssi Kubernetesissa, jolla on tuttu syntaksi. Kun tämä resurssi on luotu, ohjaustaso poimii sen ja käyttää sitä lähettiläissä.
Palvelujen suhde Istioon
Olemme kuvanneet Istion suhdetta palveluihin, mutta emme päinvastoin: miten palvelut liittyvät Istioon?
Rehellisesti sanottuna palvelut tietävät Istion olemassaolosta yhtä hyvin kuin kalat tietävät vedestä, kun he kysyvät itseltään: "Mitä vesi muuten on?".
kuva : Mitä pidät vedestä? - Mitä vesi muuten on?
Voit siis ottaa toimivan klusterin ja Istio-komponenttien käyttöönoton jälkeen siinä olevat palvelut jatkavat toimintaansa ja näiden komponenttien poistamisen jälkeen kaikki on taas kunnossa. On selvää, että tässä tapauksessa menetät Istion tarjoamat mahdollisuudet.
Tarpeeksi teoriaa - laitetaan tämä tieto käytäntöön!
Istio käytännössä
Istio vaatii Kubernetes-klusterin, jossa on vähintään 4 vCPU:ta ja 8 Gt RAM-muistia. Nostaaksesi klusterin nopeasti ja noudattaaksesi artikkelin ohjeita, suosittelen käyttämään Google Cloud Platformia, joka tarjoaa uusille käyttäjille .
Kun olet luonut klusterin ja määrittänyt pääsyn Kubernetesiin konsoliapuohjelman kautta, voit asentaa Istion Helm-pakettienhallinnan kautta.
Helmen asennus
Asenna Helm-asiakas tietokoneellesi kohdassa kuvatulla tavalla . Käytämme sitä luomaan malleja Istion asentamista varten seuraavassa osiossa.
Asennus
Lataa Istio-resurssit osoitteesta (alkuperäisen kirjoittajan linkki versioon 1.0.5 on muutettu nykyiseksi, eli 1.0.6 - noin käännös.), pura sisältö yhteen hakemistoon, jota kutsun nimellä [istio-resources].
Istio-resurssien tunnistamisen helpottamiseksi luo nimiavaruus K8s-klusteriin istio-system:
$ kubectl create namespace istio-system
Viimeistele asennus siirtymällä hakemistoon [istio-resources] ja suorita komento:
$ 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
Tämä komento tulostaa Istion avainkomponentit tiedostoon istio.yaml. Olemme muuttaneet standardimallia itsellemme määrittämällä seuraavat parametrit:
-
global.mtls.enabledasennettu sisäänfalse(eli mTLS-todennus on poistettu käytöstä - noin käännös)yksinkertaistaaksemme treffiprosessiamme; -
tracing.enabledmahdollistaa pyyntöjen jäljityksen Jaegerin avulla; -
kiali.enabledasentaa Kialin klusteriksi visualisoimaan palveluita ja liikennettä; -
grafana.enabledasentaa Grafanan visualisoidakseen kerätyt tiedot.
Käytä luotuja resursseja komennolla:
$ kubectl apply -f istio.yaml
Istion asennus klusteriin on valmis! Odota, kunnes kaikki nimiavaruuden palot istio-system pystyvät Running tai Completedsuorittamalla alla oleva komento:
$ kubectl get pods -n istio-systemOlemme nyt valmiita jatkamaan seuraavaan osioon, jossa nostamme ja suoritamme sovelluksen.
Sentimenttianalyysin sovellusarkkitehtuuri
Otetaan esimerkkinä jo mainitussa käytetty Sentiment Analysis -mikropalvelusovellus . Se on tarpeeksi monimutkainen näyttämään Istion mahdollisuudet käytännössä.
Sovellus koostuu neljästä mikropalvelusta:
- Työkalut SA-Etuosa, joka palvelee Reactjs:n käyttöliittymäsovellusta;
- Työkalut SA WebApp, joka palvelee tunneanalyysikyselyitä;
- Työkalut SA Logiikkajoka suorittaa itsensä ;
- Työkalut SA Palaute, joka saa käyttäjiltä palautetta suoritetun analyysin tarkkuudesta.
Tässä kaaviossa näkyy palveluiden lisäksi myös Ingress Controller, joka Kubernetesissa reitittää saapuvat pyynnöt vastaaviin palveluihin. Istio käyttää samanlaista konseptia osana Ingress Gatewayä, jonka yksityiskohdat tulevat myöhemmin.
Sovelluksen käynnistäminen välityspalvelimella Istiosta
Kloonaa arkistosi muita artikkelissa mainittuja toimintoja varten . Se sisältää sovelluksen ja manifestit Kubernetesille ja Istiolle.
Sivuvaunujen asennus
Lisäys voidaan tehdä automaattisesti tai käsin. Jos haluat lisätä sivuvaunusäiliöitä automaattisesti, sinun on määritettävä nimiavaruuden nimi istio-injection=enabled, joka tehdään seuraavalla komennolla:
$ kubectl label namespace default istio-injection=enabled
namespace/default labeled
Nyt jokainen pod, joka otetaan käyttöön oletusnimiavaruudessa (default) saa sivuvaunukonttinsa. Varmista tämä ottamalla käyttöön testisovellus menemällä arkiston juurihakemistoon [istio-mastery] ja suoritat seuraavan komennon:
$ 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
Kun palvelut on otettu käyttöön, tarkista, että koteloissa on kaksi konttia (itse palvelu ja sen sivuvaunu) suorittamalla komento kubectl get pods ja varmista, että sarakkeen alla READY määritetty arvo 2/2, joka symboloi, että molemmat säilöt ovat käynnissä:
$ 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 12mVisuaalisesti se näyttää tältä:
Envoy proxy jossakin kotelossa
Nyt kun sovellus on käynnissä, meidän on sallittava saapuvan liikenteen pääsy sovellukseen.
Ingress Gateway
Paras käytäntö tämän saavuttamiseksi (salli liikenne klusterissa) on läpimeno Ingress Gateway Istiossa, joka sijaitsee klusterin "reunassa" ja jonka avulla voit ottaa käyttöön Istion ominaisuuksia, kuten reitityksen, kuormituksen tasapainotuksen, suojauksen ja saapuvan liikenteen valvonnan.
Ingress Gateway -komponentti ja palvelu, joka välittää sen eteenpäin, asennettiin klusteriin Istion asennuksen yhteydessä. Voit selvittää palvelun ulkoisen IP-osoitteen suorittamalla:
$ 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.120Jatkamme sovelluksen käyttöä tällä IP-osoitteella (viittaan siihen nimellä EXTERNAL-IP), joten mukavuuden vuoksi kirjoitamme arvon muuttujaan:
$ EXTERNAL_IP=$(kubectl get svc -n istio-system
-l app=istio-ingressgateway
-o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')Jos yrität päästä tähän IP-osoitteeseen nyt selaimen kautta, saat Palvelu ei ole käytettävissä -virheen, koska oletuksena Istio estää kaiken saapuvan liikenteenkunnes yhdyskäytävä on määritetty.
Gateway-resurssi
Yhdyskäytävä on Kubernetesin CRD (Custom Resource Definition), joka määritellään sen jälkeen, kun Istio on asennettu klusteriin ja joka mahdollistaa mahdollisuuden määrittää portit, protokollat ja isännät, joille haluamme sallia tulevan liikenteen.
Meidän tapauksessamme haluamme sallia HTTP-liikenteen portissa 80 kaikille koneille. Ongelma ilmenee seuraavalla määritelmällä ():
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: http-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
Tämä kokoonpano ei vaadi selitystä paitsi valitsimen istio: ingressgateway. Tällä valitsimella voimme määrittää, mihin tuloyhdyskäytävään konfiguraatiota sovelletaan. Meidän tapauksessamme tämä on Ingress Gateway -ohjain, joka asennettiin oletuksena Istioon.
Kokoonpano otetaan käyttöön kutsumalla seuraava komento:
$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway createdYhdyskäytävä sallii nyt pääsyn porttiin 80, mutta sillä ei ole aavistustakaan, minne pyynnöt reititetään. Tätä varten tarvitset Virtuaalipalvelut.
Virtuaalipalvelun resurssi
VirtualService kertoo tuloyhdyskäytävälle, kuinka klusterin sisällä sallitut pyynnöt reititetään.
http-yhdyskäytävän kautta tulevat sovellukseemme pyynnöt tulee lähettää sa-frontend-, sa-web-app- ja sa-feedback-palveluihin:
VirtualServicesilla määritettävät reitit
Harkitse pyyntöjä, jotka tulisi lähettää SA-Frontendille:
- Tarkka ottelu matkan varrella
/tulee lähettää SA-Frontendille saadaksesi index.html; - Polut etuliitteellä
/static/*tulee lähettää SA-Frontendille saadakseen käyttöliittymässä käytetyt staattiset tiedostot, kuten CSS ja JavaScript; - Polut, jotka vastaavat säännöllistä lauseketta
'^.*.(ico|png|jpg)$', on lähetettävä SA-Frontendille, koska Nämä ovat sivulla näkyvät kuvat.
Toteutus saadaan aikaan seuraavalla konfiguraatiolla ():
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: 80Tärkeitä seikkoja:
- Tämä virtuaalipalvelu viittaa läpi tuleviin pyyntöihin http-yhdyskäytävä;
- В
destinationmäärittää palvelun, johon pyynnöt lähetetään.
Huomata: Yllä oleva kokoonpano on tallennettu tiedostoon sa-virtualservice-external.yaml, joka sisältää myös asetukset SA-WebAppiin ja SA-Feedbackiin reitittämistä varten, mutta sitä on lyhennetty tässä artikkelissa lyhennyksen vuoksi.
Hae Virtuaalipalvelua soittamalla:
$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services createdHuomata: Kun käytämme Istio-resursseja, Kubernetes API -palvelin käynnistää tapahtuman, jonka Istio Control Plane vastaanottaa, ja sen jälkeen uutta kokoonpanoa sovelletaan kunkin podin Envoy-välityspalvelimiin. Ja Ingress Gateway -ohjain näyttää olevan toinen ohjaustasoon konfiguroitu lähettiläs. Kaikki tämä näyttää kaaviossa tältä:
Istio-IngressGateway-konfiguraatio pyyntöjen reititystä varten
Tunneanalyysi on nyt saatavilla osoitteessa http://{EXTERNAL-IP}/. Älä huoli, jos saat Ei löydy -tilan: joskus kestää hieman kauemmin, ennen kuin asetukset tulevat voimaan ja Envoy-välimuistit päivittyvät.
Ennen kuin jatkat, pelaa vähän sovelluksella luodaksesi liikennettä (sen läsnäolo on välttämätöntä myöhempien toimien selkeyden vuoksi - noin käännös.).
Kiali: havaittavuus
Pääset Kialin järjestelmänvalvojan käyttöliittymään suorittamalla seuraava komento:
$ kubectl port-forward
$(kubectl get pod -n istio-system -l app=kiali
-o jsonpath='{.items[0].metadata.name}')
-n istio-system 20001…ja auki kirjautumalla sisään admin/admin. Täältä löydät monia hyödyllisiä ominaisuuksia, esimerkiksi Istio-komponenttien kokoonpanon tarkistamiseen, palveluiden visualisointiin verkkopyyntöjen sieppaamisen kautta kerätyistä tiedoista, vastauksia kysymyksiin "Kuka ottaa yhteyttä?", "Mikä versio palvelusta on käytössä epäonnistumisia?" ja niin edelleen. Yleisesti ottaen tutki Kialin mahdollisuuksia ennen kuin siirryt mittareiden visualisointiin Grafanalla.
Grafana: mittareiden visualisointi
Istioon kerätyt mittarit päätyvät Prometheukseen ja visualisoidaan Grafanalla. Pääset Grafana-järjestelmänvalvojan käyttöliittymään suorittamalla alla oleva komento ja avaamalla :
$ kubectl -n istio-system port-forward
$(kubectl -n istio-system get pod -l app=grafana
-o jsonpath={.items[0].metadata.name}) 3000Klikkaamalla valikkoa Koti vasemmassa yläkulmassa ja valitse Istio Service Dashboard aloita palvelusta vasemmassa yläkulmassa sa-web-sovellustarkastellaksesi kerättyjä mittareita:
Täällä odotamme tyhjää ja täysin tylsää esitystä - johto ei koskaan hyväksy tätä. Luodaan pieni kuorma seuraavalla komennolla:
$ while true; do
curl -i http://$EXTERNAL_IP/sentiment
-H "Content-type: application/json"
-d '{"sentence": "I love yogobella"}';
sleep .8; doneNyt meillä on paljon kauniimpia kaavioita ja niiden lisäksi upeita työkaluja Prometheus monitorointiin ja Grafana mittareiden visualisointiin, joiden avulla voimme oppia suorituskyvystä, terveydentilasta, palveluiden parannuksista / heikkenemisestä ajan myötä.
Lopuksi tarkastellaan pyyntöjen jäljitystä palveluissa.
Jaeger: jäljitys
Tarvitsemme jäljitystä, sillä mitä enemmän palveluita meillä on, sitä vaikeampaa on päästä käsiksi vian syytä. Katsotaanpa yksinkertaista tapausta alla olevasta kuvasta:
Tyypillinen esimerkki satunnaisesta epäonnistuneesta pyynnöstä
Pyyntö tulee, putoaa - mikä on syy? Ensimmäinen palvelu? Vai toiseksi? Molemmissa on poikkeuksia - katsotaanpa kummankin lokeja. Kuinka usein olet huomannut itsesi tekemästä tätä? Työmme on enemmänkin ohjelmistoetsiviä kuin kehittäjiä…
Tämä on laajalle levinnyt ongelma mikropalveluissa ja se ratkaistaan hajautetuilla jäljitysjärjestelmillä, joissa palvelut välittävät yksilöllisen otsikon toisilleen, minkä jälkeen tämä tieto ohjataan jäljitysjärjestelmään, jossa sitä verrataan pyyntötietoihin. Tässä on esimerkki:
TraceId-tunnusta käytetään pyynnön tunnistamiseen
Istio käyttää Jaeger Traceria, joka toteuttaa toimittajasta riippumattoman OpenTracing API -kehyksen. Pääset Jaeger-käyttöliittymään seuraavalla komennolla:
$ kubectl port-forward -n istio-system
$(kubectl get pod -n istio-system -l app=jaeger
-o jsonpath='{.items[0].metadata.name}') 16686Siirry nyt kohtaan ja valitse palvelu sa-web-sovellus. Jos palvelu ei näy avattavassa valikossa, näytä/luo sivun toiminta ja päivitä käyttöliittymä. Napsauta sen jälkeen painiketta Etsi jälkiä, joka näyttää viimeisimmät jäljet - valitse mikä tahansa - yksityiskohtaiset tiedot kaikista jäljistä tulevat näkyviin:
Tämä jälki näyttää:
- Pyyntö tulee sisään istio-ingressgateway (tämä on ensimmäinen vuorovaikutus jonkin palvelun kanssa ja pyynnölle luodaan jäljitystunnus), jonka jälkeen yhdyskäytävä lähettää pyynnön palveluun sa-web-sovellus.
- Palvelussa sa-web-sovellus Envoy-sivuvaunu poimii pyynnön, väliin luodaan "lapsi" (siksi näemme sen jälkinä) ja ohjataan konttiin sa-web-sovellus. ( - Jääkärin looginen työyksikkö, jolla on nimi, operaation alkamisaika ja kesto. Jännitteet voidaan sisäkkäin ja tilata. Suunnattu asyklinen jännekaavio muodostaa jäljen. - noin käännös.)
- Täällä pyyntö käsitellään menetelmällä sentimenttianalyysi. Nämä jäljet ovat jo sovelluksen luomia, ts. ne vaativat koodin muutoksia.
- Tästä hetkestä lähtien POST-pyyntö aloitetaan sisään sa-logiikkaa. Jäljitystunnus on välitettävä osoitteesta sa-web-sovellus.
- ...
Huomata: Vaiheessa 4 sovelluksen pitäisi nähdä Istion luomat otsikot ja välittää ne myöhemmille pyynnöille alla olevan kuvan mukaisesti:
(A) Otsikon välittäminen on Istion vastuulla; (B) Palvelut vastaavat otsikoista
Istio tekee suurimman osan työstä, koska luo otsikot saapuville pyynnöille, luo uusia jaksoja jokaiseen sivuhuoltoon ja välittää ne. Jos palveluissa ei kuitenkaan käsitellä otsikoita, koko pyynnön jäljityspolku menetetään.
Seuraavat otsikot on otettava huomioon (edelleen):
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-contextTämä on yksinkertainen tehtävä, mutta sen toteuttamisen yksinkertaistamiseksi se on jo olemassa - esimerkiksi sa-web-sovelluspalvelussa RestTemplate-asiakas lähettää nämä otsikot edelleen, jos lisäät vain Jaeger- ja OpenTracing-kirjastot .
Huomaa, että Sentiment Analysis -sovellus näyttää toteutukset Flaskissa, Springissä ja ASP.NET Coressa.
Nyt kun on selvää, mitä saamme laatikosta (tai melkein ulos laatikosta), katsotaanpa hienosäädettyä reititystä, verkkoliikenteen hallintaa, turvallisuutta ja paljon muuta!
Huomautus. käännös: lue tästä Rinor Malokun Istiota käsittelevien materiaalien seuraavassa osassa, jonka käännökset tulevat lähiaikoina blogiimme. PÄIVITYS (14. maaliskuuta): jo julkaistu.
PS kääntäjältä
Lue myös blogistamme:
- "Takaisin mikropalveluihin Istion kanssa": , ;
- «";
- «";
- «";
- «'.
Lähde: will.com