Implementacija mikroservisov v produkcijskih okoljih

Informatec Digital » Viri » Implementacija mikroservisov v produkcijskih okoljih

Uporaba arhitekture mikroservisov v resničnem okolju ne pomeni le delitve monolita na manjše dele: vključuje ponovno premislite o infrastrukturi, opremi, procesih, podatkih, varnosti in poslovanjuKo sistem preide iz teorije v produkcijsko gručo, se pojavijo težave glede odkrivanja storitev, pogodb med ekipami, CI/CD, opazovalnosti, odpornosti in skalabilnosti, ki, če niso ustrezno obravnavane, mikrostoritve spremenijo v porazdeljen kaos.

Dobra novica je, da imamo danes veliko nabranih izkušenj organizacij, kot so Netflix, Amazon, Google ali velikih korporacij, ki vodijo Na stotine mikroservisov v produkcijiNa podlagi teh spoznanj in najboljših praks v poslovnih okoljih na Kubernetes in OpenShift je mogoče oblikovati zelo dober pristop za načrtovanje, uvajanje in upravljanje mikroservisov v velikem obsegu brez izgube nadzora.

Zakaj uvajati mikroservise v produkcijo (in kdaj se to ne splača)

Dobro zasnovana arhitektura mikroservisov vam omogoča delo z majhne, ​​avtonomne in večfunkcijske ekipe ki prevzamejo odgovornost za celovito storitev. Vsaka ekipa deluje v dobro opredeljenem kontekstu, lahko pogosto uvaja in prevzame polno odgovornost za svojo storitev, kar skrajša čas razvojnega cikla in pospeši dobavo novih funkcij.

Druga ključna prednost je neodvisno skaliranje na storitevČe samo katalog, blagajna ali javni API doživlja porast prometa, vam ni treba preveliko povečati celotne aplikacije. Vsako mikrostoritev lahko prilagodite vodoravno ali navpično glede na njen vzorec obremenitve, natančno izmerite stroške posamezne funkcije in ohranite razpoložljivost, tudi če na določenem območju pride do porasta porabe.

Način, kako so te storitve pakirane in uvedene, olajša neprekinjeno izvajanje z nizkim tveganjemČe je vsaka mikroservis izdana neodvisno, je testiranje novih idej in vračanje problematičnih različic veliko preprostejše: kanarčkove uvedbe, modro/zelene uvedbe in samodejne povrnitve prejšnjih različic zmanjšajo stroške napak in omogočajo prostor za eksperimentiranje.

S tehnološkega vidika mikroservisi spodbujajo svoboda izbire jezikov, ogrodja in podatkovnih baz na storitev. Vse potrebe se ne ujemajo z istim tehnološkim skladom: morda imate poslovne storitve v .NET ali Javi, obdelavo podatkov v Scali/Sparku, specializirane storitve v Pythonu ali F# ali mikrostoritve umetne inteligence v R. Ta nadzorovana raznolikost vam omogoča, da za vsak primer uporabite pravo orodje, ne da bi celotno aplikacijo potegnili v globalno tehnološko spremembo.

Poleg tega razdelitev na majhne, ​​dobro definirane dele olajša ponovna uporaba funkcionalnosti kot gradnikovMikroservis, ki je bil prvotno ustvarjen kot del funkcije, je mogoče kasneje ponovno uporabiti kot odvisnost drugih delov sistema, ne da bi bilo treba prepisati logiko. In ker so storitve izolirane, napaka v eni od njih običajno povzroči delno degradacijo sistema, ne pa popolnega izpada sistema, pod pogojem, da je bila odpornost zasnovana že od samega začetka.

Arhitekturno in storitveno oblikovanje

Da bi mikroservisi dobro delovali v produkciji, morate začeti z skrbna zasnova meja in odgovornosti storitevV praksi se običajno začne z identifikacijo grobozrnatih storitev znotraj obstoječega monolita: velikih funkcionalnih področij ali poslovnih domen (npr. naročila, katalog, uporabniki, obračunavanje), ki že imajo nekaj logične ločitve.

Začenši s temi velikimi bloki, morate izpopolnjevati, dokler ne dobite drobnozrnate mikrostoritve, ki delujejo na koherentnem naboru podatkovImeti bi morali svoj model in natančno vedeti, kaj morajo brati ali pisati drugim storitvam. Ta proces običajno podpirajo koncepti načrtovanja, ki ga poganja domena (DDD), in omejeni konteksti, kar preprečuje, da bi mikrostoritev postala »mini monolit«.

