Kas ir pakalpojumu tīkls?

Labrīt vēlreiz!.. Pirms kursa uzsākšanas «Programmatūras arhitekts» mēs esam sagatavojuši vēl vienu noderīgu tulkojumu.

Service Mesh ir konfigurējams infrastruktūras slānis ar zemu latentumu, kas nepieciešams, lai apstrādātu lielu apjomu tīkla starpprocesu komunikāciju starp lietojumprogrammu saskarnēm (API). Service Mesh nodrošina ātru, uzticamu un drošu komunikāciju starp konteinētiem un bieži efemēriem lietojumprogrammu infrastruktūras pakalpojumiem. Service Mesh nodrošina tādas iespējas kā pakalpojumu atklāšana, slodzes līdzsvarošana, šifrēšana, caurredzamība, izsekojamība, autentifikācija un autorizācija, kā arī atbalsts automātiskās izslēgšanas paraugiem (circuit breaker).
Service Mesh parasti tiek īstenots, nodrošinot katram pakalpojuma instancei proxy instanci, kas saucas Sidecar. Sidecar apstrādā komunikāciju starp pakalpojumiem, veic monitora funkcijas un risina drošības problēmas, tātad visu, ko var abstrahēt no atsevišķiem pakalpojumiem. Tādējādi izstrādātāji var rakstīt, uzturēt un apkalpot savas lietojumprogrammas kodu pakalpojumos, bet sistēmu administratori var strādāt ar Service Mesh un palaist lietojumprogrammu.

Istio no Google, IBM un Lyft, pašlaik ir visatzītākais Service Mesh arhitektūras risinājums. Kubernetes, kas sākotnēji tika izstrādāts Google, tagad ir vienīgā konteineru orķestrācijas sistēma, ko atbalsta Istio. Pārdevēji cenšas izveidot komerciāli atbalstītas versijas no Istio. Interesanti, ko jaunu viņi spēs ieviest atvērtā koda projektā.

Tomēr Istio nav vienīgā iespēja, jo tiek izstrādātas arī citas Service Mesh realizācijas. Paraugs sidecar proxy ir vispopulārākā realizācija, ko var spriest pēc projektiem Buoyant, HashiCorp, Solo.io un citiem. Ir arī alternatīvas arhitektūras: Netflix tehnoloģiju rīkkopa ir viens no pieejas veidiem, kur Service Mesh funkcionalitāte tiek īstenota, izmantojot bibliotēkas Ribbon, Hysterix, Eureka, Archaius, kā arī tādas platformas kā Azure Service Fabric.

Service Mesh arī kam ir sava terminoloģija attiecībā uz komponentu pakalpojumiem un funkcijām:

