Irrota kaikki. Anna palveluiden kommunikoida tapahtumien kautta, ei odotusten perusteella toistensa käytettävyydestä.

Monoliittisi on muuttumassa käyttöönoton pullonkaulaksi – jokainen muutos edellyttää tiimienvälistä koordinointia, ja laskutuksen virhe kaataa koko sovelluksen. Tai rakennat uutta järjestelmää, jossa eri ominaisuudet kehittyvät eri tahtiin: tilaustenhallinta muuttuu viikoittain, mutta varaston logiikka neljännesvuosittain. Tarvitset palveluita, joita voidaan kehittää, ottaa käyttöön ja skaalata itsenäisesti, ja jotka kommunikoivat tapahtumien kautta synkronisten API-kutsujen sijaan, jotka luovat kaskadoituvia virheketjuja.
Explore more design patterns and system architectures
Arkkitehtehtemme voivat auttaa suunnittelemaan ja rakentamaan järjestelmiä käyttäen tätä mallia omiin vaatimuksiin.
Ota yhteyttäTapahtumapohjaiset mikropalvelut hajottavat järjestelmän itsenäisesti käyttöönotettaviksi palveluiksi, jotka kommunikoivat ensisijaisesti asynkronisten tapahtumien kautta. Jokainen palvelu omistaa tietonsa, julkaisee domain-tapahtumia tilan muuttuessa ja reagoi muiden palveluiden tapahtumiin. Tämä eliminoi ajallisen kytkennän – Palvelun A ei tarvitse Palvelun B olla käynnissä tehdäkseen työnsä. Malli hyödyntää CQRS:ää (Command Query Responsibility Segregation) kirjoitus- ja lukumallien erotteluun, Event Sourcing -mallia tilan muutosten täydellisen historian tallentamiseen ja Saga Orchestration -mallia usean palvelun transaktioiden hallintaan ilman hajautettuja lukkoja.
Arkkitehtuuri keskittyy tapahtumarunkoon (Kafka, EventBridge tai NATS), joka reitittää domain-tapahtumia palveluiden välillä. Jokaisella palvelulla on kolme rajapintaa: komentojen käsittelijä, joka käsittelee saapuvia pyyntöjä ja lähettää tapahtumia, kyselyjen käsittelijä, joka palvelee lukemiseen optimoituja projektiota, ja tapahtumaprosessori, joka reagoi muiden palveluiden tapahtumiin. Saga-orkestraattori koordinoi monivaiheisia liiketoimintaprosesseja (esim. tilausten toimitus) kuuntelemalla tapahtumia ja antamalla korvaavia komentoja vaiheiden epäonnistuessa.
| Kerros | Teknologiat |
|---|---|
| Laskenta | Node.js (NestJS), Python (FastAPI), Go – palvelukohtaisesti työkuorman ominaisuuksien mukaan |
| Viestinvälitys | Apache Kafka (MSK), AWS EventBridge, NATS JetStream, RabbitMQ |
| Tietovarasto | PostgreSQL (transaktionaalinen), DynamoDB (avain-arvo), Redis (välimuisti/lukot), EventStoreDB |
| Orkestraatio | Temporal (työnkulun orkestraatio), AWS Step Functions, mukautettu saga-koordinaattori |
| Havainnoitavuus | OpenTelemetry (hajautettu jäljitys), Datadog, Jaeger, strukturoitu lokitus korrelaatio-tunnisteilla |
| Käytä, kun | Vältä, kun |
|---|---|
| Useita tiimejä tarvitsee ottaa käyttöön itsenäisesti eri tahtiin | Tiimissäsi on alle 5 insinööriä – hyvin strukturoitu monoliitti on yksinkertaisempi operoida |
| Järjestelmän eri osilla on erilaiset skaalautuvuusominaisuudet | Rakennat MVP:tä ja sinun on saatava valmista nopeasti – hajautettuja järjestelmiä on hidasta rakentaa |
| Tarvitset vahvat valvontaketjut ja tapahtumien uudelleentoistokyvyt | Jokainen operaatio vaatii synkronisia, vahvasti konsistentteja vastauksia |
| Domainilla on luonnollisia rajattuja konteksteja (tilaukset, maksut, varasto) | Domain on tiukasti kytketty – sen jakaminen luo hajautetun monoliitin |
MW ei hajota järjestelmää mikropalveluiksi teknisten kerrosten mukaan (API-palvelu, tietopalvelu, todennuspalvelu). Hajotamme sen domain-rajojen mukaan käyttäen DDD:n (Domain-Driven Design) rajattuja konteksteja. Ennen koodin kirjoittamista järjestämme tapahtumamyllerrystyöpajan (event storming workshop) domain-tapahtumien, komentojen ja aggregaattien kartoittamiseksi – tämä määrittää palvelun rajat, ei teknologiavalinnat. Olemme siirtäneet monoliitteja tapahtumapohjaisiin arkkitehtuureihin yritysasiakkaille, ja yleisin oppi on: aloita harvemmilla, suuremmilla palveluilla ja jaa myöhemmin, älä toisinpäin.
Mallit eivät toimi itsestään. Putki, joka kouluttaa, validoi, ottaa käyttöön ja valvoo malliasi, on todellinen tuote – malli on vain yksi artefakti.
MicrocosmWorks suunnittelee tapahtumavetoisia järjestelmiä kestävien viestinvälittäjien, kuten Apache Kafkan tai Amazon EventBridgen, avulla. Nämä välittäjät säilyttävät tapahtumat, kunnes kuluttajat ovat käsitelleet ne onnistuneesti, varmistaen, ettei tietoa katoa käyttökatkojen aikana. Toteutamme dead-letter-jonot, eksponentiaaliset viivästetyt uudelleenyrityskäytännöt ja katkaisijat, jotta epäonnistuva mikropalvelu ei tuki koko tapahtumaputkea. Kun alavirran palvelu palautuu, se käsittelee automaattisesti rästissä olevat tapahtumat ilman manuaalista puuttumista.
Tapahtumapohjainen kommunikaatio on parempi valinta, kun palvelusi eivät tarvitse välitöntä vastausta, kun sinun on irrotettava käyttöönottosyklit toisistaan, tai kun yksi toiminto laukaisee useita jatkoprosesseja. MicrocosmWorks suosittelee tyypillisesti tapahtumapohjaisia malleja tilausten käsittelyyn, ilmoitusputkiin ja analytiikan keruuseen, samalla kun synkroniset API:t pidetään käyttäjille suunnatuille kyselyille, jotka vaativat alle sekunnin vastauksia. Monet rakentamamme tuotantojärjestelmät käyttävät hybridiä lähestymistapaa synkronisilla lukutoiminnoilla ja asynkronisilla kirjoitustoiminnoilla.
MicrocosmWorks hyödyntää osiointiavaimiin perustuvaa järjestystä Kafka topicsissa varmistaakseen, että kaikki tietylle entiteetille (kuten tietty tilaus tai käyttäjä) tarkoitetut tapahtumat käsitellään peräkkäin saman kuluttajaistanssin toimesta. Skenaarioissa, jotka edellyttävät entiteettien välistä järjestystä, toteutamme saga orchestratoreita, joissa on idempotentit tapahtumankäsittelijät, ja jotka voivat turvallisesti käsitellä uudelleen epäjärjestyksessä olevia viestejä. Upotamme myös vektorikellot tai järjestysnumerot tapahtumakuormiin, jotta kuluttajat voivat havaita ja selvittää järjestysristiriidat.
MicrocosmWorks toteuttaa Saga-mallin kompensoivilla transaktioilla, joissa jokainen microservice julkaisee domain events -tapahtumia suoritettuaan paikallisen transaktionsa, ja alavirran palvelut reagoivat vastaavasti tai käynnistävät rollback compensations -toimenpiteitä vian sattuessa. Yhdistämme tämän outbox pattern -malliin, joka kirjoittaa tapahtumat atomisesti paikalliseen outbox table -tauluun liiketoimintatiedon rinnalla, ja julkaisee ne sitten luotettavasti message brokeriin. Tämä saavuttaa eventual consistency -tilan ilman two-phase commits -menetelmän suorituskyky- ja luotettavuusrangaistuksia.
MicrocosmWorks varustaa jokaisen tapahtuman korrelaatiotunnuksilla ja hajautetun jäljityksen otsikoilla OpenTelemetryn avulla, mikä mahdollistaa liiketoimintatransaktion koko elinkaaren visualisoinnin kaikkien osallistuvien mikropalveluiden yli työkaluissa kuten Jaeger tai Grafana Tempo. Rakennamme myös reaaliaikaisia tapahtumavirran hallintapaneeleja, jotka näyttävät suoritustehoa, kuluttajan viivettä ja käsittelyviivettä palvelukohtaisesti, tehden pullonkaulojen paikantamisesta helppoa. Standardi observointipinonimme sisältää strukturoitua lokitusta tapahtumametadatalla, jotta mikä tahansa yksittäinen tapahtuma voidaan jäljittää tuottajasta jokaiseen kuluttajaan sekunneissa.