API-ji, ki razkrivajo te storitve, morajo imeti dobro opredeljene in stabilne pogodbeTo vključuje strogo dokumentacijo (REST z OpenAPI, gRPC z datotekami .proto itd.), eksplicitno različicovanje, ohranjanje združljivosti s prejšnjimi različicami, kjer je to mogoče, in avtomatizacijo validacije pogodb za odkrivanje kritičnih sprememb, preden dosežejo produkcijo.

V okoljih z več deset ali več sto storitvami je ključnega pomena, da se vzorci odpornosti vključijo že v fazi načrtovanja, tako da sistem bodite pripravljeni na delne neuspeheVzorci, kot so odklopniki, ponovni poskusi z zamikom, dobro definirane časovne omejitve, pregrade in protitlak, pomagajo preprečiti, da bi okvara ene storitve vplivala na ostale. Orodja za inženiring kaosa, kot sta Chaos Monkey ali Gremlin, se uporabljajo za praktično testiranje delovanja platforme v simuliranih izpadih.

V mnogih kompleksnih sistemih relativno preproste storitve CRUD sobivajo z bolj sofisticiranimi, ki se osredotočajo na spreminjajoča se poslovna pravila. Vse mikrostoritve ne potrebujejo kompleksne notranje arhitektureNekateri so lahko preprosti krmilniki HTTP z osnovnim dostopom do podatkov, drugi, kot je storitev naročil ali obračunavanja, pa lahko izkoriščajo naprednejše vzorce (DDD, CQRS, dogodki domen itd.).

Produkcijska infrastruktura: oblak, kontejnerji in Kubernetes/OpenShift

Izkušnje iz resničnega sveta kažejo, da se mikroservisi veliko bolje prilegajo, če so nameščeni na infrastruktura v oblaku s kontejnerji in orkestracijo kot na izoliranih virtualnih strojih. Platforme, kot sta Kubernetes in OpenShift, zagotavljajo potrebne primitive za pakiranje storitev kot vsebnikov, skaliranje, nadgradnjo, uravnoteženje obremenitve in upravljanje visoke razpoložljivosti.

Običajno je vsaka mikroservis slika embalaže v zabojniku, ki temelji na osnovni sliki podjetja (na primer OpenJDK 21 za storitve Java), ki jih ureja ekipa za infrastrukturo. Ta osnovna slika se posodablja z varnostnimi popravki, in ko je izdana nova različica, so razvojne ekipe odgovorne za obnovo in ponovno uvajanje svojih storitev v ustrezna okolja.

V Kubernetes/OpenShift je osnovna enota za uvajanje pod, ki vsebuje enega ali več vsebnikovObičajno mikroservis ustreza vrsti pod-a in se uvede z uporabo virov, kot so Deployments (za storitve brez stanja) ali StatefulSets (kadar je povezano stanje). Že od samega začetka je določeno minimalno število replik na okolje, tako da imajo testna, predprodukcijska in produkcijska okolja ustrezne ravni razpoložljivosti glede na njihovo kritičnost.

Samodejno skaliranje je implementirano z Horizontalni pod Autoscaler (HPA)To prilagodi število replik na podlagi metrik, kot so CPU, pomnilnik ali druge meritve po meri. Platforma mora konfigurirati tudi pravila za preprečevanje afinitete podov, tako da so replike iste storitve porazdeljene po različnih vozliščih, kar preprečuje, da bi okvara vozlišča ustavila vse instance.

Kar zadeva vertikalno dimenzioniranje, se igra z viri.zahteve in viri.omejitve Za določitev obsega procesorja in pomnilnika, ki ga lahko pod porabi. Na primer, rezervacija najmanj 100 MB procesorja in 256 MB pomnilnika ter omogočanje do 500 MB oziroma 2 GB v storitvi Java, prilagajanje JVM (Xms, Xmx, Xss) za dobro izrabo virov vsebnika.

Upravljanje stanja: mikrostoritve brez stanja in s stanjem

