Mikropalveluarkkitehtuurissa sovellus koostuu useista pienistä palveluista, jotka kytkeytyvät löysästi toisiinsa ja ovat itsenäisesti asennettavissa. Kukin mikropalvelu vastaa tietystä toiminnallisuudesta ja palvelut kommunikoivat keskenään hyvin määriteltyjen rajapintojen välityksellä käyttäen kevyitä protokollia kuten HTTP/REST tai viestijonot. Kullakin mikropalvelulla on oma tietokantansa, lähdekoodi ja työkalut. Toisin sanoen niitä voidaan kehittää ja asentaa toisistaan riippumatta.
Mitä hyötyä on mikropalveluarkkitehtuurista?
- Ketteryys. Palvelut ovat pieniä ja helposti ymmärrettäviä. Kehitys ja asennus nopeutuvat. Tiimin eri jäsenet voivat keskittyä tiettyyn osa-alueeseen häiritsemättä muita.
- Skaalattavuus. Pienet, itsenäisesti asennettavat palvelut mahdollistavat paremman skaalattavuuden.
- Vikasietoisuus. Pienempi todennäköisyys sille, että ongelma jollain osa-alueella vie koko sovelluksen alas.
- Soveltuu hyvin DevOps-käytäntöihin (continuous integration/continuous delivery).
- Teknologia- ja ohjelmointikieliagnostisuus.
- Ylläpito. Pienet palvelut ovat osittain itsenäisesti ylläpidettävissä ja asennettavissa.
- Testaus. Mikropalvelukohtaiset automaatiotestit.
- Tietoturva. Mikropalveluissa voidaan toteuttaa tietoturva kyseisen toiminnallisuuden vaatimusten mukaisesti.
Entä ne haasteet?
- Monimutkaisuus. Kun mikropalveluiden määrä kasvaa, niin kokonaisuuden ymmärtäminen vaikeutuu.
- Riippuvuudet. Mikropalveluiden välillä on riippuvuuksia.
- Tiedon eheys. Mikropalveluarkkitehtuurissa kullakin mikropalvelulla on usein oma tietokanta. Kuinka toteutetaan hajautetut transaktiot?
- Resurssien kulutus. Kukin mikropalvelu pyörii omassa ympäristössään.
- Tiedonsiirron viiveet. Mikropalvelut kommunikoivat verkon yli toistensa kanssa, mikä lisää viiveitä.
- Palveluiden koordinointi. Yhden toiminnon toteuttamiseen tarvitaan useita mikropalveluita.
- Asennuksen monimutkaisuus. Yksittäisen mikropalvelun asentaminen on yksinkertaista, mutta järjestelmätasolla esimerkiksi asennusjärjestyksellä on merkitystä.
- Testauksen monimutkaisuus. E2E- ja integraatiotestaus voi olla hankalampaa, koska transaktioihin osallistuu useita mikropalveluita.
- Tietoturvan haasteet. Mikropalveluarkkitehtuuri tuo uudenlaisia tietoturvahaasteita. Esimerkiksi mikropalveluiden väliseen kommunikointiin tarkoitetut rajapinnat on suojattava niin, ettei niihin pääse käsiksi muut kuin toiset mikropalvelut.
Parhaita käytäntöjä
- Suunnittele mikropalvelujako huolellisesti. Mikropalvelun pitäisi olla kohtuullisen kokoinen ja keskittyä tiettyyn liiketoiminnalliseen tehtävään.
- Jos kahden mikropalvelun välillä on riippuvuus, mieti kumman mikropalvelun vastuulla on riippuvuuden ylläpito.
- Ota tietomallissa huomioon jako mikropalveluihin riippuvuuksien kannalta.
- Suunnittele mikropalveluiden rajapinnat huolellisesti. Käytä standardeja protokollia kuten HTTP/REST.
- Ota API Gateway pattern käyttöön. API Gateway on välityspalvelu, joka tarjoaa keskitetyn pääsyn eri mikropalveluiden rajapintoihin.
- Versionhallinta kuuluu mihin tahansa ohjelmistoprojektiin, mutta mikropalveluarkkitehtuurin toteuttamisessa sen käyttö on välttämätöntä.
- Toteuta mikropalvelut jollain tunnetulla alustalla. Näitä ovat esimerkiksi Spring Boot, .NET ja Node.js.
- Ota huomioon, että transaktiot ovat usein hajautettuja mikropalveluarkkitehtuurissa. Tähän tarvitaan hajautettua transaktion hallintaa, joka voidaan toteuttaa esimerkiksi Saga patternin.
Vaihtoehtoja mikropalveluarkkitehtuurille
- Perinteinen monoliitti. Koko sovellus kehitetään yhtenä kokonaisuutena. Tämä saattaa olla pieniin sovelluksiin parempi vaihtoehto kuin mikropalvelut.
- Service Oriented Architecture (SOA). Mikropalveluarkkitehtuurin edeltäjä. Palvelut ovat tyypillisesti isompia ja rajapinnat käyttävät raskaampia protokollia kuten SOAP.
- Modulaarinen monoliitti. Esimerkiksi Spring Modulith.
- Perinteinen kolmetasoinen (three tier). Sovellukset jaetaan kolmeen kerrokseen: esitys, liiketoimintalogiikka ja tiedon tallennus.
- Event Driven Architecture (EDA). Pohjautuu tapahtumaohjattuun asynkroniseen kommunikointiin. Event sourcing ja Command Query Responsibility Segregation patternit usein käytössä.
- Hybridi. Yhdistelmä erilaisia arkkitehtuureja. Esimerkiksi monoliittinen ydin ja liittymät mikropalveluilla.
- Komponenttipohjainen. Yleensä käytössä työpöytäsovelluksissa.
Tämän blogikirjoituksen on kirjoittanut asiantuntijamme Lars Andtfolk.
Mikäli haluat keskustella ohjelmistokehitystarpeistanne, ole yhteydessä!
