Gandrīz katra datorsistēma veic vairākus uzdevumus, izmantojot kopīgos resursus, un viens no datorprogrammēšanas jautājumiem ir tas, cik cieši koda biti, kas veic šos uzdevumus, būtu jāpiesaista viens otram. Arvien populārāka atbilde ir mikropakalpojuma jēdziens—maza, diskrēta funkcionalitātes daļa, kas mijiedarbojas ar citiem mikropakalpojumiem, lai izveidotu lielāku sistēmu.
Lai gan pamatideja par šādu diskrētu komponentu izmantošanu nav jauna, mikropakalpojumu ieviešanas veids padara tos par dabisku pamatu abām mūsdienu mākoņdatošanas lietojumprogrammām. Mikropakalpojumi atbilst arī devops filozofijai, kas mudina ātri un nepārtraukti ieviest jaunu funkcionalitāti.
Kas ir mikropakalpojumi?
Mikroservisu “mikro” nozīmē, ka tie ir mazi lietojumi. Dažreiz tā ir taisnība, bet labāks veids, kā domāt par viņiem, ir tas, ka viņiem jābūt tikai tik lieliem, cik nepieciešams, lai veiktu vienu konkrētu lietu vai atrisinātu konkrētu problēmu. Šai problēmai jābūt konceptuālai, nevis tehniskai. Kā norāda Microsoft, "mikropakalpojumi jāveido atbilstoši biznesa iespējām, nevis horizontāliem slāņiem, piemēram, piekļuvei datiem vai ziņojumapmaiņai." Viņi sazinās ar citiem mikropakalpojumiem un ārējiem lietotājiem, izmantojot relatīvi stabilas API, lai izveidotu lielāku lietojumprogrammu.
Tādējādi atsevišķa mikropakalpojuma iekšējo funkcionalitāti var pielāgot vai radikāli uzlabot, neietekmējot pārējo sistēmu. Tas savukārt saistās ar to, kā darbojas veikali: ja lielākas lietojumprogrammas īpašās funkcijas tiek sadalītas atsevišķos, neatkarīgi darbojošos koda gabalos, ir vieglāk dzīvot CI / CD devops mantrā (nepārtraukta integrācija un nepārtraukta piegāde) . Arī labi definēti API ļauj mikropakalpojumus viegli pārbaudīt automātiski.
Mikroservisu arhitektūra pret monolītu arhitektūru
Jūs bieži dzirdēsiet par mikropakalpojumiem, par kuriem runāja “mikropakalpojumu arhitektūras ziņā”.” Šī frāze ietver ne tikai pašus mikropakalpojumus, bet arī vadības un pakalpojumu atklāšanas komponentus, kā arī API vārteju, kas apstrādā saziņu starp mikropakalpojumiem un ārpasauli.
“Monolīts pielietojums” ir pretējs tam, kas ir mikropakalpojumi. Tas ir retronīms lietojumprogrammai, kurā viss kods ir vienā lielā binārā izpildāmā failā. Kā skaidro TechTarget, monolītu lietojumprogrammu ir grūtāk mērogot un grūtāk uzlabot. Bet, tā kā tā ir veidota kā viena saliedēta lietojumprogramma, tai nav nepieciešama tik daudz pārvaldības kā mikropakalpojumu arhitektūrai.
Ierobežoti jēdzieni: kā definēt mikropakalpojumu
Uz brīdi atbalstīsim mūsu iepriekšējo bausli, ka mikropakalpojumiem ir jādara viena konkrēta lieta. To ir viegli pateikt, taču praksē funkcionalitāte bieži tiek sajaukta, un dalījumu zīmēšana ir grūtāka, nekā izskatās. Domēna analīze un domēna virzīts dizains ir teorētiskas pieejas, kas palīdzēs jums izšķirt lielo uzdevumu atsevišķās problēmās, kuras var atrisināt mikropakalpojums. Šajā procesā, kas izklāstīts izgaismojošā Microsoft emuāra ziņu sērijā, jūs izveidojat sava biznesa domēna abstraktu modeli un šajā procesā atklājat ierobežotos kontekstus, kura grupa apvieno funkcionalitāti, kas konkrētā veidā mijiedarbojas ar pasauli.
Piemēram, jums var būt viens ierobežots konteksts nosūtīšanai un cits kontiem. Reālā pasaules fiziskajam objektam, protams, būtu gan cena, gan vieta, kur tam jāiet, taču ierobežotie konteksti atspoguļo īpašus veidus, kādos jūsu lietojumprogramma domā un mijiedarbojas ar šiem objektiem. Katram mikropakalpojumam vajadzētu pastāvēt pilnībā vienā ierobežotā kontekstā, lai gan daži ierobežoti konteksti var ietvert vairāk nekā vienu mikropakalpojumu.
Mikropakalpojumi pret pakalpojumiem orientētu arhitektūru pret tīmekļa pakalpojumiem
Šajā brīdī, ja jūs esat IT profesionālis, kurš kādu laiku darbojas nozarē, jūs domājat, ka daudz kas izklausās pazīstams. Ideja par nelielu atsevišķu programmu sadarbību varētu jums atgādināt gan par SOA (uz pakalpojumiem orientētu arhitektūru), gan tīmekļa pakalpojumiem, divi modes vārdi no satriecošajām Web 2.0 dienām 2000. gados. Lai gan vienā ziņā zem saules patiešām nav nekā jauna, starp šiem jēdzieniem un mikropakalpojumiem ir nozīmīgas atšķirības. Datamation ir labi sadalīts atšķirībās, taču šeit ir īsa versija:
- Uz pakalpojumu orientētā arhitektūrā atsevišķi komponenti ir samērā cieši saistīti, bieži koplietojot tādus aktīvus kā krātuve, un tie sazinās, izmantojot specializētu programmatūru, ko sauc par uzņēmuma krātuves autobusu. Mikropakalpojumi ir neatkarīgāki, tiem ir mazāk resursu un tie sazinās, izmantojot vieglākus protokolus. Ir vērts atzīmēt, ka mikropakalpojumi radās SOA vidē un dažreiz tiek uzskatīti par sava veida SOA vai koncepcijas pēcteci.
- Tīmekļa pakalpojums ir publiski pieejams funkcionalitātes kopums, kuram citas lietojumprogrammas var piekļūt, izmantojot Web; iespējams, visizplatītākais piemērs ir Google Maps, kuru restorāna vietne varētu ievietot, lai sniegtu norādes klientiem. Tas ir daudz brīvāks savienojums, nekā jūs varētu redzēt mikropakalpojumu arhitektūrā.
Mikroservisu komunikācija
Uzmanība, ko jūs bieži dzirdat par mikropakalpojumu arhitektūrām, ir tāda, ka tajās jābūt “viedajiem galapunktiem un mēmajām caurulēm”. Citiem vārdiem sakot, mikropakalpojumiem jābūt vērstiem uz pamata un labi izveidotu komunikācijas metožu izmantošanu, nevis uz sarežģītu un stingru integrāciju. Kā atzīmēts, šī ir vēl viena lieta, kas atšķir mikropakalpojumus no SOA.
Parasti saziņai starp mikropakalpojumiem jābūt asinhronai, nozīmē, ka kodu pavedieni nav bloķēti, gaidot atbildes. (Joprojām ir labi izmantot sinhronos sakaru protokolus, piemēram, HTTP, lai gan asinhronie protokoli, piemēram, AMQP (Advanced Message Queuing Protocol), ir izplatīti arī mikropakalpojumu arhitektūrās.) Šāda veida vaļīga savienošana padara mikroservisu arhitektūru elastīgāku, ja rodas kļūme. atsevišķām tīkla sastāvdaļām vai daļām, kas ir galvenais ieguvums.
Mikroservisi, Java un pavasara sāknēšana un pavasara mākonis
Daži no pirmajiem darbiem mikropakalpojumos radās Java kopienā; Martins Faulers bija agrīns aizstāvis. 2012. gada Java konferencē Polijā notika viena no vissvarīgākajām agrīnajām tēmas prezentācijām ar nosaukumu “Mikro pakalpojumi - Java, Unix ceļš.” Tajā tika ieteikts piemērot principus, kas vadīja pirmo Unix lietojumprogrammu attīstību 20. gadsimta 70. gados (“Rakstīt programmas, kas dara vienu lietu un dara to labi. Rakstiet programmas, lai tās darbotos kopā ”) uz Java izstrādi.
Šīs vēstures rezultātā ir daudz Java sistēmu, kas ļauj veidot mikropakalpojumus. Viens no populārākajiem ir Spring Boot, kas īpaši paredzēts mikropakalpojumiem; Sāknēšanu paplašina Spring Cloud, kas, kā norāda nosaukums, ļauj šos pakalpojumus izvietot arī mākonī. Pivotal Software, Spring izstrādātājam, ir laba apmācība, kā sākt darbu ar mikropakalpojumu izstrādi, izmantojot šos ietvarus.
Mikropakalpojumi un konteineri: Docker, Kubernetes un citi
Pamattehnoloģija, kas ir vistālāk virzījusies uz mikropakalpojumu nokļūšanu galvenajā plūsmā, ir konteineri. Konteiners ir līdzīgs VM gadījumam, taču tā vietā, lai tajā iekļautu visu autonomu operētājsistēmu, konteiners ir tikai izolēta lietotāja telpa, kas izmanto resursdatora operētājsistēmas kodolu, bet citādi saglabā tā iekšējo izpildi. Konteineri ir daudz mazāki par VM gadījumiem, un tos ir viegli ātri izvietot lokāli vai mākonī, un tos var vērpt uz augšu vai uz leju, lai tie atbilstu pieprasījumam un pieejamajiem resursiem.
Mikropakalpojumu konteineru pievilcībai jābūt acīmredzamai: katrs atsevišķais mikropakalpojums var darboties savā konteinerā, kas ievērojami samazina pakalpojumu pārvaldības izmaksas. Lielākajai daļai konteineru ieviešanas ir papildu orķestrēšanas rīki, kas automatizē konteineru lietojumprogrammu izvietošanu, pārvaldību, mērogošanu, tīklu veidošanu un pieejamību. Tā ir mazu, viegli uzbūvējamu mikropakalpojumu un viegli izvietojamu konteineru kombinācija, kas padara devops filozofiju iespējamu. Ir vairākas konteineru koncepcijas realizācijas, taču neapšaubāmi vispopulārākais ir Docker, kas parasti ir savienots pārī ar Kubernetes kā orķestrēšanas platformu.
Lai arī pavasaris ir populārs, tas ir saistīts ar Java platformu. Savukārt uz konteineriem balstītas sistēmas ir poligloti: jebkura programmēšanas valoda, kuru atbalsta OS, var darboties konteinerā, kas programmētājiem dod lielāku elastību. Patiešām, liela mikropakalpojumu priekšrocība ir tā, ka katru atsevišķo pakalpojumu var rakstīt jebkurā valodā, kas ir visjēdzīgākā vai kas izstrādātājiem ir visērtāk. Patiešām, pakalpojumu var pilnībā pārbūvēt jaunā valodā, neietekmējot sistēmu kopumā, ja vien tā API paliek stabila. DZone ir raksts, kurā apspriesti Spring Cloud un Kubernetes plusi un mīnusi mikropakalpojumiem.
Mikroservisu dizaina modeļi
Neatkarīgi no tā, kādā valodā izmantojat mikropakalpojumu izstrādi, jūs saskarsieties ar problēmām, ar kurām citi izstrādātāji ir saskārušies iepriekš. Dizaina modeļi ir formalizēti, abstrakti risinājumi atkārtotām datorzinātņu problēmām, un daudzi no tiem ir īpaši paredzēti mikropakalpojumiem. Devopedia ir lielisks saraksts, kurā ietilpst:
- Pakalpojuma reģistrs: klientu savienošanai ar pieejamajiem mikropakalpojumu gadījumiem
- Automātiskais slēdzis: lai novērstu neveiksmīgu pakalpojumu atkārtotu izsaukšanu
- Fallback: par alternatīvas nodrošināšanu neveiksmīgam pakalpojumam
- Blakusvāģis: galvenā pakalpojuma papildu pakalpojumu sniegšanai, piemēram, mežizstrādei, pakalpojumu sinhronizēšanai vai uzraudzībai
- Adapteris: lai standartizētu vai normalizētu saskarni starp galveno konteineru un ārējo pasauli
- Vēstnieks: lai savienotu galveno konteineru ar ārpasauli, piemēram, par vietējo hostu savienojumu tuvināšanu ārējiem savienojumiem
Mikroservisi un mākonis: AWS un Azure
Kā minēts iepriekš, viena no konteineru izmantošanas priekšrocībām ir tā, ka tos var viegli izvietot mākonī, kur ir pieejami elastīgi skaitļošanas resursi, lai jūs varētu maksimāli palielināt savas lietojumprogrammas efektivitāti. Kā jūs varētu iedomāties, lielākie publiskie mākoņu pārdevēji ļoti vēlas, lai jūs izmantotu savas platformas, lai palaistu jūsu mikropakalpojumos balstītas lietotnes. Lai iegūtu papildinformāciju, skatiet Amazon, Microsoft un Google resursus.