Večina poslovnih mikroservisov je zasnovanih kot storitve brez državljanstvaTo pomeni, da pod ne shranjuje informacij, ki morajo preživeti ponovne zagone; stanje se ohrani v zunanjih bazah podatkov, čakalnih vrstah sporočil ali drugih shrambah. Ta pristop omogoča dinamično horizontalno skaliranje in nemoteno uvajanje, saj lahko vsaka replika obdela katero koli zahtevo.

Vendar pa obstajajo scenariji, ko ni druge možnosti, kot da imate Statične mikrostoritve, ki jih podpirajo trajne količineTo velja za nekatere baze podatkov, porazdeljene datotečne sisteme ali komponente, ki zahtevajo vzdrževanje lokalnih podatkov. Ti podi so običajno nameščeni s StatefulSets, povezani s PersistentVolumes z uporabo PersistentVolumeClaims in se skalirajo vertikalno in ne horizontalno.

Ko mikroservis potrebuje trajno shranjevanje, Zahteva za trajno prostornino (PVC) z velikostjo, načinom dostopa in predvideno uporaboOperativna ekipa je odgovorna za njegovo zagotavljanje v skladu s pravilniki platforme. Ta PVC je naveden v manifestu uvajanja in nameščen na pod, tako da lahko storitev vztrajno bere in zapisuje podatke.

Čeprav je v posebnih primerih morda potreben model, ki upošteva stanje, je splošno priporočilo, da poskusite narediti čim več storitev ostane brez državljanstvaTo poenostavi uvajanje, skaliranje, odpornost in obnovo po nesrečah ter zmanjša operativno kompleksnost v okoljih z veliko mikroservisi.

Decentralizacija podatkov in suverenost storitev

V tradicionalnih infrastrukturah je običajno centralizirati baze podatkov in shranjevanje, da se poveča učinkovitost. Pri mikroservisih je ta pristop drugačen. To je v nasprotju z avtonomijo in ločitvijo ekipe.Če si veliko storitev deli isto relacijsko shemo, lahko vsaka strukturna sprememba blokira več ekip in nenamerno prekine združljivost.

Zato je priporočena praksa, da je vsaka mikroservis lastnik lastnega podatkovnega modela in lastne baze podatkovČeprav se v razvojnem okolju ta baza podatkov lahko izvaja kot vsebnik znotraj gruče za poenostavitev uvajanja, se v produkciji običajno uporabljajo instance, ki jih upravlja oblak, ali drugi visoko razpoložljivi strežniki baz podatkov, pri čemer se vedno ohranja jasna meja lastništva.

To ne pomeni, da ni integracije med podatki: pomeni, da Skladnost med storitvami se upravlja z dogodki in asinhronim sporočanjem.Sprejemanje morebitne doslednosti, kadar je to razumno. Običajno se za širjenje sprememb stanja med mikroservisi uporabljajo vodila dogodkov (RabbitMQ, Azure Service Bus, Kafka itd.), kar zmanjšuje močne odvisnosti od ene same baze podatkov.

Platforma v oblaku ekipam olajša izbiro optimalna vrsta baze podatkov za vsako storitev (relacijske, na dokumentih temelječe, ključ-vrednost, časovne vrste itd.), brez vsiljevanja ene same tehnologije. Pomembno je, da zasnova upošteva možnost migracije shem in struktur brez prekinitve pogodb z drugimi storitvami ter da se odločitve o podatkih sprejemajo v skladu z mejami domene posamezne mikrostoritve.

Porazdeljeno upravljanje, ekipe in organizacija

Prehod na mikrostoritve brez spreminjanja organizacije si nakoplje težave. Namesto klasičnih Funkcionalni silosi za omrežja, sisteme, baze podatkov, razvoj in delovanjePriporoča se struktura, ki temelji na produktnih ekipah in združuje razvojne, QA, DevOps profile ter, kjer je to primerno, poslovne ali podatkovne analitike.

Vsaka ekipa je odgovorna za eno ali več mikroservisov znotraj iste funkcionalne domene in prevzame tako razvoj kot operacija (zgradiš, vodiš)To pomeni, da ekipa upravlja svoje cevovode CI/CD, sodeluje z infrastrukturo za specifične potrebe ter sodeluje pri spremljanju in odzivanju na incidente. Področja infrastrukture in platforme v oblaku se osredotočajo na zagotavljanje skupnih in standardiziranih storitev.