• Konteineru orķestrācijas ietvars. Kam pievieno arvien vairāk konteineru lietojumprogrammas infrastruktūrai, rodas nepieciešamība pēc atsevišķa rīka konteineru uzraudzībai un pārvaldībai - konteineru orķestrēšanas ietvara. Kubernetes stingri ieņēmis šo nišu, pat tik lielā mērā, ka pat tā galvenie konkurenti Docker Swarm un Mesosphere DC/OS piedāvā kā alternatīvu integrāciju ar Kubernetes.
• Pakalpojumi un instanču (Kubernetes podi). Instanče ir viena palaista mikropakalpojuma kopija. Dažreiz viena instanče ir viens konteiners. Kubernetes instanče sastāv no nelielas grupas neatkarīgu konteineru, ko sauc par podu. Klienti reti tieši vēršas pie instanču vai podu, visbiežāk viņi piekļūst pakalpojumam, kas pārstāv identisku, mērogojamu un kļūdu noturīgu instanču vai podu (repliku) kopumu.
• Sidecar Proxy. Sidecar Proxy strādā ar vienu instanču vai podu. Sidecar Proxy būtība ir novirzīt vai proksēt trafiku, kas nāk no tā konteineru, ar kuru tas strādā, un atpakaļtīkla trafiku. Sidecar mijiedarbojas ar citiem Sidecar Proxy un tiek pārvaldīts ar orķestrēšanas ietvaru. Daudzas Service Mesh realizācijas izmanto Sidecar Proxy, lai pārņemtu un pārvaldītu visu ienākošo un izejošo trafiku instanču vai podu.
• Pakalpojumu atklāšana. Kad instanču ir nepieciešams mijiedarboties ar citu pakalpojumu, tai ir jāatrod (jāatklāj) derīga un pieejama cita pakalpojuma instanču. Parasti instanče meklē pa DNS. Orķestrēšanas ietvars glabā sarakstu ar instancēm, kas ir gatavas saņemt pieprasījumus, un nodrošina interfeisu DNS pieprasījumiem.
• Slodzes līdzsvarošana. Lielākā daļa konteineru orķestrēšanas ietvaru nodrošina slodzes līdzsvarošanu 4. līmenī (transporta). Service Mesh īsteno sarežģītāku slodzes līdzsvarošanu 7. līmenī (lietojumprogrammā), bagātā ar algoritmiem un efektīvāku trafika pārvaldībā. Slodzes līdzsvarošana parametri var tikt mainīti, izmantojot API, kas ļauj orķestrēt zilo-zaļo vai kanāriju izvietojumu.
• ŠifrēšanaService Mesh var šifrēt un atšifrēt pieprasījumus un atbildes, tādējādi atvieglojot uzdevumu pakalpojumiem. Service Mesh arī var uzlabot veiktspēju, prioritizējot vai atkārtoti izmantojot esošās pastāvīgās savienojumus, kas samazina nepieciešamību dārgiem aprēķiniem jaunu savienojumu izveidē. Visizplatītākā trafika šifrēšanas realizācija ir mutual TLS (mTLS), kuras atslēgu infrastruktūra (PKI) ģenerē un izplata sertifikātus un atslēgas to izmantošanai Sidecar Proxy.
• Autentifikācija un autorizācija. Service Mesh var autorizēt un autentificēt pieprasījumus, kas veikti no ārpuses vai no programmas iekšpuses, nosūtot instancēm tikai apstiprinātus pieprasījumus.
• Atbalsts automātiskās izslēgšanas modelim. Service Mesh atbalsta automātiskās izslēgšanas modeli, kas izolē nedarbspējīgas instances un pakāpeniski atjauno tās veselīgo instanču grupā pēc nepieciešamības.

Tā daļa no aplikācijas Service Mesh, kas pārvalda tīkla trafiku starp instancēm, saucas Data Plane. Konfigurācijas izveidošana un izvietošana, kas pārvalda uzvedību Data Plane, tiek veikta ar atsevišķu Control Plane. Control Plane parasti ietver vai ir izstrādāta, lai savienotos ar API, CLI vai GUI aplikācijas pārvaldīšanai.

Control Plane pakalpojumā Service Mesh izplata konfigurāciju starp Sidecar Proxy un Data Plane.

Bieži vien Service Mesh arhitektūra tiek izmantota, lai risinātu sarežģītas operāciju uzdevumus, izmantojot konteinerus un mikroservisus. Nozaru pionieri mikroservisiem ir tādas kompānijas kā Lyft, Netflix un Twitter, kas sniedz stabilus pakalpojumus miljoniem lietotāju visā pasaulē. (Šeit varat iepazīties ar detalizētu aprakstu par dažām arhitektūras problēmām, ar kurām saskārās Netflix). Mazāk prasīgām pielietojuma uzdevumiem, visticamāk, būs pietiekami vienkāršākas arhitektūras.

Service Mesh arhitektūra noteikti nekad nebūs atbilde uz visiem jautājumiem, kas saistīti ar aplikāciju darbību un piegādi. Arhitekti un izstrādātāji ir apveltīti ar plašu instrumentu arsenālu, un tikai viens no tiem — āmurs, kas starp daudziem uzdevumiem jāveic tikai vienu – iekodināt naglas. Microservices Reference Architecture no NGINX, piemēram, ietver vairākus dažādus modeļus, kas nodrošina nepārtrauktu pieeju uzdevumu risināšanai, izmantojot mikroservisus.

Elementi, kas apvienojas Service Mesh arhitektūrā, piemēram, NGINX, konteineri, Kubernetes un mikroservisi kā arhitektūras pieeja, var tikt izmantoti ne mazāk produktīvi arī risinājumos bez Service Mesh. Piemēram, Istio tika izstrādāts kā pilnīga Service Mesh arhitektūra, taču modularitāte liecina, ka izstrādātāji var izvēlēties un piemērot tikai nepieciešamos tehnoloģiju komponentus. Atceroties to, ir jāveido skaidra izpratne par Service Mesh koncepciju, pat ja neesat pārliecināti, ka kādreiz varēsit to pilnībā ieviest savā lietotnē.

Modulārie monolīti un DDD

Avots: habr.com