Sveiki vēlreiz!.. Kursu sākuma priekšvakarā Esam sagatavojuši vēl vienu noderīgu tulkojumu.
Pakalpojuma tīkls ir konfigurējams, zema latentuma infrastruktūras slānis, kas nepieciešams, lai apstrādātu lielus tīkla starpprocesu sakaru apjomus starp lietojumprogrammu saskarnēm (API). Service Mesh nodrošina ātru, uzticamu un drošu saziņu starp konteinerizētiem un bieži vien īslaicīgiem lietojumprogrammu infrastruktūras pakalpojumiem. Service Mesh nodrošina tādas iespējas kā pakalpojumu atklāšana, slodzes līdzsvarošana, šifrēšana, caurspīdīgums, izsekojamība, autentifikācija un autorizācija, kā arī automātiskās izslēgšanas modeļa atbalsts (ķēdes pārtraucējs).
Pakalpojuma tīkls parasti tiek ieviests, nodrošinot katru pakalpojuma gadījumu ar starpniekservera gadījumu, ko sauc Blakusvāģis. Blakusvāģis pārvaldīt sakarus starp pakalpojumiem, pārraudzīt un atrisināt drošības problēmas, tas ir, visu, ko var abstrahēt no atsevišķiem pakalpojumiem. Tādā veidā izstrādātāji var rakstīt, uzturēt un apkalpot lietojumprogrammas kodu pakalpojumos, un sistēmas administratori var strādāt ar Service Mesh un palaist lietojumprogrammu.
Istio no Google, IBM un Lyft pašlaik ir slavenākā pakalpojumu tīkla arhitektūra. Un Kubernetes, kas sākotnēji tika izstrādāta Google, tagad ir vienīgā konteineru orķestrēšanas sistēma, ko atbalsta Istio. Pārdevēji cenšas izveidot komerciāli atbalstītas Istio versijas. Būs interesanti redzēt, kādas jaunas lietas viņi var ienest atvērtā pirmkoda projektā.
Tomēr Istio nav vienīgā iespēja, jo tiek izstrādātas citas Service Mesh implementācijas. Raksts sidecar proxy ir vispopulārākā realizācija, par ko var spriest pēc projektiem Buoyant, HashiCorp, Solo.io un citiem. Ir arī alternatīvas arhitektūras: Netflix tehnoloģiju rīkkopa ir viena no pieejām, kur Service Mesh funkcionalitāte tiek ieviesta caur Ribbon, Hysterix, Eureka, Archaius bibliotēkām, kā arī tādām platformām kā Azure Service Fabric.
Service Mesh ir arī sava terminoloģija pakalpojumu komponentiem un funkcijām:
- Konteineru orķestrēšanas ietvars. Tā kā lietojumprogrammu infrastruktūrai tiek pievienots arvien vairāk konteineru, ir nepieciešams atsevišķs konteineru uzraudzības un pārvaldības rīks - konteineru orķestrēšanas ietvars. Kubernetes ir stingri ieņēmis šo nišu, tik ļoti, ka pat tās galvenie konkurenti Docker Swarm un Mesosphere DC/OS piedāvā integrāciju ar Kubernetes kā alternatīvu.
- Pakalpojumi un gadījumi (Kubernetes Pods). Eksemplārs ir viena darbīga mikropakalpojuma kopija. Dažreiz viens gadījums ir viens konteiners. Programmā Kubernetes instance sastāv no nelielas neatkarīgu konteineru grupas, ko sauc par podiņu. Klienti reti piekļūst gadījumam vai podam tieši; biežāk viņi piekļūst pakalpojumam, kas ir identisku, mērogojamu un pret defektiem izturīgu gadījumu vai aplikumu (reprodukciju) kopa.
- Blakusvāģa starpniekserveris. Sidecar starpniekserveris darbojas ar vienu gadījumu vai podziņu. Sidecar Proxy mērķis ir maršrutēt vai starpniekserveri, kas nāk no konteinera, ar kuru tas darbojas, un atgriezt trafiku. Blakusvāģis mijiedarbojas ar citiem blakusvāģa starpniekserveriem, un to pārvalda orķestrēšanas sistēma. Daudzas Service Mesh implementācijas izmanto Sidecar Proxy, lai pārtvertu un pārvaldītu visu datplūsmu instancē vai podā un no tās.
- Pakalpojuma atklāšana. Kad instancei ir jāsazinās ar citu pakalpojumu, tai ir jāatrod (atklāj) veselīgs un pieejams cita pakalpojuma gadījums. Parasti instance veic DNS meklēšanu. Konteinera orķestrēšanas sistēma uztur to gadījumu sarakstu, kas ir gatavi saņemt pieprasījumus, un nodrošina saskarni DNS vaicājumiem.
- Slodzes balansēšana. Lielākā daļa konteineru orķestrēšanas sistēmu nodrošina slodzes līdzsvarošanu 4. slānī (transports). Service Mesh ievieš sarežģītāku slodzes līdzsvarošanu 7. slānī (lietojumprogrammas līmenī), kas ir bagāts ar algoritmiem un efektīvāks trafika pārvaldībā. Slodzes līdzsvarošanas iestatījumus var mainīt, izmantojot API, ļaujot jums organizēt zili zaļas vai kanārijas izvietošanu.
- Šifrēšana. Service Mesh var šifrēt un atšifrēt pieprasījumus un atbildes, novēršot šo pakalpojumu slogu. Service Mesh var arī uzlabot veiktspēju, piešķirot prioritāti vai atkārtoti izmantojot esošos pastāvīgos savienojumus, tādējādi samazinot nepieciešamību pēc dārgiem aprēķiniem jaunu savienojumu izveidošanai. Visizplatītākā trafika šifrēšanas ieviešana ir savstarpējais TLS (mTLS), kur publiskās atslēgas infrastruktūra (PKI) ģenerē un izplata sertifikātus un atslēgas izmantošanai Sidecar Proxy.
- Autentifikācija un autorizācija. Service Mesh var autorizēt un autentificēt pieprasījumus, kas veikti no lietojumprogrammas ārpuses vai iekšpuses, nosūtot gadījumiem tikai apstiprinātus pieprasījumus.
- Automātiskās izslēgšanas modeļa atbalsts. Service Mesh atbalsta , kas izolē neveselīgos gadījumus un pēc tam pakāpeniski atgriež tos veselīgu gadījumu kopā, kad nepieciešams.
Tiek izsaukta lietojumprogrammas Service Mesh daļa, kas pārvalda tīkla trafiku starp gadījumiem Datu plakne. Izveidojiet un izvietojiet konfigurāciju, kas kontrolē uzvedību Datu plakne, tiek veikta, izmantojot atsevišķu Vadības plakne. Vadības plakne parasti ietver vai ir paredzēts savienojuma izveidei ar API, CLI vai GUI, lai kontrolētu lietojumprogrammu.
Servisa tīkla vadības plakne sadala konfigurāciju starp blakusvāģa starpniekserveri un datu plakni.
Service Mesh arhitektūra bieži tiek izmantota, lai atrisinātu sarežģītas darbības problēmas, izmantojot konteinerus un mikropakalpojumus. Pionieri šajā jomā ir tādi uzņēmumi kā Lyft, Netflix un Twitter, kas nodrošina stabilus pakalpojumus miljoniem lietotāju visā pasaulē. (). Mazāk prasīgām lietojumprogrammām, visticamāk, pietiks ar vienkāršāku arhitektūru.
Service Mesh arhitektūra, visticamāk, nekad neatrisinās visas lietojumprogrammu darbības un piegādes problēmas. Arhitektu un izstrādātāju rīcībā ir milzīgs instrumentu arsenāls, un tikai viens no tiem ir āmurs, kuram starp daudziem uzdevumiem jāatrisina tikai viens – naglu kalšana. Piemēram, ietver vairākus dažādus modeļus, kas nodrošina pieeju nepārtrauktību problēmu risināšanai, izmantojot mikropakalpojumus.
Elementi, kas tiek apvienoti Service Mesh arhitektūrā, piemēram, NGINX, konteineri, Kubernetes un mikropakalpojumi kā arhitektūras pieeja, var būt vienlīdz produktīvi arī ar pakalpojumu tīklu nesaistītās implementācijās. Piemēram, Istio tika izstrādāta kā pilnīga pakalpojumu tīkla arhitektūra, taču tā modularitāte nozīmē, ka izstrādātāji var atlasīt un ieviest tikai tiem nepieciešamos tehnoloģiju komponentus. Paturot to prātā, ir svarīgi izveidot skaidru izpratni par Service Mesh koncepciju, pat ja neesat pārliecināts, ka kādreiz varēsiet to pilnībā ieviest savā lietojumprogrammā.
Avots: www.habr.com