Pozdrav, Habr. Danas nastavljam seriju objava koju sam napisao posebno za početak novog toka tečaja .
Uvod
Odabir arhitektonskog stila predstavlja jedno od temeljnih tehničkih rješenja prilikom izgradnje informacijskog sustava. U ovoj seriji članaka predlažem da proučimo najpopularnije arhitektonske stilove izgradnje aplikacija i odgovorimo na pitanje kada je koji arhitektonski stil najpoželjniji. Tijekom izlaganja pokušat ću izvesti logički slijed koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.
Posljednji put smo razgovarali o različitim vrstama monolita i upotrebi komponenti za njihovo izgradnju, uključujući kako komponente za sastavljanje, tako i komponente za implementaciju. Istražili smo arhitekturu orijentiranu na usluge.
Sada ćemo konačno definirati osnovne karakteristike mikroservisne arhitekture.
Odnos arhitektura
Važno je razumjeti da, prema podacima iz prethodnih članaka, svaka usluga predstavlja komponentu, ali nije svaka usluga mikroservis.
Karakteristike mikroservisne arhitekture
Osnovne karakteristike mikroservisne arhitekture su:
- Organizacija prema poslovnim mogućnostima (Organized around Business Capabilities)
- Proizvodi, a ne projekti (Products not Projects)
- Pametne ulazne točke i glupi kanali (Smart endpoints and dumb pipes)
- Decentralizirano upravljanje (Decentralized Governance)
- Decentralizirano upravljanje podacima (Decentralized Data Management)
- Automatizacija infrastrukture (Infrastructure Automation)
- Osiguranje od kvarova (Design for failure)
- Arhitektura s evolucijskim razvojem (Evolutionary Design)
Prva stavka dolazi iz arhitekture orijentirane na usluge, jer su mikroservisi posebni slučajevi usluga. Ostale stavke zaslužuju posebno razmatranje.
Organizacija prema poslovnim mogućnostima (Organized around Business Capabilities)
Sada je potrebno prisjetiti se Conwayevog zakona: organizacije koje stvaraju sustave organiziraju njihovu arhitekturu koja odražava strukturu interakcije unutar tih organizacija. Kao primjer, možemo se prisjetiti izrade kompajlera: tim od sedam ljudi razvio je sedmoprocenatni kompajler, dok je tim od pet napravio petoprocentni.
Ako govorimo o monolitima i mikroservisima, onda, ako je razvoj organiziran prema funkcionalnim odjelima (back-end, front-end, administratori baza podataka), to rezultira klasičnim monolitom.
Za izradu mikroservisa, timove treba organizirati prema poslovnim mogućnostima (timovi za narudžbe, otpreme, kataloge). Ova organizacija omogućava timovima da se fokusiraju na izradu specifičnih dijelova aplikacije.
Proizvodi, a ne projekti (Products not Projects)
Projektni pristup pri kojem tim predaje razvijenu funkcionalnost drugim timovima u kontekstu mikroservisne arhitekture potpuno je neprikladan. Tim mora podržavati sustav tijekom cijelog njegovog životnog ciklusa. Tvrtka Amazon, jedan od pionira u implementaciji mikroservisa, istaknula je: 'vi kreirate proizvod, a vi ga i pokrećete' ('you build, you run it'). Proizvodni pristup omogućava timu da osjeti potrebe poslovanja.
Pametne ulazne točke i glupi kanali (Smart endpoints and dumb pipes)
SOA arhitektura posvećivala je veliku pažnju komunikacijskim kanalima, posebno Enterprise Service Bus-u (servisna šina poduzeća). To često dovodi do Erroneous Spaghetti Box, tj. složenost monolita prelazi u složenost veza između servisa. U mikroservisnoj arhitekturi koriste se samo jednostavni načini interakcije.
Decentralizirano upravljanje (Decentralized Governance)
Ključne odluke o mikroservisima trebaju donositi ljudi koji zaista razvijaju mikroservise. Ovdje se pod ključnim odlukama misli na izbor
programskih jezika, metodologije implementacije, javnih interfejsa itd.
Decentralizirano upravljanje podacima (Decentralized Data Management)
Standardni pristup, u kojem aplikacija oslanja na jednu bazu podataka, ne može uzeti u obzir specifičnosti svakog pojedinog servisa. MSA predviđa decentralizirano upravljanje podacima, do upotrebe različitih tehnologija.
Automatizacija infrastrukture (Infrastructure Automation)
MSA podržava procese kontinuirane implementacije i isporuke. To se može ostvariti jedino automatizacijom procesa. Pri tome, implementacija velikog broja servisa više ne izgleda zastrašujuće. Proces implementacije trebao bi postati rutinski. Drugi aspekt odnosi se na upravljanje servisima u proizvodnom okruženju. Bez automatizacije, upravljanje procesima pokrenutima u različitim operativnim okruženjima postaje nemoguće.
Osiguranje od kvarova (Design for failure)
Brojni servisi MSA su podložni kvarovima. Pri tome, obrada grešaka u distribuiranom sustavu nije trivijalna zadaća. Arhitektura aplikacija mora biti otporna na takve kvarove. Rebecca Parsons smatra vrlo važnim da više ne koristimo čak ni međuprocesnu interakciju između servisa; umjesto toga, za vezu se oslanjamo na HTTP, koji nikako nije toliko pouzdan.
Arhitektura s evolucijskim razvojem (Evolutionary Design)
Arhitektura MSA sustava mora se razvijati evolutivno. Poželjno je ograničiti potrebne promjene granicama jedne usluge. Također je važno uzeti u obzir utjecaj na druge usluge. Tradicionalni pristup sastoji se u pokušaju rješavanja ovog problema pomoću upravljanja verzijama, ali MSA podrazumijeva korištenje upravljanja verzijama kao
krajnje mjere.
Zaključak
Nakon svega rečenog, možemo formulirati što su mikrosustavi. Mikrosustavna arhitektura je pristup razvoju pojedinačne aplikacije u obliku seta malih usluga, od kojih svaka radi u svom vlastitom procesu i međusobno komunicira putem pojednostavljenih mehanizama, često API-interfejsom HTTP resursa. Ove usluge su izgrađene na poslovnim mogućnostima i mogu se neovisno implementirati pomoću potpuno
automatiziranog mehanizma implementacije. Postoji minimalna razina centraliziranog upravljanja ovim uslugama, koje mogu biti napisane na različitim programskim jezicima i koristiti različite tehnologije pohrane podataka.
Izvor: habr.com
