Viena no pārmaiņām, kas notiek IT zem digitālās transformācijas karoga, ir lielu, monolītu lietojumu sadalīšana mikropakalpojumos—mazas, atsevišķas funkcionalitātes vienības, kas darbojas konteineros—programmatūras pakotnes, kas ietver visu pakalpojuma kodu un atkarības, kuras var izolēt un viegli pārvietot no viena servera uz citu.
Šādas konteineru arhitektūras ir viegli palielināt un palaist mākonī, un atsevišķus mikropakalpojumus var ātri izvērst un atkārtot. Tomēr saziņa starp šiem mikropakalpojumiem kļūst arvien sarežģītāka, jo lietojumprogrammas kļūst lielākas un vienlaikus tiek palaisti vairāki viena pakalpojuma gadījumi. Pakalpojuma siets ir jauna arhitektūras forma, kuras mērķis ir dinamiski savienot šos mikropakalpojumus tādā veidā, kas samazina administratīvās un programmēšanas izmaksas.
Kas ir servisa siets?
Plašākajā nozīmē pakalpojuma tīkls ir, kā Red Hat to raksturo, “veids, kā kontrolēt, kā dažādas lietojumprogrammas daļas koplieto datus savā starpā”. Šis apraksts tomēr varētu ietvert daudz un dažādas lietas. Patiesībā tas izklausās ļoti daudz kā starpprogrammatūra, kas lielākajai daļai izstrādātāju ir pazīstama no klienta-servera lietojumprogrammām.
Pakalpojuma sietu padara unikālu tas, ka tas ir veidots, lai pielāgotos izplatīto mikropakalpojumu vides unikālajam raksturam. Liela apjoma lietojumprogrammā, kas izveidota no mikropakalpojumiem, var būt vairāki jebkura pakalpojuma gadījumi, kas darbojas dažādos vietējos vai mākoņdatoros. Visas šīs kustīgās daļas acīmredzami apgrūtina atsevišķu mikropakalpojumu atrašanu, lai atrastu citus pakalpojumus, ar kuriem viņiem nepieciešams sazināties. Pakalpojuma tīkls automātiski rūpējas par pakalpojumu atklāšanu un savienošanu katrā brīdī, lai tas nebūtu jādara gan cilvēku izstrādātājiem, gan atsevišķiem mikropakalpojumiem.
Padomājiet par pakalpojumu sietu kā programmatūras definēta tīkla (SDN) ekvivalentu OSI tīkla modeļa 7. līmenim. Tāpat kā SDN izveido abstrakcijas slāni, lai tīkla administratoriem nebūtu jārisina fiziski tīkla savienojumi, pakalpojuma siets atdala lietojumprogrammas pamatā esošo infrastruktūru no abstraktās arhitektūras, ar kuru jūs mijiedarbojaties.
Ideja par pakalpojumu sietu radās organiski, kad izstrādātāji sāka cīnīties ar patiesi milzīgo sadalīto arhitektūru problēmām. Linkerd, pirmais projekts šajā jomā, dzimis kā iekšējā projekta rezultāts Twitter. Istio, vēl viens populārs pakalpojumu tīkls ar lielu korporatīvo atbalstu, radās Lyft. (Pēc brīža mēs sīkāk aplūkosim abus šos projektus.)
Pakalpojuma tīkla slodzes līdzsvarošana
Viena no galvenajām iezīmēm, ko nodrošina tīkla tīkls, ir slodzes līdzsvarošana. Mēs parasti domājam par slodzes līdzsvarošanu kā par tīkla funkciju - jūs vēlaties novērst, ka kāds serveris vai tīkla saite tiek pārņemta ar trafiku, tāpēc jūs atbilstoši maršrutējat paketes. Pakalpojuma sietas kaut ko līdzīgu dara lietojumprogrammu līmenī, kā to raksturo Tvens Teilors, un izpratne, kas ļauj labi izprast, ko mēs domājam, sakot, ka tīkla siets ir kā lietojumprogrammas slāņa programmatūras noteikts tīkls.
Būtībā viens no pakalpojumu tīkla uzdevumiem ir izsekot, kuri dažādu mikropakalpojumu gadījumi, kas tiek izplatīti visā infrastruktūrā, ir “veselīgākie”. Tas var viņus aptaujāt, lai redzētu, kā viņiem klājas, vai sekotu, kuri gadījumi lēnām reaģē uz pakalpojumu pieprasījumiem, un nosūta nākamos pieprasījumus citām instancēm. Pakalpojuma tīkls var veikt līdzīgu darbu tīkla maršrutos, pamanot, kad ziņojumu saņemšanai ir nepieciešams pārāk ilgs laiks, lai nokļūtu galamērķī, un veicot citus maršrutus, lai kompensētu. Šīs palēnināšanās var rasties problēmu dēļ ar pamata aparatūru vai vienkārši tāpēc, ka pakalpojumi ir pārslogoti ar pieprasījumiem vai strādā pie to apstrādes jaudas. Svarīgi ir tas, ka servisa siets var atrast citu tā paša pakalpojuma gadījumu un tā maršrutu, tādējādi visefektīvāk izmantojot lietojumprogrammas kopējo jaudu.
Pakalpojuma siets pret Kubernetes
Ja jums ir zināmas ar konteineriem balstītas arhitektūras, jums var rasties jautājums, kur Kubernetes, populārā atvērtā koda konteineru orķestrēšanas platforma, iekļaujas šajā attēlā. Galu galā, vai visa Kubernetes jēga nav tā, ka tā pārvalda to, kā jūsu konteineri sazinās viens ar otru? Kā korporatīvajā emuārā norāda Kublr komanda, jūs varētu domāt par Kubernetes “servisa” resursu kā par ļoti vienkāršu pakalpojumu tīkla veidu, jo tas nodrošina pakalpojumu atklāšanu un pieprasījumu līdzsvarošanu. Bet pilnībā piedāvātie servisa tīkli nodrošina daudz vairāk funkcionalitātes, piemēram, drošības politikas un šifrēšanas pārvaldība, “ķēdes pārrāvums”, lai apturētu pieprasījumus lēni reaģējošiem gadījumiem, slodzes līdzsvarošana, kā aprakstīts iepriekš, un daudz kas cits.
Paturiet prātā, ka lielākajai daļai pakalpojumu sietu ir nepieciešama orķestrēšanas sistēma, piemēram, Kubernetes. Pakalpojuma acis piedāvā paplašinātu funkcionalitāti, nevis aizstājēju.
Pakalpojuma siets pret API vārtejām
Katrs mikropakalpojums nodrošinās lietojumprogrammu saskarni (API), kas kalpo kā līdzeklis, ar kuru citi pakalpojumi ar to sazinās. Tas rada jautājumu par atšķirībām starp pakalpojumu sietu un citiem tradicionālākiem API pārvaldības veidiem, piemēram, API vārtejām. Kā skaidro IBM, API vārteja atrodas starp mikropakalpojumu grupu un “ārējo” pasauli, vajadzības gadījumā maršrutējot pakalpojumu pieprasījumus, lai pieprasītājam nebūtu jāzina, ka tas nodarbojas ar mikropakalpojumiem balstītu lietojumprogrammu. No otras puses, pakalpojuma tīkls starpo pieprasījumus mikroservisu lietotnes iekšpusē, dažādiem komponentiem pilnībā apzinoties savu vidi.
Vēl viens veids, kā domāt par to, kā raksta Džastins Vorens Forbes, ir tas, ka pakalpojumu siets ir paredzēts austrumu-rietumu satiksmei klastera ietvaros un API vārteja ir paredzēta ziemeļu-dienvidu satiksmei, kas ienāk klasterī un iziet no tā. Bet visa ideja par tīkla sietu joprojām ir agra un mainīga. Daudzi servisa tīkli, tostarp Linkerd un Istio, tagad piedāvā arī ziemeļu-dienvidu funkcionalitāti.
Pakalpojuma tīkla arhitektūra
Ideja par pakalpojumu sietu ir parādījusies tikai pēdējos pāris gados, un ir daudz dažādu pieeju “tīkla sietu” problēmas risināšanai, t.i., sakaru pārvaldībai mikropakalpojumiem. Endrjū Jenkinss no Aspen Mesh identificē trīs iespējamās izvēles attiecībā uz vietu, kur varētu dzīvot servisa tīkla izveidotais saziņas slānis:
- Iekšā bibliotēka ka katrs no jūsu mikropakalpojumiem tiek importēts
- Iekšā mezglu aģents kas sniedz pakalpojumus visiem konteineriem noteiktā mezglā
- Iekšā blakusvāģis konteiners, kas darbojas blakus jūsu lietojumprogrammas konteineram
Blakusvāģa modelis ir viens no vispopulārākajiem tīkla acu modeļiem - tik ļoti, ka tas dažos veidos ir kļuvis par sinonīmu pakalpojumu tīkliem. Lai gan tas nav stingri sakāms, blakusvāģu pieeja ir ieguvusi tik lielu saķeri, ka šo arhitektūru mēs aplūkosim sīkāk.
Blakusvāģi dienesta sietā
Ko nozīmē teikt, ka blakusvāģa konteiners “iet blakus” jūsu lietojumprogrammas konteineram? Red Hat ir diezgan labs izskaidrojums. Katram šāda veida pakalpojumu sieta mikropakalpojumu konteineram ir cits atbilstošs starpniekservera konteiners. Visa loģika, kas nepieciešama saziņai starp pakalpojumu, tiek izņemta no mikropakalpojuma un ievietota blakusvāģī.
Tas var šķist sarežģīti - galu galā jūs faktiski divkāršojat savā lietojumprogrammā esošo konteineru skaitu! Bet jūs izmantojat arī noformējuma modeli, kas ir galvenais izplatīto lietotņu vienkāršošanai. Ievietojot visu tīkla un sakaru kodu atsevišķā konteinerā, jūs padarījāt to par daļu no infrastruktūras un atbrīvojāt izstrādātājus no tā ieviešanas lietojumprogrammas ietvaros.
Būtībā tas, kas jums ir palicis, ir mikropakalpojums, kuru var koncentrēt uz lāzeru tā biznesa loģikai. Mikropakalpojumam nav jāzina, kā sazināties ar visiem citiem dienestiem savvaļas un trakajā vidē, kur tie darbojas. Tam tikai jāzina, kā sazināties ar blakusvāģi, kurš rūpējas par pārējo.
Pakalpojuma tīkli: Linkerd, Envio, Istio, Consul
Tātad, kādas ir izmantojamās pakalpojumu sietas? Nu, tur nav tieši tādu preču, kas būtu pieejamas ārpus tirgus. Lielākā daļa pakalpojumu sietu ir atvērta pirmkoda projekti, kuru īstenošana prasa nelielu izsmalcinātību. Lielie vārdi ir:
- Linkerd (izrunā “linker-dee”) - izlaists 2016. gadā, un tādējādi vecākais no šiem piedāvājumiem Linkerds tika atdalīts no bibliotēkas, kas izstrādāta vietnē Twitter. Vēl viens smags hitter šajā telpā, Conduit, tika iekļauts Linkerd projektā un veido pamatu Linkerd 2.0.
- Sūtnis - izveidots Lyft, sūtnis aizņem pakalpojumu tīkla “datu plaknes” daļu. Lai nodrošinātu pilna servisa tīklu, tas jāapvieno ar “vadības plakni”, piemēram, ...
- Istio - sadarbībā ar Lyft, IBM un Google izstrādātais Istio ir vadības plāns tādu starpnieku apkalpošanai kā Envoy. Kamēr Istio un Envoy ir noklusējuma pāris, katru var savienot pārī ar citām platformām.
- HashiCorp Consul - ieviesta ar Consul 1.2, funkcija ar nosaukumu Connect pievienoja pakalpojumu šifrēšanu un uz identitāti balstītu autorizāciju HashiCorp izplatītajai sistēmai pakalpojumu atklāšanai un konfigurēšanai, pārvēršot to par pilna servisa sietu.
Kurš servisa siets jums ir piemērots? Salīdzinājums pārsniedz šī raksta darbības jomu, taču ir vērts atzīmēt, ka visi iepriekš minētie produkti ir pierādīti lielās un sarežģītās vidēs. Linkerd un Istio ir visplašākās funkciju kopas, taču visas tās strauji attīstās. Jūs varētu vēlēties apskatīt Džordža Mirandas sadalījumu par Linkerda, sūtņa un Istio funkcijām, lai gan paturiet prātā, ka viņa raksts tika uzrakstīts pirms Conduit un Linkerd apvienoja spēkus.
Tāpat paturiet prātā, ka šī telpa ir jauna un jebkurā laikā varētu parādīties jauni konkurenti. Piemēram, 2018. gada novembrī Amazon sāka piedāvāt AWS pakalpojumu tīkla publisku priekšskatījumu. Ņemot vērā to, cik daudz veikalu izmanto Amazon publisko mākoni, AWS App Mesh vajadzētu būt lielai ietekmei.
