Tere jälle! .. Kursuse alguse eel oleme valmistanud ette veel ühe kasuliku tõlke.
Service Mesh on konfigureeritav infrastruktuuri tase, millel on madal latentsus, ja see on vajalik suurte koguste võrguprotsesside suhete töötlemiseks rakendusliideste (API) vahel. Service Mesh tagab kiire, usaldusväärse ja turvalise suhtluse konteineriseeritud ja sageli ajutiste rakenduste infrastruktuuri teenuste vahel. Service Mesh pakub selliseid funktsioone nagu teenuste avastamine, koormuse tasakaalustamine, krüpteerimine, nähtavus, jälgitavus, autentimine ja autoriseerimine, samuti automaatse katkestamise mustri toetamine (circuit breaker).
Service Meshi rakendatakse tavaliselt, andes igale teenuse eksemplarile proxy eksemplari, mida nimetatakse Sidecar. käsitlevad teenuste vahelisi kommunikatsioone, jälgivad ja lahendavad turbeprobleeme, st kõike, mida saab eristada eraldi teenustest. Nii saavad arendajad kirjutada, hooldada ja hallata rakenduse koodi teenustes, samal ajal kui süsteemiadministraatorid saavad töötada Service Meshiga ja rakendust käivitada.
Google'i, IBM-i ja Lyfti Istio on hetkel kõige tuntum Service Mesh arhitektuur. Kubernetes, mis algselt arendati Google'is, on nüüd ainus konteinerite orkestreerimise raamistik, mida Istio toetab. Tarnijad püüavad luua kaubanduslikult toetatud variante Istio'ist. Huvi pakub, mida uut nad suudavad avatud lähtekoodiga projektile tuua.
Kuid Istio ei ole ainus võimalus, sest arendatakse ka muid Service Mesh'i teostusi. Muster sidecar proxy on üks populaarsemaid teostusi, nagu näitab projektide Buoyant, HashiCorp, Solo.io ja teiste puhul. On ka alternatiivseid arhitektuure: Netflixi tehnoloogiline tööriistakomplekt on üks lähenemistest, kus Service Meshi funktsionaalsust rakendatakse Ribbon, Hysterix, Eureka, Archaius raamatukogude ja selliste platvormide nagu Azure Service Fabric abil.
Service Mesh'il on ka oma terminoloogia teenuste ja funktsioonide komponentide jaoks:
- Konteinerite orkestreerimise raamistik. Kui järjest rohkem konteineri lisandub rakenduse infrastruktuuri, tekib vajadus eraldi tööriista järele konteinerite jälgimiseks ja haldamiseks – konteinerite orkestreerimise raamistik. Kubernetes on selles valdkonnas tihedalt sisse seatud, nii palju, et isegi selle peamised konkurendid Docker Swarm ja Mesosphere DC/OS pakuvad alternatiivina integreerimist Kubernetesega.
- Teenused ja instantsid (Kubernetes pod'id). Näidis on ainus käivitatud mikroteenus. Mõnikord on üks näidis üks konteiner. Kuberneteses koosneb näidis väikesest sõltumatute konteinerite rühmast, mida nimetatakse podiks. Klientide harva pöördub otse näidise või podi poole, pigem pöördutakse teenuse poole, mis esindab mitmeid identsed skaleeritavaid ja tõrketaluvate näidiseid või pode (replikaid).
- Sidecar Proxy. Sidecar Proxy töötab ühe näidise või podiga. Sidecar Proxy mõte on suunata või proksida liiklust, mis tuleb konteinerilt, millega ta töötab, ning tagasiliiklust. Sidecar suhtleb teiste Sidecar Proxy'dega ja neid haldab orkestreerimise raamistik. Paljud teenuse mehhanismi rakendused kasutavad Sidecar Proxy'd, et haarata ja hallata kogu näidise või podi sisenemist ja väljuvat liiklust.
- Teenuste avastamine. Kui instants peab suhtlema teise teenusega, peab see leidma (tuvastama) töökindla ja kergesti ligipääsetava instantsi teisest teenusest. Tüüpiliselt otsib instants DNS-i kaudu. Kahnide orkestreerimise raamistik hoiab nimekirja instantsidest, mis on valmis päringute vastuvõtmiseks, ning pakub liidese DNS-päringute tegemiseks.
- Koormuse jaotamine. Enamik konteinerite orkestreerimisraamistikke tagavad koormuse jaotamise 4. tasemel (transpordi tasemel). Teenuste võrgustik rakendab keerukamat koormuse jaotamist 7. tasemel (rakenduse tasemel), mis on rikas algoritmide poolest ja efektiivsem liikluse haldamise osas. Koormuse jaotamise parameetreid saab muuta API kaudu, mis võimaldab orkestreerida sinise-roheline või kanarbiku juurutamist.
- Krüpteerimine. Service Mesh võib krüpteerida ja dekrüpteerida päringud ja vastused, vabastades selle koorma teenustest. Service Mesh võib samuti parandada jõudlust, eelistades või taaskasutades olemasolevaid püsivaid ühendusi, mis vähendab vajadust kulukate arvutuste järele uute ühenduste loomisel. Kõige levinum krüptimise teostus on omavaheline TLS (mTLS), kus avalike võtmete infrastruktuur (PKI) genereerib ja jagab sertifikaate ja võtit nende kasutamiseks Sidecar Proxy's.
- Autentimine ja autoriseerimine. Service Mesh võib autoriseerida ja autentida päringud, mis tehakse väljastpoolt või seestpoolt rakendust, edastades instantsidele vaid valideeritud päringud.
- Toetab automaatse väljalülitamise mustrit. Service Mesh toetab , mis isoleerib haiged instantsid ja seejärel järk-järgult tagastab need tervete instantside gruppi vajadusel.
Rakenduse Service Mesh osa, mis haldab võrgu liiklust instantside vahel, nimetatakse Andmeplaneet. Konfiguratsiooni loomine ja juurutamine, mis haldab käitumist Andmeplaneet, teostatud eraldi Kontrolli küngas. Kontrolli küngas tavaliselt hõlmab või on kavandatud ühenduma API, CLI või GUI kaudu rakenduse haldamiseks.
Control Plane Service Meshis jagab konfiguratsiooni Sidecar Proxy ja Data Plane'i vahel.
Service Meshi arhitektuur on tihti kasutusel keerukate operatiivsete ülesannete lahendamiseks, kasutades konteinerite ja mikroteenuste arhitektuuri. Valdkonna pioneerideks on sellised ettevõtted nagu Lyft, Netflix ja Twitter, kes pakuvad stabiilselt toimivaid teenuseid miljonitele kasutajatele üle kogu maailma. (). Vähem nõudlike rakenduste puhul piisab tõenäoliselt lihtsamast arhitektuurist.
Service Meshi arhitektuur ei ole tõenäoliselt kunagi vastus kõigile rakenduste töö ja tarnimisega seotud küsimustele. Arhitektidel ja arendajatel on suur tööriistade arsenal, ja ainult üks neist — haamer, mis peab mitme ülesande seas lahendama vaid ühte — naelu kokku lööma. , näiteks sisaldab see mitmeid erinevaid mudeleid, mis pakuvad pidevat lähenemisviisi probleemide lahendamiseks mikroteenuste kaudu.
Service Mesh arhitektuuris ühendatud elemendid, nagu NGINX, konteinerid, Kubernetes ja mikroteenused arhitektuurilise lähenemisviisina, võivad olla vähemalt sama tõhusalt kasutatud ka rakendustes, kus Service Mesh ei ole. Näiteks on Istio loodud täieliku Service Mesh arhitektuurina, kuid moodulsus näitab, et arendajad saavad valida ja rakendada ainult neid tehnoloogia komponente, mida nad vajavad. Peame meeles pidama, et Service Mesh kontseptsioonist on selge arusaamine vajalik, isegi kui te pole kindel, et suudate seda kunagi oma rakenduses täielikult rakendada.
Allikas: habr.com
