Mikroteenuste arhitektuur: millal seda vaja on ja kuidas läheneda
21. november 2025
11 min lugemine
Millal mikroteenused mõistlikud on
Hea monoliit võib vabalt teenindada miljoneid kasutajaid. Mikroteenused muutuvad vajalikuks alles siis, kui teatud tüüpi skaleerimis- ja organisatsioonilised probleemid enam teisiti lahendatavad ei ole.
Tiimide skaleerumine ja autonoomia
Erinevad skaleerimisvajadused
Tehnoloogiline mitmekesisus
Varjatud kulud, mida sageli alahinnatakse
Kui monoliidist mikroteenustele üle minna, ei kao keerukus kuhugi - see liigub koodibaasist võrgu- ja operatiivkihi peale. Ilma tugeva monitooringu ja tööriistadeta on igapäevane ops oluliselt raskem.
Silumine ja jälgitavus hajusas süsteemis
Võrk kui potentsiaalne rikkekoht
Andmekooskõla ja transaktsioonid
Läbiproovitud migreerimismustrid
Suur „kirjuta kõik ümber mikroteenusteks“ projekt lõpeb tavaliselt kas veniva tähtaja või katkise süsteemiga. Paremini toimib järkjärguline lähenemine, kus monoliit ja uued teenused elavad mõnda aega koos.
Strangler Fig - teenuste järkjärguline välja juurimine
Selle mustri mõte:
uus funktsionaalsus ehitatakse juba mikroteenusena
vanu osi tõstetakse tükikaupa monoliidist välja
API gateway otsustab, kas päring läheb monoliiti või uude teenusesse
Nii saab:
vältida ühekordset suurt riskantset „cutover’it“
õppida ja parandada arhitektuuri jooksvalt
Lõpuks on alles vaid mikroteenused ja vana monoliit „kuivanud kokku“ ning saab välja lülitada.
Alusta äärealadest, mitte südamikust
Esimeste mikroteenustena tasub välja tõsta:
e-posti saatmine
teavitused
raportid
Need:
on sageli suhteliselt isoleeritud
ei oma kriitilist rolli põhiloogikas
annavad hea mänguväljaku deploy-mustrite, jälgitavuse ja logimise harjutamiseks
Kui nendes teenustes midagi läheb valesti, on mõju väiksem kui siis, kui esimene katse tehakse otse näiteks makseteenuse kallal.
Platvormivalik ja tiimi suurus
Kokkuvõte
Mõtled, kas sinu süsteem vajab mikroteenuseid?
Aitame hinnata praegust arhitektuuri, kaardistada skaleerimis- ja organisatsioonilisi pudelikaelu ning soovitada, kas ja millises mahus mikroteenused on mõistlikud. Vajadusel paneme koos paika ka konkreetse, samm-sammulise migreerimiskava.
Mikroteenused on jõudnud oma hype-tsükli küpsemisse faasi. Aastate eest kõlas sageli „murra kõik teenusteks“, kuid reaalsuses on nähtud nii edulugusid kui ka valusaid ebaõnnestumisi. Mikroteenused lahendavad teatud probleeme, kuid toovad kaasa terve hulga uusi - eriti operatiivses, jälgitavuse ja andmekooskõla kihis.
Oleme Accelis aidanud klientidel ehitada nii hästi struktureeritud monoliite kui ka mitmekümnest teenusest koosnevaid süsteeme. Selles artiklis anname otsustusraamistiku: millal mikroteenused on õigustatud, millal mitte, millised on peamised varjatud kulud ning kuidas monoliidist turvaliselt üle minna.
Kui arendustiim kasvab üle 15-20 inimese, hakkab ühte koodibaasi tihedalt koordineerida keeruliseks:
rohkem merge-konflikte
raskem sünkroonis deploy’sid teha
iga muudatus puudutab korraga suurt hulka inimesi
Mikroteenused võimaldavad jagada süsteemi „vertikaalseteks viiludeks“, kus üks tiim:
omab kindlat domeeni
haldab nii andmebaasi, API-t kui deploy-protsesse
saab oma tempos väljalaskeid teha, mõjutamata teisi tiime üleliia
See töötab aga ainult siis, kui teenused on joondatud äridomeenide, mitte tehniliste kihtide (näiteks „frontend-teenus“, „backend-teenus“) järgi.
Kui kõik süsteemi osad skaleeruvad enam-vähem ühtemoodi, ei anna mikroteenused väga palju juurde. Kui aga:
üks komponent vajab oluliselt rohkem RAM-i või CPU-d
teised komponendid saavad töötada tagasihoidlikemates tingimustes,
siis võib eraldi teenus ja eraldi deploy olla kuluefektiivne. Näiteks:
pilditöötlus või videoenkodeerimine
intensiivsed analyütilised või ML-töövood
Sellisel juhul ei pea „tavalisi“ request’e jooksutama sama kalli infrastruktuuri peal, mida spetsiaalne osa vajab.
Mõnikord on mõistlik:
kasutada reaalaja teenuse jaoks Go-d
ML-teenuse jaoks Pythoni
ülejäänud süsteemi jaoks Node’i või .NET-i
Mikroteenused annavad selleks ruumi, kuid:
iga lisanduv keel tähendab eraldi runtime’i, build’ide ja logimise/deloye haldust
värbamine ja teadmiste jagamine muutub keerulisemaks
Seega tasub keel(t)e hulka hoida kontrolli all ja valida teistsugune tehnoloogiapakk ainult siis, kui võit on selgelt mõõdetav (nt oluliselt parem jõudlus või parem ökosüsteem).
Monoliidis on veateade ja stack trace tavaliselt selgelt ühest kohast leitud. Mikroteenustes võib üks kasutaja teekond läbida:
API gateway’d
3-10 eraldi teenust
mitut andmebaasi ja välist teenust
Ühe vea põhjuse välja selgitamine eeldab:
hajusjälgimist (OpenTelemetry, Jaeger, Tempo)
tsentraliseeritud logimist (ELK, Loki jms)
korrelatsiooni ID-sid, mis liiguvad läbi kõikide teenuste
Sellise jälgitavuskihi ülesehitamine võtab aega (mitu nädalat-kuud) ning lisab püsikuluna nii infrastruktuuri- kui ka inimressursi kulu.
Protsessisisene meetodikõne kas töötab või viskab vea üsna deterministlikult. Võrgukõnede puhul:
võib ühendus katkeda
timeout’ida
jääda aeglaseks
See sunnib kasutama mustreid:
circuit breaker’id
retry + backoff strateegiad
idempotentsed kirjutusoperatsioonid
graatsiline degradeerumine (nt „mõni osa lehe sisust ei laadinud, kuid põhifunktsioon töötab“)
Need ei ole „mugavad lisad“, vaid tootmiskeskkonna vältimatu osa. Nende mustrite korrektne juurutamine on omaette töömaht.
Monoliidis saab sageli kasutada ühtset andmebaasi ja klassikalisi transaktsioone:
BEGIN
mitu muudatust
COMMIT
Mikroteenuste puhul on eri domeenid eri andmebaasides. See tähendab:
jaotatud transaktsioonide mustreid (nt Saga)
eventual consistency põhimõtteid
keerukamat veakäsitlust (mis saab, kui mõni samm ebaõnnestub?)
See omakorda mõjutab UX-i: mõnikord tuleb kasutajale näidata „Tehingut töödeldakse“ seniks, kuni kõik alamsammud on valmis.
Kubernetes on muutunud de facto standardiks mikroteenuste orkestreerimisel, kuid:
tema õppimiskõver on järsk
väiksematel tiimidel võib kogu aeg kuluda platvormi haldamisele
lahendusi, mis peidavad ära suure osa K8s keerukusest
Võid alati hiljem Kuberneteseni jõuda, kui teenuste arv ja nõuded seda õigustavad. Algfaasis on olulisem kiiresti ja turvaliselt liikuma saada, mitte ehitada „täiuslikku“ platvormi.
Mikroteenused on võimas tööriist õigetes kätes ja õiges kontekstis: nad aitavad jagada tööd tiimide vahel, skaleerida eri osi süsteemist iseseisvalt ja kasutada sobivaimat tehnoloogiat iga domeeni jaoks. Samas tähendavad nad peaaegu alati 2-3 korda suuremat operatiivset keerukust võrreldes hästi tehtud monoliidiga.
Kui sinu tiim on väike või kasutajate arv veel tasemel, kus monoliit hästi toimib, on mõistlik pigem investeerida korralikku arhitektuuri ja modulaarset koodi ühe rakenduse sees. Kui aga organisatsiooniline ja tehniline surve kasvab piisavalt suureks, tasub mikroteenustele liikuda järk-järgult ja teadlikult, ehitades koos sellega ka jälgitavuse, deploy-mustrid ja meeskondliku distsipliini, mis sellist arhitektuuri kanda suudavad.
