Tere jälle!.. Kursuse alguse eel oleme valmistanud veel ühe kasuliku tõlke.
Service Mesh on konfigureeritavad infrastruktuuri tasand madala latentsusega, mis on vajalik suure hulga võrgusiseste suhtluste töötlemiseks rakenduse programmeerimise liideste (API) vahel. Service Mesh tagab kiire, usaldusväärse ja turvalise suhtluse konteineriseeritud ja tihti ajutiste rakenduste teenuste vahel. Service Mesh pakub selliseid võimalusi nagu teenuste avastamine, koormuse tasakaalustamine, krüpteerimine, läbinägelikkus, jälgitavus, autentimine ja autoriseerimine ning automaatse lülitamise mallitoe (circuit breaker).
Service Meshi rakendamine toimub tavaliselt iga teenuse eksemplari jaoks proxy eksemplari, mida nimetatakse Sidecar. Sidecar haldab teenuste vahelisi suhtlusi, teostab jälgimist ja lahendab turbeprobleeme, see tähendab kõike, mis saab olla eraldatud üksikutest teenustest. Seeläbi saavad arendajad kirjutada, toetada ja hooldada rakenduse koodi teenustes, samas kui süsteemiadministraatorid saavad töötada Service Meshiga ja rakendada rakendust.
Google'i, IBM-i ja Lyft'i Istio on praegu kõige tuntum Service Meshi arhitektuur. Kubernetes, mis töötati esialgu välja Google'is, on nüüd ainus konteinerite orkestreerimise raamistik, mida Istio toetab. Tarnijad üritavad luua kommertstoetatud versioone Istio'st. On huvitav, mida uut nad saavad tuua avatud koodiga projekti.
Kuid Istio ei ole ainus variant, kuna arendatakse ka teisi Service Meshi teostusi. Mall sidecar proxy on kõige populaarsem teostus, nagu võib järeldada projektidest Buoyant, HashiCorp, Solo.io ja teised. Samuti on olemas alternatiivsed arhitektuurid: Netflixi tehnoloogiatööriistakomplekt on üks lähenemisviis, kus Service Meshi funktsionaalsust rakendatakse Ribboni, Hysterixi, Eureka, Archaiuse raamatukogude ja selliste platvormide nagu Azure Service Fabric kaudu.
Service Meshil on ka oma terminoloogia teenuste ja funktsioonide komponentide jaoks:
- Konteinerite orkestreerimise raamistik. Kui rakenduse infrastruktuuri lisandub üha rohkem konteinerit, tekib vajadus eraldi tööriista järele konteinerite jälgimiseks ja haldamiseks – konteinerite orkestreerimise raamistik. Kubernetes on selle niši kindlalt hõivanud, nii palju, et isegi selle peamised konkurendid, Docker Swarm ja Mesosphere DC/OS, pakuvad Kubernetese integreerimist alternatiivina.
- Teenused ja eksemplarid (Kubernetese podid). Eksemplar on üksik käivitatud koopia mikroteenusest. Mõnikord on üks eksemplar üks konteiner. Kuberneteses koosneb eksemplar väikese grupist iseseisvatest konteineritest, mida nimetatakse podiks. Klientid ei suunata harva otse eksemplarile või podile, vaid nad pöörduvad pigem teenuse poole, mis esindab identsete, skaleeritavate ja tõrketaluvate eksemplaride või podide (replikate) kogumit.
- Sidecar Proxy. Sidecar Proxy töötab ühe eksemplari või podiga. Sidecar Proxy mõte on suunata või proksida liiklust, mis tuleb konteinerist, millega ta töötleb, ja tagasiteed. Sidecar suhtleb teiste Sidecar Proxy'ga ja seda haldab orkestreerimise raamistik. Paljud teenuse mesh'i rakendused kasutavad Sidecar Proxy't, et haarata ja hallata kogu eksemplari või podi sisenemist ja väljaminevat liiklust.
- Teenuste avastamine. Kui eksemplaril on vaja suhelda teise teenusega, peab ta leidma (avastama) töötava ja kergesti ligipääsetava eksemplari teisest teenusest. Üldiselt otsib eksemplar DNS-i kaudu. Orkestreerimise raamistik hoiab nimekirja eksemplaridest, mis on valmis päringute vastu võtmiseks, ja pakub liidese DNS-päringute jaoks.
- Koormuse tasakaalustamine. Enamik konteinerite orkestreerimise raamistikke tagab 4. taseme (transpordi) koormuse tasakaalustamise. Teenuse mesh rakendab keerukamat 7. taseme (rakendusliku) koormuse tasakaalustamist, mis on rikkalikult algoritme ja efektiivsem liikluse haldamise osas. Koormuse tasakaalustamise parameetreid saab API kaudu muuta, võimaldades orkestreerida sinise-roheline või kanarbiku rolli rakendust.
- Krüpteerimine. Service Mesh võib krüpteerida ja dekodeerida päringud ja vastused, vähendades sellega teenuste koormust. Service Mesh võib samuti tõsta jõudlust prioriseerimise või olemasolevate püsiva ühenduse taaskasutamise kaudu, mis vähendab vajadust kallite arvutuste järele uute ühenduste loomiseks. Levinum rakendus liikluse krüptimiseks on omavaheline TLS (mTLS), kus avalike võtmete infrastruktuur (PKI) genereerib ja jagab sertifikaate ja võtmeid nende kasutamiseks Sidecar Proxy-s.
- Autentimine ja autoriseerimine. Service Mesh võib autoriseerida ja autentida väljastpoolt või seestpoolt rakendusse tehtud päringuid, saates eksemplaridele ainult valideeritud päringud.
- Automaatse väljalülitamise malli tugi. Service Mesh toetab , mis isoleerib haiged eksemplarid ja toob need siis vajadusel järk-järgult tagasi terve eksemplaride hulka.
Service Meshi rakenduse osa, mis haldab võrgu liiklust eksemplaride vahel, nimetatakse Andmeplaan. Konfiguratsiooni loomine ja juurutamine, mis haldab käitumist Andmeplaan, toimub eraldi Kontrollplaan. Kontrollplaan tavaliselt hõlmab või on kavandatud ühenduma API, CLI või GUI-ga rakenduse haldamiseks.
Control Plane Service Meshis jagab konfiguratsiooni Sidecar Proxy ja Data Plane'i vahel.
Tihti rakendatakse Service Meshi arhitektuuri keerukate operatiivsete ülesannete lahendamiseks konteinerite ja mikroteenuste abil. Mikroteenuste valdkonna pioneerideks on ettevõtted nagu Lyft, Netflix ja Twitter, kes pakuvad stabiilselt töötavaid teenuseid miljonitele kasutajatele üle kogu maailma. ( ) on ettevõtted nagu Lyft, Netflix ja Twitter, kes pakuvad stabiilselt töötavaid teenuseid miljonitele kasutajatele üle kogu maailma. (). Vähem nõudlike rakendusülesannete jaoks võib tõenäoliselt piisata lihtsamast arhitektuurist.
Service Meshi arhitektuur ei saa tõenäoliselt kunagi lahendada kõiki rakenduste toimimise ja tarnimisega seotud küsimusi. Arhitektidel ja arendajatel on tohutu tööriistade arsenal ning ainult üks neist - vasara - peab mitmete ülesannete seas lahendama vaid ühe: naela sisse lõhkuma. , näiteks, sisaldab mitmeid erinevaid mudeleid, mis pakuvad pidevat lähenemisviisi probleemide lahendamiseks mikroserviste kaudu.
Elemendid, mis ühendatakse Service Mesh arhitektuuris, nagu NGINX, konteinerid, Kubernetes ja mikroservised kui arhitektuuriline lähenemisviis, võivad olla sama produktiivselt kasutatavad ka teistes rakendustes ilma Service Meshita. Näiteks, Istio on loodud kui täielik Service Mesh arhitektuur, kuid moodulite ülesehitus tähendab, et arendajad saavad valida ja rakendada vaid vajalikke tehnoloogiate komponente. Seda silmas pidades on oluline formeerida selge arusaam Service Mesh kontseptsioonist, isegi kui te pole kindel, kas suudate seda kunagi oma rakenduses täielikult rakendada.
Allikas: habr.com