Da bi preprečili, da bi to porazdeljeno upravljanje vodilo v anarhijo, je ključnega pomena opredeliti lahki standardi in skupni katalogiOdobrene osnovne slike, vzorci uvajanja, konvencije poimenovanja za imenske prostore in storitve, smernice API-ja, predloge Dockerfile in Kustomize itd. Te smernice služijo kot »varovalne ograje«, ki vodijo ekipe, ne da bi jim ovirale možnost odločanja.

Številna poslovna okolja uporabljajo imenski prostori, ločeni s projektom ali domenoz vsaj enim na okolje (razvoj, predprodukcija, produkcija). Velik projekt lahko svoje mikrostoritve porazdeli po več imenskih prostorih, pod pogojem, da so notranje komunikacije pravilno konfigurirane in da se spoštujejo varnostna pravila.

CI/CD, avtomatizacija in model GitOps

Ko ima arhitektura na desetine ali stotine mikroservisov, je edini način, da jih ohranimo delujoče, velika naložba vanje. celovita avtomatizacijaTo vključuje dosledne cevovode CI/CD, deklarativno definicijo uvajanja, avtomatizirano testiranje in mehanizme za samodejno vračanje prejšnjih nastavitev.

Tipični ročaji za neprekinjeno integracijo in neprekinjeno dobavo prevedite kodo, izvedite teste, analizirajte kakovost z orodji, kot je SonarQubeZgradite sliko vsebnika iz datoteke Dockerfile podjetja in posodobite manifeste uvajanja. Od tam sistem, kot je ArgoCD ali podoben, uporabi spremembe v gručo po pristopu GitOps.

Vsak repozitorij mikroservisov običajno vključuje standardizirana datoteka Dockerfile, konfiguracijska datoteka za cevovod (npr. ci.json)Lastnosti za analizo kakovosti in imenik za uvajanje z definicijami Kubernetes (Kustomize ali Helm), ločenimi po okolju. Spletni kavlji repozitorija sprožijo cevovod, ko se zgodijo dogodki, kot so potiski oznak ali zahteve za združitev.

Vzorec GitOps navaja, da Vir resnice za infrastrukturo in uvajanje je repozitorij GitManifesti za uvedbe, storitve, konfiguracijske zemljevide (ConfigMaps), PVC-je, zaščitene tajne (SealedSecrets) in druge vire so tam nadzorovani z različicami, posebna orodja pa upravljajo sinhronizacijo stanja gruče z definiranim v Gitu. To zagotavlja sledljivost, preglede zahtev za prevzem (pull request) in enostavne možnosti povrnitve prejšnjih nastavitev.

Nastavitve, skrivnosti in varnost

V zreli platformi mikroservisov se upravljanje konfiguracije opira na ConfigMaps za neobčutljive parametre in Secrets za zaupne informacijeVsaka mikroservis ima običajno svoj ConfigMap na okolje, ki shranjuje lastnosti, kot so URL-ji odvisnih storitev, zastavice funkcionalnosti ali parametri uglaševanja.

Skrivnosti (poverilnice, ključi, žetoni, potrdila) se obravnavajo z stroge varnostne politikeV manj kritičnih okoljih je morda sprejemljivo, da se hranijo v obliki navadnega besedila, ki ga upravlja razvojna ekipa, vendar je v predprodukciji in produkciji priporočljivo, da se šifrirajo z orodji, kot so Sealed Secrets ali posebni zunanji upravljalniki oblaka.

