Sveiki, Habr. Šodien es turpinu publikāciju sēriju, ko rakstīju īpaši jaunas kursa plūsmas uzsākšanai. .
Ievads
Arhitektūras stila izvēle ir viens no fundamentālajiem tehniskajiem lēmumiem, veidojot informācijas sistēmu. Šajā rakstu sērijā es piedāvāju analizēt populārākos arhitektūras stilus būvniecības vajadzībām un atbildēt uz jautājumu, kad kurš arhitektūras stils ir vispiemērotākais. Prezentācijas procesā mēģināšu novilkt loģisku ķēdi, kas izskaidro arhitektūras stilu attīstību no monolītiem līdz mikropakalpojumiem.
Iepriekšējā reizē mēs runājām par dažādiem monolītu veidiem un komponentu izmantošanu to veidošanai, gan būves komponentiem, gan izvietošanas komponentiem. Mēs saprotam uz pakalpojumiem orientētu arhitektūru.
Tagad mēs beidzot definēsim mikropakalpojumu arhitektūras galvenās īpašības.
Arhitektūras attiecības
Ir jāsaprot, ka, pamatojoties uz iepriekšējos pantos sniegtajām definīcijām, jebkurš pakalpojums ir sastāvdaļa, bet ne katrs pakalpojums ir mikropakalpojums.
Mikropakalpojumu arhitektūras raksturojums
Galvenās mikropakalpojumu arhitektūras iezīmes ir:
- Organizēts atbilstoši biznesa iespējām
- Produkti, nevis projekti
- Gudri galapunkti un mēmās caurules
- Decentralizēta pārvaldība
- Decentralizēta datu pārvaldība
- Infrastruktūras automatizācija
- Dizains neveiksmei
- Arhitektūra ar evolucionāru attīstību (evolucionārais dizains)
1. punkts nāk no uz pakalpojumiem orientētas arhitektūras, jo mikropakalpojumi ir īpašs pakalpojumu gadījums. Citi punkti ir jāapsver atsevišķi.
Organizēts atbilstoši biznesa iespējām
Tagad ir jāatceras Konveja likums: organizācijas, kas rada sistēmas, organizē tās arhitektūru, kopējot mijiedarbības struktūru šajās organizācijās. Kā piemēru var atgādināt kompilatora izveides gadījumu: septiņu cilvēku komanda izstrādāja septiņu pakāpju kompilatoru, bet piecu pakāpju kompilatoru.
Ja runājam par monolītiem un mikropakalpojumiem, tad, ja izstrādi organizē funkcionālās nodaļas (backend, frontend, datu bāzes administratori), tad iegūstam klasisko monolītu.
Lai saņemtu mikropakalpojumus, komandas jāorganizē pēc biznesa iespējām (pasūtījumi, sūtījumi, katalogu komanda). Šī organizācija ļaus komandām koncentrēties uz konkrētu lietojumprogrammas daļu izveidi.
Produkti, nevis projekti
Projekta pieeja, kurā komanda nodod izstrādāto funkcionalitāti citām komandām, ir pilnīgi nepiemērota mikropakalpojumu arhitektūras gadījumā. Komandai ir jāatbalsta sistēma visā tās dzīves ciklā. Amazon, viens no līderiem mikropakalpojumu ieviešanā, paziņoja: "jūs veidojat, jūs to vadāt." Produkta pieeja ļauj komandai sajust uzņēmuma vajadzības.
Gudri galapunkti un mēmās caurules
SOA arhitektūra lielu uzmanību pievērsa komunikācijas kanāliem, jo īpaši Enterprise Service Bus. Kas bieži noved pie kļūdainas spageti kastes, tas ir, monolīta sarežģītība pārvēršas par savienojumu sarežģītību starp pakalpojumiem. Mikropakalpojumu arhitektūra izmanto tikai vienkāršas komunikācijas metodes.
Decentralizēta pārvaldība
Galvenie lēmumi par mikropakalpojumiem būtu jāpieņem cilvēkiem, kuri faktiski izstrādā mikropakalpojumus. Šeit galvenie lēmumi nozīmē izvēli
programmēšanas valodas, izvietošanas metodika, publiskā interfeisa līgumi utt.
Decentralizēta datu pārvaldība
Standarta pieeja, kurā lietojumprogramma balstās uz vienu datu bāzi, nevar ņemt vērā katra konkrētā pakalpojuma specifiku. MSA ietver decentralizētu datu pārvaldību, tostarp dažādu tehnoloģiju izmantošanu.
Infrastruktūras automatizācija
MSA atbalsta nepārtrauktus izvietošanas un piegādes procesus. To var panākt tikai automatizējot procesus. Tajā pašā laikā liela skaita pakalpojumu izvietošana vairs neizskatās pēc kaut kā biedējoša. Izvēršanas procesam vajadzētu kļūt garlaicīgam. Otrs aspekts ir saistīts ar pakalpojumu vadību produktu vidē. Bez automatizācijas kļūst neiespējami pārvaldīt procesus, kas darbojas dažādās darbības vidēs.
Dizains neveiksmei
Daudzi MSA pakalpojumi ir pakļauti neveiksmēm. Tajā pašā laikā kļūdu apstrāde sadalītā sistēmā nav mazsvarīgs uzdevums. Lietojumprogrammas arhitektūrai jābūt izturīgai pret šādām kļūmēm. Rebeka Pārsons uzskata, ka ir ļoti svarīgi, lai mēs vairs pat neizmantotu saziņu starp pakalpojumiem, tā vietā saziņai izmantojam HTTP, kas ne tuvu nav tik uzticams.
Arhitektūra ar evolucionāru attīstību (evolucionārais dizains)
MSA sistēmas arhitektūrai jāattīstās evolucionāri. Ir vēlams ierobežot nepieciešamās izmaiņas viena pakalpojuma robežās. Jāņem vērā arī ietekme uz citiem pakalpojumiem. Tradicionālā pieeja ir mēģināt atrisināt šo problēmu ar versiju veidošanu, bet MSA iesaka izmantot versiju veidošanu
kā pēdējo līdzekli.
Secinājums
Pēc visa iepriekš minētā mēs varam formulēt, kas ir mikropakalpojumi. Mikropakalpojumu arhitektūra ir pieeja vienas lietojumprogrammas kā mazu pakalpojumu kolekcijas izstrādei, katrs darbojas savā procesā un mijiedarbojas, izmantojot vieglus mehānismus, bieži vien HTTP resursu API. Šie pakalpojumi ir balstīti uz biznesa iespējām, un tos var pilnībā izvietot neatkarīgi
automatizēts izvietošanas mehānisms. Pastāv minimālais šo pakalpojumu centralizētās pārvaldības līmenis, ko var rakstīt dažādās programmēšanas valodās un izmantot dažādas datu uzglabāšanas tehnoloģijas.
Avots: www.habr.com