Skoraj vsak računalniški sistem izvaja več nalog z uporabo skupnih virov, eno od vprašanj računalniškega programiranja pa je, kako tesno bi morali biti bitni deli kode, ki izvajajo te naloge, povezani. Vse bolj priljubljen odgovor je koncept mikro storitve—majhen, ločen del funkcije, ki v interakciji z drugimi mikro storitvami ustvarja večji sistem.
Čeprav osnovna ideja o takšnih ločenih komponentah ni nova, pa jih način uporabe mikro storitev pomeni naravni temelj za sodobne aplikacije v oblaku. Mikroservice so prav tako povezane s filozofijo devops, ki spodbuja hitro in nenehno uvajanje nove funkcionalnosti.
Kaj so mikro storitve?
"Mikro" v mikro storitvah pomeni, da gre za majhne aplikacije. To je včasih res, toda boljši način razmišljanja o njih je, da morajo biti veliki le toliko, kolikor je potrebno, da naredijo določeno stvar ali rešijo določeno težavo. Ta težava bi morala biti konceptualna in ne tehnična. Kot pravi Microsoft, "bi morale biti mikro storitve zasnovane na poslovnih zmožnostih, ne pa na vodoravnih plasteh, kot sta dostop do podatkov ali pošiljanje sporočil." Za ustvarjanje večje aplikacije komunicirajo z drugimi mikrostoritvami in zunanjimi uporabniki prek razmeroma stabilnih API-jev.
Tako je mogoče notranjo funkcionalnost posamezne mikrostoritve prilagoditi ali korenito nadgraditi, ne da bi to vplivalo na preostali del sistema. To pa je povezano s tem, kako poskušajo poslovati trgovine devops: Če so posebne funkcije večje aplikacije razdeljene na diskretne, neodvisno delujoče kose kode, je lažje živeti manto devopsa o CI / CD (stalna integracija in neprekinjena dostava) . Prav tako natančno definirani API-ji omogočajo enostavno samodejno preskušanje mikro storitev.
Arhitektura mikro storitev proti monolitni arhitekturi
Pogosto boste slišali, da se o mikro storitvah govori v smislu "arhitekture mikro storitev".” Ta besedna zveza ne zajema samo mikrostoritev, temveč tudi komponente za upravljanje in odkrivanje storitev ter prehod API, ki ureja komunikacijo med mikro storitvami in zunanjim svetom.
"Monolitna aplikacija" je nasprotno od tega, kar so mikro storitve. Je retron za aplikacijo, kjer je vsa koda v eni veliki binarni izvedljivi datoteki. Kot pojasnjuje TechTarget, je monolitno aplikacijo težje prilagoditi in težje izboljšati. Ker pa je zgrajena kot ena kohezivna aplikacija, ne zahteva toliko upravljanja kot arhitektura mikro storitev.
Omejeni koncepti: Kako definirati mikrostoritev
Za trenutek se vrnimo k prejšnji zapovedi, da bi morale mikro storitve storiti eno določeno stvar. To je lahko reči, toda v praksi se funkcionalnost pogosto preplete in risanje delitev je težje, kot se zdi. Analiza domene in zasnova, zasnovana na domeni, sta teoretična pristopa, ki vam bosta pomagala, da svojo nalogo velike slike razdelite na posamezne probleme, ki jih lahko reši mikrostoritev. V tem postopku, ki je opisan v osvetljeni seriji Microsoftovih objav v blogu, ustvarite abstraktni model svoje poslovne domene in v tem procesu odkrijete omejeni kontekst, ki združujejo funkcionalnost, ki na poseben način komunicira s svetom.
Na primer, morda imate en omejen kontekst za pošiljanje in drugega za račune. Realni fizični predmet bi seveda imel ceno in kraj, kamor bi moral iti, vendar omejeni konteksti predstavljajo posebne načine, na katere vaša aplikacija razmišlja o teh predmetih in komunicira z njimi. Vsaka mikro storitev mora obstajati v celoti v enem samem omejenem kontekstu, čeprav lahko nekateri omejeni konteksti zajemajo več kot eno mikro storitev.
Mikro storitve proti arhitekturi, usmerjeni v storitve, in storitve v spletu
Če ste trenutno strokovnjak za informacijsko tehnologijo, ki se že nekaj časa ukvarja s panogo, se vam morda zdi, da se veliko tega sliši znano. Zamisel o majhnih posameznih programih, ki delujejo skupaj, vas lahko spomni tako na SOA (storitveno usmerjena arhitektura) kot na spletne storitve, dve modni besedi iz napetega spleta 2.0 dni 2000-ih. Čeprav v nekem smislu pod soncem res ni nič novega, obstajajo pomembne razlike med temi pojmi in mikro storitvami. Razlikovanje podatkov ima dobro razčlenitev podatkov, a tukaj je kratka različica:
- V storitveno usmerjeni arhitekturi so posamezne komponente sorazmerno tesno povezane, pogosto si delijo sredstva, kot je shramba, in komunicirajo prek dela posebne programske opreme, imenovane poslovno vodilo za shranjevanje. Mikroservisi so bolj neodvisni, delijo manj virov in komunicirajo prek lažjih protokolov. Omeniti velja, da so mikro storitve nastale iz okolja SOA in se včasih štejejo za neke vrste SOA ali naslednike koncepta.
- Spletna storitev je nabor funkcionalnosti, do katerih lahko druge aplikacije dostopajo prek spleta; Verjetno najbolj razširjen primer je Google Maps, ki bi ga spletno mesto restavracije lahko vdelalo, da bi strankam nudilo navodila. To je veliko bolj ohlapna povezava, kot bi jo videli v arhitekturi mikro storitev.
Komunikacija mikro storitev
Krilatica, ki jo boste pogosto slišali o arhitekturah mikro storitev, je, da bi morale vsebovati "pametne končne točke in neumne cevi". Z drugimi besedami, mikro storitve naj bi namesto zapletene in tesne integracije uporabljale osnovne in dobro uveljavljene komunikacijske metode. Kot smo že omenili, je to še ena stvar, ki razlikuje mikrostoritve od SOA.
Na splošno mora biti komunikacija med mikro storitvami asinhrona, v smislu, da niti kode niso blokirane v čakanju na odgovore. (Še vedno je v redu uporabljati sinhrone komunikacijske protokole, kot je HTTP, čeprav so asinhroni protokoli, kot je AMQP (Advanced Message Queuing Protocol), pogosti tudi v arhitekturah mikroservisov.) Tovrstno ohlapno povezovanje naredi arhitekturo mikro storitev bolj prožno v primeru okvare posameznih komponent ali delov omrežja, kar je ključna prednost.
Microservices, Java in Spring Boot in Spring Cloud
Nekatera prva dela v zvezi z mikro storitvami so nastala v skupnosti Java; Martin Fowler je bil zgodnji zagovornik. Na konferenci Java leta 2012 na Poljskem je bila predstavljena ena najpomembnejših zgodnjih predstavitev na to temo z naslovom »Mikro storitve - Java, Unixova pot.« Priporočila je uporabo načel, ki so vodila razvoj prvih Unixovih aplikacij v sedemdesetih letih (»Napišite programi, ki delajo eno stvar in to dobro. Napišite programe za sodelovanje ") za razvoj Jave.
Kot rezultat te zgodovine je na voljo veliko ogrodja Java, ki vam omogočajo izdelavo mikro storitev. Eden izmed najbolj priljubljenih je Spring Boot, ki je posebej zasnovan za mikro storitve; Zagon je razširjen s storitvijo Spring Cloud, ki vam, kot že ime pove, omogoča, da te storitve razporedite tudi v oblak. Pivotal Software, razvijalec Spring, ima dobro vadnico o tem, kako začeti z razvojem mikro storitev s pomočjo teh okvirov.
Mikroservice in posode: Docker, Kubernetes in druge
Osnovna tehnologija, ki je šla najbolj daleč do vstopa mikro storitev v osrednji tok, so zabojniki. Vsebnik je podoben primerku VM, vendar je vsebnik namesto, da bi vključeval celoten samostojni OS, samo izoliran uporabniški prostor, ki uporablja jedro gostiteljskega operacijskega sistema, sicer pa kodo, ki se v njej izvaja, deluje samostojno. Posode so veliko manjše od primerkov VM in jih je enostavno hitro uvesti, bodisi lokalno bodisi v oblaku, in jih je mogoče zavrteti navzgor ali navzdol, da se ujemajo s povpraševanjem in razpoložljivimi viri.
Privlačnost vsebnikov za mikro storitve bi morala biti očitna: vsaka posamezna mikro storitev lahko deluje v svojem vsebniku, kar bistveno zmanjša režijske stroške upravljanja storitev. Večina izvedb vsebnikov ima dopolnilna orodja za orkestracijo, ki avtomatizirajo uvajanje, upravljanje, spreminjanje velikosti, mreženje in razpoložljivost aplikacij na osnovi vsebnikov. Kombinacija majhnih, enostavnih mikro storitev in vsebnikov, ki jih je enostavno namestiti, omogoča filozofijo devops. Obstaja več izvedb koncepta vsebnika, daleč najbolj priljubljen pa je Docker, ki je na splošno v povezavi s Kubernetesom kot platforma za orkestracijo.
Pomlad je sicer priljubljena, vendar je vezana na platformo Java. Sistemi, ki temeljijo na vsebnikih, pa so poligloti: Vsak programski jezik, ki ga podpira OS, se lahko izvaja v vsebniku, kar daje večjo prilagodljivost programerjem. Dejansko je velika prednost mikro storitev v tem, da je vsako posamezno storitev mogoče napisati v katerem koli jeziku, ki je najbolj smiseln, ali da je razvijalcem najbolj všeč. Dejansko bi bilo mogoče storitev popolnoma obnoviti v novem jeziku, ne da bi to vplivalo na sistem kot celoto, če so njeni API-ji stabilni. DZone ima članek, ki razpravlja o prednostih in slabostih Spring Cloud proti Kubernetesu za mikro storitve.
Vzorci oblikovanja mikro storitev
Ne glede na jezik, ki ga uporabljate za razvoj mikro storitev, se boste srečevali s težavami, s katerimi so se že srečevali drugi razvijalci. Vzorci oblikovanja so formalizirani, abstraktne rešitve ponavljajočih se problemov v računalništvu in številni izmed njih so posebej namenjeni mikro storitvam. Devopedia ima odličen seznam, ki vključuje:
- Service Registry: za povezovanje odjemalcev z razpoložljivimi primerki mikro storitev
- Circuit Breaker: za preprečevanje ponavljajočih se klicev neuspešnih storitev
- Nadomestni: za zagotavljanje alternative neuspeli storitvi
- Sidecar: za zagotavljanje pomožne storitve glavnemu zabojniku, na primer za beleženje, sinhronizacijo ali nadzor
- Adapter: za standardizacijo ali normalizacijo vmesnika med glavnim vsebnikom in zunanjim svetom
- Veleposlanik: za povezavo glavnega vsebnika z zunanjim svetom, na primer za posredovanje povezav localhost z zunanjimi povezavami
Mikro storitve in oblak: AWS in Azure
Kot smo že omenili, je ena od prednosti uporabe vsebnikov ta, da jih je mogoče enostavno namestiti v oblak, kjer so na voljo prilagodljivi računski viri, da lahko povečate učinkovitost svoje aplikacije. Kot si lahko predstavljate, so vsi glavni ponudniki javnih oblakov nestrpni, da na njihovih platformah zaženete aplikacije, ki temeljijo na mikro storitvah. Za več informacij si oglejte vire Amazon, Microsoft in Google.
