Pozdrav, Habr. Danas nastavljam niz publikacija koje sam napisao posebno za početak novog toka tečaja. .
Uvod
Odabir arhitektonskog stila jedna je od temeljnih tehničkih odluka pri izgradnji informacijskog sustava. U ovoj seriji članaka predlažem analizu najpopularnijih arhitektonskih stilova za primjenu u građevinarstvu i odgovor na pitanje kada je koji arhitektonski stil najpoželjniji. U procesu izlaganja pokušat ću povući logičan lanac koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.
Prošli put smo govorili o različitim vrstama monolita i upotrebi komponenti za njihovu izgradnju, komponenti za izgradnju i komponenti za implementaciju. Razumijemo arhitekturu usmjerenu na usluge.
Sada ćemo konačno definirati glavne karakteristike arhitekture mikroservisa.
Odnos arhitektura
Potrebno je razumjeti da je na temelju definicija navedenih u prethodnim člancima svaka usluga komponenta, ali nije svaka usluga mikrousluga.
Karakteristike mikroservisne arhitekture
Glavne karakteristike mikroservisne arhitekture su:
- Organizirani oko poslovnih mogućnosti
- Proizvodi, a ne projekti
- Pametne krajnje točke i glupe cijevi
- Decentralizirano upravljanje
- Decentralizirano upravljanje podacima
- Automatizacija infrastrukture
- Dizajn za neuspjeh
- Arhitektura s evolucijskim razvojem (Evolutionary Design)
Prva točka dolazi iz servisno orijentirane arhitekture jer su mikroservisi poseban slučaj servisa. Ostale točke zaslužuju zasebno razmatranje.
Organizirani oko poslovnih mogućnosti
Sada se treba sjetiti Conwayeva zakona: organizacije koje stvaraju sustave organiziraju svoju arhitekturu, kopirajući strukturu interakcije unutar tih organizacija. Kao primjer, možemo se prisjetiti slučaja stvaranja prevoditelja: tim od sedam ljudi razvio je prevoditelj sa sedam prolaza, a tim od petero je razvio prevoditelj s pet prolaza.
Ako govorimo o monolitima i mikroservisima, onda ako je razvoj organiziran po funkcionalnim odjelima (backend, frontend, administratori baza podataka), tada dobivamo klasični monolit.
Za dobivanje mikroservisa, timovi moraju biti organizirani prema poslovnoj sposobnosti (narudžbe, pošiljke, tim za katalog). Ova će organizacija omogućiti timovima da se usredotoče na izgradnju određenih dijelova aplikacije.
Proizvodi, a ne projekti
Projektni pristup u kojem tim prenosi razvijenu funkcionalnost drugim timovima potpuno je neprikladan u slučaju mikroservisne arhitekture. Tim mora podržavati sustav tijekom njegovog životnog ciklusa. Amazon, jedan od predvodnika u implementaciji mikroservisa, izjavio je: “vi gradite, vi to pokrećete”. Pristup proizvodu omogućuje timu da osjeti potrebe poslovanja.
Pametne krajnje točke i glupe cijevi
SOA arhitektura veliku je pozornost posvetila komunikacijskim kanalima, posebice Enterprise Service Bus-u. Što često dovodi do Erroneous Spaghetti Boxa, odnosno kompleksnost monolita prelazi u kompleksnost povezivanja servisa. Arhitektura mikroservisa koristi samo jednostavne komunikacijske metode.
Decentralizirano upravljanje
Ključne odluke o mikrouslugama trebaju donositi ljudi koji zapravo razvijaju mikrousluge. Ovdje ključne odluke znače izbore
programski jezici, metodologija postavljanja, ugovori o javnom sučelju itd.
Decentralizirano upravljanje podacima
Standardni pristup, u kojem se aplikacija oslanja na jednu bazu podataka, ne može uzeti u obzir specifičnosti svake pojedine usluge. MSA uključuje decentralizirano upravljanje podacima, uključujući korištenje različitih tehnologija.
Automatizacija infrastrukture
MSA podržava stalne procese implementacije i isporuke. To se može postići samo automatizacijom procesa. U isto vrijeme, implementacija velikog broja usluga više ne izgleda kao nešto zastrašujuće. Proces implementacije trebao bi postati dosadan. Drugi aspekt se odnosi na upravljanje uslugama u okruženju proizvoda. Bez automatizacije, upravljanje procesima koji se izvode u različitim operativnim okruženjima postaje nemoguće.
Dizajn za neuspjeh
Brojne MSA usluge sklone su kvarovima. U isto vrijeme, rukovanje greškama u distribuiranom sustavu nije trivijalan zadatak. Arhitektura aplikacije mora biti otporna na takve kvarove. Rebecca Parsons smatra da je vrlo važno da više ne koristimo niti komunikaciju unutar procesa između usluga; umjesto toga pribjegavamo HTTP-u za komunikaciju, koji nije ni približno pouzdan.
Arhitektura s evolucijskim razvojem (Evolutionary Design)
Arhitektura MSA sustava trebala bi se razvijati evolucijski. Preporučljivo je ograničiti potrebne promjene na granice jedne usluge. Mora se uzeti u obzir i utjecaj na druge usluge. Tradicionalni pristup je pokušati riješiti ovaj problem s verzijama, ali MSA predlaže korištenje verzija u
u krajnjem slučaju.
Zaključak
Nakon svega navedenog možemo formulirati što su mikroservisi. Arhitektura mikroservisa je pristup razvoju jedne aplikacije kao skupa malih usluga, od kojih svaka radi u svom procesu i međusobno djeluje kroz lagane mehanizme, često API-je HTTP resursa. Ove usluge izgrađene su na poslovnim mogućnostima i mogu se samostalno implementirati u potpunosti
automatizirani mehanizam postavljanja. Postoji minimalna razina centraliziranog upravljanja ovim uslugama, koje mogu biti napisane u različitim programskim jezicima i koristiti različite tehnologije pohrane podataka.
Izvor: www.habr.com