🥇Arhitektūras stila izvēle (3. daļa)

Sveiki, Habr. Šodien turpināšu publikāciju sēriju, ko esmu izveidojis jaunā kursa uzsākšanai. «Programmatūras arhitekts».

Ievads

Arhitektūras stila izvēle ir viens no galvenajiem tehniskajiem lēmumiem informācijas sistēmas izveidē. Šajā rakstu sērijā es piedāvāju apskatīt populārākos lietojumprogrammu arhitektūras stilus un atbildēt uz jautājumu, kurā gadījumā kurš arhitektūras stils ir visvairāk vēlams. Izklāstot informāciju, es cenšos veidot loģisku secību, kas izskaidro arhitektūras stilu attīstību no monolītiem līdz mikroservisiem.

Ie priekšnē mēs runājām par dažādām monolītu formām un komponentu izmantošanu to izveidē, iekļaujot gan montāžas komponentus, gan izvietošanas komponentus. Mēs padziļināti aplūkojām pakalpojumu orientētu arhitektūru.

Tagad mēs beidzot noteiksim mikropakalpojumu arhitektūras pamatīpašības.

Attiecības starp arhitektūrām

Ir nepieciešams saprast, ka, balstoties uz datiem iepriekšējās rakstā definicijās, jebkurš pakalpojums ir komponente, taču ne katrs pakalpojums ir mikropakalpojums.

Mikropakalpojumu arhitektūras īpašības

Pamatīpašības mikropakalpojumu arhitektūras ir:

Organizācija, kas orientēta uz biznesa iespējām (Organized around Business Capabilities)
Produkti, nevis projekti (Products not Projects)
Gudras ieejas punkti un muļķīgi caurules (Smart endpoints and dumb pipes)
Decentralizēta pārvaldība (Decentralized Governance)
Decentralizēta datu pārvaldība (Decentralized Data Management)
Infrastruktūras automatizācija (Infrastructure Automation)
Dizains neveiksmēm (Design for failure)
Evolūcijas strūktūras arhitektūra (Evolutionary Design)

Pirmais punkts nāk no pakalpojumu orientētas arhitektūras, jo mikropakalpojumi ir īpaša pakalpojumu forma. Citi punkti ir pelnījuši atsevišķu apskatu.

Organizācija, kas orientēta uz biznesa iespējām (Organized around Business Capabilities)

Tagad ir jāatceras Konveja likums: organizācijas, kas izstrādā sistēmas, organizē tās arhitektūru, kas atbilst šo organizāciju mijiedarbības struktūrai. Piemēram, var pieminēt kompīlatora izveidi: komanda no septiņiem cilvēkiem izstrādāja septiņu pārdošanu kompīlatoru, bet komanda no pieciem — piecu pārdošanu.

Ja runājam par monolītiem un mikropakalpojumiem, tad, ja izstrāde organizēta funkcionālajos departamentos (aizmugure, priekšnē, datu bāzes administratori), tad rezultāts ir klasiskā monolīta.

Lai iegūtu mikropakalpojumus, komandas ir jārīko pa biznesa iespējām (pasūtījumu, piegādes, kataloga komanda). Šāda organizācija ļaus komandām koncentrēties uz konkrētu aplikācijas daļu izveidi.

Produkti, nevis projekti (Products not Projects)

Projektu pieeja, kurā komanda nodod izstrādāto funkcionalitāti citām komandām mikropakalpojumu arhitektūras gadījumā, ir pilnīgi nepiemērota. Komanda jāatbalsta sistēmas dzīves cikla laikā. Amazon, viens no vadošajiem mikropakalpojumu ieviešanas uzņēmumiem, ir apgalvojusi: „jūs izstrādājat produktu, un jūs to arī palaidīsiet” ("you build, you run it"). Produktu pieeja ļauj komandai sajust biznesa vajadzības.

Gudras ieejas punkti un muļķīgi caurules (Smart endpoints and dumb pipes)

SOA arhitektūra pievērsa lielu uzmanību sakaru kanāliem, īpaši Enterprise Service Bus (uzņēmuma pakalpojumu autobuss). Tas bieži noved pie Erroneous Spaghetti Box, tas ir, monolīta sarežģītība pāriet uz sarežģītību starp pakalpojumiem. Mikropakalpojumu arhitektūrā tiek izmantotas tikai vienkāršas mijiedarbības metodes.

Decentralizēta pārvaldība (Decentralized Governance)

Galvenos lēmums par mikropakalpojumiem jāpieņem cilvēkiem, kuri tiešām izstrādā mikropakalpojumus. Šeit ar galvenajiem lēmumiem saprot izvēli
programmēšanas valodām, izvietošanas metodoloģijām, publisko interfeisu līgumiem utt.

Decentralizēta datu pārvaldība (Decentralized Data Management)

Standarta pieeja, kurā lietojumprogramma balstās uz vienu datu bāzi, nevar ņemt vērā katra konkrētā pakalpojuma specifiku. MSA paredz decentralizētu datu pārvaldību, pat izmantojot dažādas tehnoloģijas.

Infrastruktūras automatizācija (Infrastructure Automation)

MSA atbalsta nepārtrauktas izvietošanas un piegādes procesus. To var īstenot tikai automatizējot procesus. Šādā veidā vairāku pakalpojumu izvietošana vairs neizskatās biedējoši. Izvietošanas process jāpadara garlaicīgs. Otrais aspekts ir saistīts ar pakalpojumu pārvaldību produktu vidē. Bez automatizācijas procesu pārvaldība, kas tiek uzsākta dažādās darba vidēs, kļūst neiespējama.

Dizains neveiksmēm (Design for failure)

Daudzās MSA pakalpojumos ir iespējami traucējumi. Turklāt, kļūdu apstrāde sadalītā sistēmā ir visai ne triviala uzdevums. Lietojumprogrammu arhitektūrai jābūt izturīgai pret šādiem traucējumiem. Rebeka Parsonsa uzskata, ka ir ļoti svarīgi, ka mēs vairs neizmantojam pat iekšprocesu mijiedarbību starp pakalpojumiem, bet vietā tā vietā mēs izmantojam HTTP, kas nemaz nav tik uzticams.

Evolūcijas strūktūras arhitektūra (Evolutionary Design)

MSA sistēmas arhitektūrai jāattīstās evolūcijas ceļā. Vēlams ierobežot nepieciešamās izmaiņas viena pakalpojuma robežās. Tāpat ir jāņem vērā ietekme uz citiem pakalpojumiem. Tradicionālais piegājiens ir mēģināt šo problēmu risināt, izmantojot versiju vadību, bet MSA paredz izmantot versiju vadību kā
galējo līdzekli.

Secinājums

Pēc visa iepriekš minētā var formulēt, kas ir mikropakalpojumi. Mikropakalpojumu arhitektūra ir pieeja, kas paredz izstrādāt atsevišķu lietojumprogrammu kā maza pakalpojumu komplektu, no kuriem katrs darbojas savā procesā un savstarpēji mijiedarbojas, izmantojot vieglus mehānismus, bieži HTTP resursu API interfeisu. Šie pakalpojumi ir būvēti uz biznesa iespējām un var tikt izvietoti neatkarīgi, izmantojot pilnībā
automātizētu izvietošanas mehānismu. Pastāv minimāls centralizētas vadības līmenis šo pakalpojumu pārvaldībā, kas var tikt rakstīti dažādās programmēšanas valodās un izmantot dažādas datu uzglabāšanas tehnoloģijas.