I. Komponendid – tarkvara väikseimad, aga võimsad osad
Komponent on nagu üks pusletükk. Iseseisev, korduvkasutatav ja eraldi arendatav – aga tervikuks saab see siis, kui teiste tükkidega õigesti kokku läheb. Komponentide arhitektuur põhineb mõttel, et iga süsteemi saab jagada väikesteks osadeks, millel on selge eesmärk ja piiratud vastutus.
Komponentide kuus omadust:
- Korduvkasutatav – saab kasutada erinevates süsteemides või kontekstides. Nt üks ja sama autentimismoodul sobib nii pangale kui e-poele.
- Asendatav – kui mõni komponent ei toimi, saab selle kiiresti asendada, ilma kogu süsteemi ümber kirjutamata.
- Sõltumatu – ei tohi olla tihedalt seotud teiste komponentidega.
- Laiendatav – võimalus lisada uut funktsionaalsust, ilma olemasolevat koodi muutmata.
- Kapseldatud – peidab oma sisemise loogika välise maailma eest. Teistele osadele on näha vaid liides ehk API.
- Mittekontekstispetsiifiline – töötab sõltumata keskkonnast, kui vajalikud parameetrid ja andmed antakse väljastpoolt.
Eluline näide:
Mõtle näiteks veebipoe ostukorvi funktsioonile. Kui see on eraldi komponendina loodud, saab seda sama koodi kasutada kümnes erinevas e-poes, muutmata loogikat, ainult stiili ja kujundust.
II. Teenused – komponendid, mis lahendavad äriülesandeid
Kui komponent on puhtalt tehniline üksus, siis teenus astub sammu kaugemale – see lahendab konkreetset ärivajadust. Teenused on tihti suuremad kui komponendid ja võivad ise koosneda mitmest komponendist.
Teenuste kõige tähtsam omadus on nende iseseisev kasutuselevõtt – neid saab paigaldada, hallata ja uuendada eraldi süsteemi ülejäänud osadest.
Teenuse omadused:
- Iseseisev, töötab üksinda
- Saa kasutada üle võrgu (nt REST API kaudu)
- Ainus aktiivne instants, mida kasutavad mitmed kliendid
- Keskendub äriprotsessile, mitte ainult koodi taaskasutamisele
Näide:
Pangal võib olla teenus, mis kontrollib kliendi krediidiskoori. See teenus töötab kõikides rakendustes – laenutaotluses, krediitkaardi taotluses, järelmaksusüsteemis jne. Aga süsteem kasutab ühte ja sama teenust, mitte ei kopeeri selle loogikat igasse kohta eraldi.
III. Komponent vs teenus – kas need on üks ja sama asi?
Ei ole. Kuigi mõlemad täidavad funktsionaalset rolli, on nende erinevus mõtteviisis ja kasutusviisis.
| Omadus | Komponent | Teenus |
|---|---|---|
| Eesmärk | Tehniline korduvkasutatavus | Äriloogika ja äriprobleemi lahendamine |
| Skaleeritus | Tavaliselt rakenduse sees | Saab kasutada sõltumata süsteemist |
| Nähtavus | Rakendusesisene | Võib olla avalik (API kaudu) |
| Juurutus | Tavaliselt koos rakendusega | Saab juurutada eraldi |
| Suhtlus | Liideste (interfaces) kaudu | Võrgu (nt HTTP, gRPC) kaudu |
IV. Hajutatud süsteemid – mis juhtub, kui kõik töötab erinevates kohtades?
Hajutatud süsteem on süsteem, kus erinevad komponendid ja teenused töötavad eri serverites või isegi eri andmekeskustes, kuid moodustavad ühe terviku.
Iseloomulikud omadused:
- Lõppkasutajale nähtamatu – kuigi teenused jooksevad eri masinates, tundub kasutajale, et kõik toimub ühe süsteemi sees.
- Tõrkekindlus – kui üks server kukub, süsteem jätkab tööd.
- Skaleeritavus – vajadusel saab lisada uusi servereid.
- Platvormisõltumatus – komponendid võivad töötada eri operatsioonisüsteemides või programmeerimiskeeltes.
- Asünkroonne suhtlus – teenused suhtlevad üksteisega sõnumite või sündmuste kaudu.
Päriseluline näide:
Netflix. Kui sina vajutad „play“, käivitub hulganisti teenuseid: autentimine, videoteenus, soovituste mootor, andmebaas, CDN, voogedastus – kõik need töötavad hajutatud süsteemis, eri serverites ja regioonides.
V. Tarkvaraarhitektuurid, mis seovad kõik selle kokku
Erinevad arhitektuurilised mustrid määravad, kuidas komponendid ja teenused süsteemis omavahel suhtlevad.
1. Kahetasandiline (2-tier)
- Klient (nt brauser) suhtleb otse serveriga
- Näide: lihtne andmebaasivorm
2. Kolmetasandiline (3-tier)
- UI (kasutajaliides)
- Äri- või rakendustasand
- Andmetasand
- Näide: veebipood (React frontend + Node backend + PostgreSQL)
3. Peer-to-peer (P2P)
- Sõlmed on võrdsed – igaüks on klient ja server
- Näide: BitTorrent, Bitcoin
4. Sündmustepõhine arhitektuur
- Üks osa saadab sündmuse, teine reageerib
- Sobib hästi hajutatud ja mikroteenustega
- Näide: Uber (klient palub sõitu, süsteem „kuulab“ ja reageerib)
5. Mikroteenused
- Rakendus on jagatud väikesteks iseseisvateks teenusteks
- Iga teenus täidab konkreetset funktsiooni
- Näide: Facebook (kasutajakonto teenus, uudisvoog, reklaam)
VI. Keskkonnad: arendusest kuni tootmiseni
Enne kui süsteem jõuab päris kasutajateni, läbib see mitmeid keskkondi:
- Arendus – kus arendajad kirjutavad ja testivad uut koodi
- QA/testimine – kus kontrollitakse kvaliteeti
- Lavastus (staging) – imiteerib tootmiskeskkonda, et testida „pärisoludes“
- Tootmine – reaalne keskkond, kus kasutajad süsteemi kasutavad
🛠 Tootmiskeskkonna komponendid:
- Tulemüür – kaitseb võrke ja servereid
- Koormuse tasakaalustaja (load balancer) – jaotab liiklust mitme serveri vahel
- Veebiserver – kuvab HTML-i, pilte jne
- Rakendusserver – töötleb äriloogikat
- Andmebaasiserver – salvestab ja haldab andmeid
- Puhverserver – optimeerib, vahemälu kasutab ja suurendab turvalisust
VII. Kus rakendust juurutada? Kohapeal või pilves?
- Kohapealne (On-Premise)
- Kõik töötab ettevõtte serverites
- Pluss: rohkem kontrolli ja turvalisust
- Miinus: kallis hooldus ja piiratud skaleerimine
- Avalik pilv (AWS, Azure, Google Cloud)
- Rentida infrastruktuuri
- Pluss: paindlikkus, kiire kasutuselevõtt
- Miinus: vähem otsest kontrolli
- Privaatpilv
- Ettevõtte oma pilvekeskkond
- Pluss: suurem turvalisus, kohandatavus
- Miinus: kallim
- Hübriidpilv
- Kombinatsioon eelmistest
- Pluss: tasakaal turvalisuse ja skaleeritavuse vahel
VIII. Lõpetuseks: terviklik süsteem vajab läbimõeldud arhitektuuri
Komponendid võimaldavad koodi taaskasutada. Teenused viivad selle mõtte sammu edasi ja loovad võimaluse süsteemi hajutada. Hajutatud süsteemid toovad mängu töökindluse, kiiruse ja mastaabitavuse. Aga kõik see vajab tugevat arhitektuuri, strateegiat ja järk-järgulist juurutust.
Hea süsteem ei juhtu kogemata – see on teadlik valik, mis algab komponentide disainist ja lõpeb tootmiskeskkonna arhitektuuriga.