Ko je treba skrivnost deliti med več storitvami (na primer Poverilnice OTEL Collector ali skupno shrambo ključevTo je mogoče centralizirati v konfiguracijskem repozitoriju za vsak imenski prostor. Projekti, ki si delijo ta imenski prostor, se usklajujejo pri posodabljanju, ko je to potrebno, in ohranjajo nadzor nad tem, kdo lahko bere ali spreminja te vire.

Na področju komunikacijske varnosti prevladuje vzorec Nič zaupanjaNič ni samoumevno samo zato, ker je promet "notranji". Vsi klici med storitvami, tako notranjimi kot zunanjimi, morajo biti overjeni in avtorizirani, idealno z žetoni mTLS, JWT ali drugimi enakovrednimi mehanizmi. Mikroservisi ne prepuščajo varnosti slepo upravitelju API-jev ali omrežju; izvajajo tudi lastna preverjanja.

Komunikacija med mikroservisi, API-ji in sporočanjem

V zreli arhitekturi mikroservisov je komunikacijski sloj razdeljen na več primerov. Za promet od odjemalcev (brskalniki, mobilne aplikacije, tretje osebe) do zalednega sistema se uporabljajo naslednji elementi: API-ji, objavljeni in upravljani prek upravitelja API-jevTi API-ji so običajno REST (pogosto uporabljajo OpenAPI) ali v nekaterih primerih gRPC, izpostavljeni prek prehoda.

Klici med mikroservisi, ki se nahajajo v istem imenskem prostoru ali celo v več imenskih prostorih istega projekta, se običajno obravnavajo z Notranje storitve Kubernetes z notranjim DNS-omNe gredo skozi javnega upravitelja API-jev, vendar še vedno upoštevajo varnostne, avtentikacijske in avtorizacijske politike. V teh primerih se lahko uporabi servisna mreža ali notranji prehodi, ki uveljavljajo skupne politike.

Kdaj mikroservisi pripadajo različna funkcionalna področja ali različni projektiKomunikacija se na organizacijski ravni šteje za "javno". V teh primerih je običajno, da poteka prek upravitelja API-jev ali vodila za interoperabilnost, kjer se nadzorujejo pogodbe, kvote, varnost, različice in revizija, s čimer se prepreči neposredno povezovanje med neodvisnimi gručami ali imenskimi prostori.

Glede integracije s starejšimi ali zunanjimi sistemi, ki ne morejo vedno razkriti sodobnih API-jev, se običajno zanašamo na specifični konektorji na interoperabilnem vodiluNa ta način mikroservisi govorijo skupni jezik (na primer dogodki ali notranji REST API-ji), konektor pa je odgovoren za prevajanje v in iz starejšega sistema, vedno z okrepljeno varnostjo.

Poleg sinhrone komunikacije, Asinhrono sporočanje igra ključno vlogoUporablja se za ločevanje procesov, absorpcijo skokov, širjenje poslovnih dogodkov med storitvami in izboljšanje odpornosti. Vsak dogodek ima običajno dobro definirano in različicsko shemo z mehanizmi za sledenje, ki preprečujejo okvare med proizvajalci in potrošniki, ko se ti razvijajo.

Opazljivost, OTEL zbiralnik in delovanje

V sistemu, sestavljenem iz številnih mikroservisov, je diagnosticiranje težave brez dobre opazovalnosti skoraj nemogoče. Zato so integrirani že od faze načrtovanja. metrike, centralizirano beleženje in porazdeljene sledi, ki nam omogočajo razumevanje, kaj se dogaja na ravni storitve in platforme.

Osrednji del te sheme je Zbiralnik OpenTelemetry (Zbiralnik OTEL)To se namesti v imenskem prostoru ali centralno za zbiranje metrik, dnevnikov in sledi iz vseh komponent. Mikrostoritve morajo vedeti le, da morajo poslati svojo telemetrijo zbiralniku; zbiralnik jo nato posreduje sistemom za opazovanje (Prometheus, Grafana, Jaeger, Elastic itd.), ne da bi storitev morala poznati podrobnosti.

Za infrastrukturni načrt se uporabljajo naslednji zbiralniki in izvozniki na ravni vozlišč Ti sistemi zbirajo meritve procesorja, pomnilnika, diska, omrežja in dnevnikov iz podov ter jih pošiljajo Prometheusu oziroma Elasticsearchu. Orodja, kot sta Grafana in Kibana, se uporabljajo za vizualizacijo teh informacij, izdelavo nadzornih plošč in definiranje opozoril s pametnimi pragovi in ​​povezanimi runbooki.

Ko projekt potrebuje zelo specifično obdelavo svojih metrik ali sledi, lahko v svojem imenskem prostoru namesti svoj primerek OTEL Collectorja, če ima operativno odobritev in je model vzdrževanja produkcije jasen.

Strategija testiranja, pogodbe in izkušnje z lokalnim razvojem

Testiranje arhitekture porazdeljenih mikroservisov zahteva bolj dovršena strategija testiranja kot v monolitu. Enotni testi ostajajo temeljni, vendar pogodbeni testi (za API-je in dogodke), integracijski testi med storitvami in celoviti testi, ki prečkajo celotne tokove, pridobivajo na pomenu.

Da bi se izognili spremembam, ki kršijo združljivost, se uporabljajo tehnike, kot so testiranje pogodb, usmerjenih k potrošnikomkjer stranke določajo pričakovanja glede API-ja, ponudniki storitev pa jih izpolnjujejo. Vsaka sprememba pogodbe gre skozi avtomatizirane teste, ki se izvajajo v cevovodih neomejene izbire, kar preprečuje uvajanje, ki bi lahko povzročilo težave znanim uporabnikom.

Ko število storitev preseže sto, postane lokalna replikacija celotnega sistema nepraktična. Zato se razvojne izkušnje zanašajo na simulacije odvisnih storitev ali tuneliranje v oddaljena okoljaRazvijalci običajno namestijo le podmnožico mikroservisov, preostale pa dopolnijo z lažnimi različicami, simulatorji ali pa določene klice preusmerijo v skupno integracijsko okolje.

Testiranje od začetka do konca se vse bolj zanaša na kratkotrajna okolja ali »predogledi«, ustvarjeni iz vej funkcijTa orodja ustvarjajo izolirano okolje s storitvami, ki so pomembne za to funkcionalnost. To zmanjšuje trenje med ekipami, zmanjšuje učinek »deluje na mojem računalniku« in zazna težave z integracijo, preden dosežejo dražja okolja, kot je predprodukcija.

Vzorci uvajanja mikroservisov v produkciji

Poleg Kubernetesa obstaja še več vzorcev uvajanja mikroservisov v produkciji, ki jih je vredno poznati, saj obravnavajo različni scenariji izolacije, stroškov in zrelostiEden najstarejših vzorcev je vzorec več primerkov storitev na gostitelja, kjer isti fizični ali virtualni gostitelj izvaja več primerkov različnih storitev, običajno na skupnem aplikacijskem strežniku.

V vzorcu primerek storitve na virtualni strojVsaka storitev je zapakirana kot slika navideznega stroja (npr. EC2 AMI) in se izvaja v svojem lastnem primerku. To zagotavlja močno izolacijo, vendar z višjo porabo virov in počasnejšimi časi zagona. Orodja, kot je Packer ali rešitve ponudnikov oblaka, olajšajo ustvarjanje slik navideznih strojev, pripravljenih za produkcijo.

Najbolj razširjen vzorec danes je primerek storitve na vsebnikkjer je vsaka mikroservis zgrajena kot slika vsebnika in nameščena v orkestratorju (Kubernetes, OpenShift itd.). Vsebniki so lažji od virtualnih strojev, se zelo hitro zaženejo in omogočajo pakiranje vsega, kar je potrebno za storitev, kar poenostavi uvajanje in samodejno skaliranje.

Končno so pristopi pridobili na priljubljenosti brezstrežniško, kot je AWS LambdaTa vzorec vključuje pakiranje funkcij, ki se odzivajo na zahteve HTTP ali dogodke iz drugih storitev (S3, DynamoDB, čakalne vrste itd.), pri čemer uporabniki plačajo le za tisto, kar uporabljajo. Še posebej je primeren za zelo majhne mikrostoritve ali kratkotrajne naloge, ki jih poganjajo dogodki, čeprav uvaja dodatne premisleke glede opazovalnosti, hladnih zagonov in omejitev izvajanja.

V praksi se številne organizacije znajdejo v hibridnem ekosistemu: osrednji del sistema deluje na vsebnikih in orkestratorjih, medtem ko so nekatere pomožne komponente implementirane kot funkcije brez strežnika ali kot specializirani virtualni stroji, vedno z jasni vmesniki in dobro definirani protokoli da jih integriramo v celoto.

Ko gre za uvedbo vsega tega v proizvodnjo, ni pomembna le izbrana tehnologija, temveč tudi arhitektura, ki ... Je odporen na napake, se prilagaja po potrebi, se samodejno uvaja in je opazljiv.Z ekipami, usklajenimi s produkti, dobro upravljanimi pogodbami, decentraliziranimi podatki in robustno platformo v oblaku se mikrostoritve iz obljube spreminjajo v učinkovit in trajnosten način za razvoj kompleksnih aplikacij, ki bo trajal leta.