🥇Odabir arhitektonskog stila (dio 3)

Pozdravljen, Habr. Danes nadaljujem s serijo objav, ki sem jih napisal posebej ob začetku novega tečaja. «Software Architect».

Uvod

Odabir arhitektonskog stila jedan je od osnovnih tehničkih rešenja pri izgradnji informacionog sistema. U ovoj seriji članaka predlažem da razmotrimo najpopularnije arhitektonske stilove izgradnje aplikacija i odgovorimo na pitanje kada je koji arhitektonski stil najprikladniji. Tokom izlaganja ću pokušati da sprovedem logički sled koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.

Nazadnje smo govorili o različnih vrstah monolitov in o uporabi komponent za njihovo gradnjo, tako komponent za sestavljanje kot komponent za uvajanje. Poglobljeno smo se ukvarjali s storitveno usmerjeno arhitekturo.

Zdaj bomo končno opredelili osnovne značilnosti mikrostoritvene arhitekture.

Odnos arhitektur

Treba je razumeti, da na podlagi podatkov iz prejšnjih člankov vsak storitev predstavlja komponento, vendar ne vsaka storitev je mikrostoritev.

Značilnosti mikrostoritvene arhitekture

Osnovne značilnosti mikrostoritvene arhitekture so:

Organizirano okoli poslovnih zmožnosti (Organized around Business Capabilities)
Projekti, ne izdelki (Products not Projects)
Pametne točke dostopa in neumne cevi (Smart endpoints and dumb pipes)
Decentralizirano upravljanje (Decentralized Governance)
Decentralizirano upravljanje podatkov (Decentralized Data Management)
Avtomatizacija infrastrukture (Infrastructure Automation)
Zavarovanje pred napakami (Design for failure)
Arhitektura z evolucijskim razvojem (Evolutionary Design)

1. točka izhaja iz storitveno usmerjene arhitekture, saj so mikrostoritve posebna oblika storitev. Druge točke si zaslužijo ločeno obravnavo.

Organizirano okoli poslovnih zmožnosti (Organized around Business Capabilities)

Zdaj je treba pomniti Conwayev zakon: organizacije, ki ustvarjajo sisteme, oblikujejo njihovo arhitekturo tako, da posnema strukturo interakcij znotraj teh organizacij. Kot primer lahko navedemo primer razvoja prevajalnika: ekipa sedmih ljudi je razvila sedemprehodni prevajalnik, medtem ko je ekipa petih naredila petprehodnega.

Če govorimo o monolitih in mikrostoritvah, je pri organizaciji razvoja po funkcionalnih oddelkih (ozadje, sprednji del, skrbniki podatkovnih baz) rezultat klasičen monolit.

Za pridobitev mikrostoritev je treba ekipe organizirati okoli poslovnih zmožnosti (ekipa naročil, odpreme, kataloga). Takšna organizacija bo omogočila ekipam, da se osredotočijo na razvoj konkretnih delov aplikacije.

Projekti, ne izdelki (Products not Projects)

Projektni pristop, pri katerem ekipa prenese razvito funkcionalnost drugim ekipam v primeru mikrostoritvenih arhitektur, ne deluje dobro. Ekipa mora podpirati sistem skozi celotno njegovo življenjsko dobo. Podjetje Amazon, eden izmed vodilnih v uvajanju mikrostoritev, je izjavil: „zgradite izdelek in ga tudi zaženite“ (angl. „you build, you run it“). Pristop k izdelku omogoča ekipi, da začuti potrebe poslovanja.

Pametne točke dostopa in neumne cevi (Smart endpoints and dumb pipes)

Arhitektura SOA je velik poudarek dajala komunikacijskim kanalom, še posebej Enterprise Service Bus (servisna šina podjetja). Kar pogosto pripelje do Erroneous Spaghetti Box, torej kompleksnost monolita se pretvori v kompleksnost povezav med storitvami. V mikrostoritveni arhitekturi se uporabljajo samo preprosti načini interakcije.

Decentralizirano upravljanje (Decentralized Governance)

Ključne odločitve o mikrostoritvah morajo sprejemati ljudje, ki dejansko razvijajo mikrostoritve. Tukaj pod ključnimi odločitvami razumemo izbiro
programskih jezikov, metodologije uvajanja, pogodb javnih vmesnikov itd.

Decentralizirano upravljanje podatkov (Decentralized Data Management)

Standardni pristop, pri katerem se aplikacija zanaša na eno bazo podatkov, ne more upoštevati specifik posameznih storitev. MSA predvideva decentralizirano upravljanje podatkov, vse do uporabe različnih tehnologij.

Avtomatizacija infrastrukture (Infrastructure Automation)

MSA podpira procese neprekinjenega uvajanja in dobave. To je mogoče doseči le z avtomatizacijo procesov. Hkrati uvajanje velikega števila storitev ne deluje več kot strašna naloga. Postopek uvajanja mora postati dolgočasen. Drugi vidik se nanaša na upravljanje storitev v produkcijskem okolju. Brez avtomatizacije postane upravljanje procesov, ki se izvajajo v različnih operativnih okoljih, nemogoče.

Zavarovanje pred napakami (Design for failure)

Številne storitve MSA so podvržene napakam. Hkrati je obravnava napak v razdistributed sistemu precej zapletena naloga. Arhitektura aplikacij mora biti odporna na takšne napake. Rebecca Parsons meni, da je zelo pomembno, da ne uporabljamo niti medprocesne komunikacije med storitvami, temveč za povezovanje uporabljamo HTTP, ki nikakor ni tako zanesljiv.

Arhitektura z evolucijskim razvojem (Evolutionary Design)

Arhitektura MSA sistema se mora razvijati evolutivno. Poželjno je ograničiti potrebne promjene unutar granica jedne usluge. Također je potrebno uzeti u obzir utjecaj na druge usluge. Tradicionalni pristup se sastoji u pokušaju rješavanja ovog problema putem upravljanja verzijama, ali MSA podrazumijeva korištenje upravljanja verzijama u
kao krajnje sredstvo.

Zaključek

Nakon svega rečenog, možemo formulirati što su mikrousluge. Mikrouslužna arhitektura je pristup razvoju zasebne aplikacije u obliku skupa malih usluga, od kojih svaka radi u svom vlastitom procesu i komunicira putem pojednostavljenih mehanizama, često HTTP API sučeljem. Ove usluge su izgrađene na poslovnim prilikama i mogu se neovisno implementirati uz potpuno
automatizirani mehanizam implementacije. Postoji minimalna razina centraliziranog upravljanja ovim uslugama, koje mogu biti napisane na različitim programskim jezicima i koristiti različite tehnologije pohrane podataka.