Zdravo, Habr. Danas nastavljam niz publikacija koje sam napisao posebno za početak novog toka kursa. .
Uvod
Izbor arhitektonskog stila jedna je od temeljnih tehničkih odluka prilikom izgradnje informacionog sistema. U ovoj seriji članaka predlažem da analiziram najpopularnije arhitektonske stilove za građevinske aplikacije i odgovorim na pitanje kada je koji arhitektonski stil najpoželjniji. U procesu prezentacije pokušaću da nacrtam logički lanac koji objašnjava razvoj arhitektonskih stilova od monolita do mikroservisa.
Prošli put smo govorili o različitim tipovima monolita i upotrebi komponenti za njihovu izgradnju, kako komponenti za izgradnju tako i komponenti za implementaciju. Razumijemo arhitekturu orijentiranu na usluge.
Sada ćemo konačno definirati glavne karakteristike mikroservisne arhitekture.
Odnos arhitektura
Neophodno je shvatiti da na osnovu definicija datih u prethodnim člancima, svaka usluga je komponenta, ali nije svaka usluga mikroservis.
Karakteristike mikroservisne arhitekture
Glavne karakteristike mikroservisne arhitekture su:
- Organizirano oko poslovnih mogućnosti
- Proizvodi ne projekti
- Pametne krajnje tačke i glupe cijevi
- Decentralizovano upravljanje
- Decentralizovano upravljanje podacima
- Infrastrukturna automatizacija
- Dizajn za neuspjeh
- Arhitektura s evolucijskim razvojem (Evolutionary Design)
Prva tačka dolazi iz uslužno orijentisane arhitekture jer su mikroservise poseban slučaj usluga. Ostale tačke zaslužuju posebno razmatranje.
Organizirano oko poslovnih mogućnosti
Sada je potrebno zapamtiti Conwayev zakon: organizacije koje kreiraju sisteme organizuju svoju arhitekturu, kopirajući strukturu interakcije unutar ovih organizacija. Kao primjer, možemo se prisjetiti slučaja kreiranja kompajlera: tim od sedam ljudi razvio je kompajler sa sedam prolaza, a tim od pet je razvio kompajler sa pet prolaza.
Ako govorimo o monolitima i mikroservisima, onda ako razvoj organiziraju funkcionalni odjeli (backend, frontend, administratori baze podataka), onda se dobija klasični monolit.
Za dobijanje mikrousluga, timovi moraju biti organizovani prema poslovnim sposobnostima (porudžbine, pošiljke, kataloški tim). Ova organizacija će omogućiti timovima da se fokusiraju na izgradnju određenih dijelova aplikacije.
Proizvodi ne projekti
Projektni pristup u kojem tim prenosi razvijenu funkcionalnost na druge timove potpuno je neprikladan u slučaju mikroservisne arhitekture. Tim mora podržavati sistem tokom njegovog životnog ciklusa. Amazon, jedan od lidera u implementaciji mikrousluga, izjavio je: „gradiš, ti to pokrećeš“. Pristup proizvoda omogućava timu da osjeti potrebe poslovanja.
Pametne krajnje tačke i glupe cijevi
SOA arhitektura je posvetila veliku pažnju komunikacijskim kanalima, posebno Enterprise Service Bus-u. Što često dovodi do pogrešne kutije za špagete, odnosno složenost monolita pretvara se u složenost veza između usluga. Mikroservisna arhitektura koristi samo jednostavne metode komunikacije.
Decentralizovano upravljanje
Ključne odluke o mikroservisima treba da donose ljudi koji zapravo razvijaju mikroservise. Ovdje ključne odluke znače izbore
programskih jezika, metodologije implementacije, ugovora o javnom interfejsu, itd.
Decentralizovano upravljanje podacima
Standardni pristup, u kojem se aplikacija oslanja na jednu bazu podataka, ne može uzeti u obzir specifičnosti svake određene usluge. MSA uključuje decentralizirano upravljanje podacima, uključujući korištenje različitih tehnologija.
Infrastrukturna automatizacija
MSA podržava kontinuirane procese implementacije i isporuke. To se može postići samo automatizacijom procesa. Istovremeno, implementacija velikog broja usluga više ne izgleda kao nešto strašno. Proces implementacije bi trebao postati dosadan. Drugi aspekt se odnosi na upravljanje uslugama u proizvodnom okruženju. Bez automatizacije, upravljanje procesima koji rade u različitim operativnim okruženjima postaje nemoguće.
Dizajn za neuspjeh
Brojne MSA usluge su podložne neuspjehu. Istovremeno, rukovanje greškama u distribuiranom sistemu nije trivijalan zadatak. Arhitektura aplikacije mora biti otporna na takve kvarove. Rebecca Parsons smatra da je veoma važno da više čak i ne koristimo komunikaciju u procesu između servisa; umjesto toga, za komunikaciju pribjegavamo HTTP-u, koji nije ni približno tako pouzdan.
Arhitektura s evolucijskim razvojem (Evolutionary Design)
Arhitektura MSA sistema treba da se razvija evolutivno. Preporučljivo je ograničiti potrebne promjene na granice jedne usluge. Mora se uzeti u obzir i uticaj na druge usluge. Tradicionalni pristup je pokušaj rješavanja ovog problema pomoću verzioniranja, ali MSA predlaže korištenje verzija u
kao poslednje sredstvo.
zaključak
Nakon svega navedenog, možemo formulirati šta su mikroservise. Mikroservisna arhitektura je pristup razvoju jedne aplikacije kao kolekcije malih usluga, od kojih svaka radi u svom vlastitom procesu i u interakciji je kroz lagane mehanizme, često API-je za HTTP resurse. Ove usluge su izgrađene na poslovnim sposobnostima i mogu se implementirati nezavisno koristeći se u potpunosti
automatizovani mehanizam implementacije. Postoji minimalni nivo centralizovanog upravljanja ovim servisima, koji se mogu pisati na različitim programskim jezicima i koristiti različite tehnologije skladištenja podataka.
izvor: www.habr.com