Palvelimettomien mikropalvelujen transformaatio

MicrocosmWorks hyödyntää strangler fig -mallia, jossa uusi toiminnallisuus rakennetaan palvelimettomina mikropalveluina rinnakkain käynnissä olevan monoliitin kanssa. API gateway reitittää liikennettä vanhojen ja uusien komponenttien välillä feature flagseihin ja asteittaiseen liikenteen siirtoon perustuen. Jokainen toimialueraja erotetaan asteittain — alkaen vähiten kytketyistä, arvokkaimmista komponenteista — säilyttäen samalla taaksepäin yhteensopivuuden anti-corruption layereiden avulla, jotka muuntavat monoliitin ja mikropalvelun tietomallien välillä. Tämä lähestymistapa tuottaa lisäarvoa jokaisella erottelulla sen sijaan, että vaadittaisiin riskialtista big-bang cutoveria. Tyypilliset muunnokset kestävät 6-18 kuukautta monoliitin monimutkaisuudesta riippuen.

MicrocosmWorks käsittelee cold start latencyä (tyypillisesti 100ms-3s riippuen runtime- ja package size -parametreista) provisioned concurrencyn avulla kriittisille poluille, function warm-keeping -strategioilla, optimoiduilla deployment packageilla, jotka minimoivat initialization time -ajan, ja architecture-päätöksillä, jotka ohjaavat latency-sensitive -operaatiot always-warm servicesiin, samalla kun batch- ja async-operaatiot käyttävät standardia serverless scalingia. Lambdaa varten optimoimme käyttämällä kevyempiä runtimeja (Node.js tai Python Javan sijaan), minimoimalla dependency bundle sizejä ja hyödyntämällä Lambda SnapStartia Java-työkuormituksissa. Avainasemassa on profiloida, mitkä API-polut ovat todella latency-sensitivejä ja mitkä voivat sietää cold startteja, välttäen provisioned concurrencyn kustannuksia siellä, missä sitä ei tarvita.

MicrocosmWorks toteuttaa saga-mallin hajautettuja transaktioita varten, orkestroiden monipalveluliiketoimintaprosesseja joko koreografian (tapahtumavetoinen) tai orkestroinnin (vaihetoiminto / työnkulkumoottori) kautta kompensoivilla transaktioilla, jotka peruuttavat osittaiset toiminnot puhtaasti, kun vaihe epäonnistuu. Datan konsistenssin osalta käytämme event sourcing- ja CQRS-malleja, joissa jokainen mikropalvelu omistaa oman tietovarastonsa ja julkaisee domain eventejä, joita muut palvelut käyttävät paikallisten read modelien ylläpitämiseen. Tämä eventual consistency -lähestymistapa eliminoi hajautettujen transaktioiden koordinoinnin, joka heikentää serverless-suorituskykyä, kun taas liiketoimintakriittiset toiminnot käyttävät synkronisia varmistusvaiheita silloin kun strong consistency on aidosti tarpeen.

MicrocosmWorks ottaa käyttöön hajautetun jäljityksen (käyttäen AWS X-Rayta, OpenTelemetrya tai Datadog APT:tä), joka korreloi pyynnöt kaikkien mikropalvelurajojen yli yhdellä trace ID:llä, strukturoitua lokitusta, joka sisältää korrelaatiometatiedot jokaisessa lokimerkinnässä, sekä mukautettuja mittaristoja, jotka visualisoivat palveluriippuvuuksia ja latenssiprosentteja. Observointipinossa on automaattinen poikkeamien tunnistus, joka hälyttää latenssipiikeistä, virheprosentin noususta tai epätavallisista kutsumalleista ennen kuin ne vaikuttavat käyttäjiin. Toteutamme myös dead letter queue -valvonnan ja automaattisen uudelleenyritysten näkyvyyden, jotta epäonnistuneet async-operaatiot tulevat esiin välittömästi sen sijaan, että ne katoaisivat äänettömästi, kehityskustannuksilla $20-$40/hr observointi-infrastruktuurin osalta.

MicrocosmWorks suorittaa yksityiskohtaista kustannusmallinnusta, joka vertaa serverless pay-per-invocation -hinnoittelua konttipohjaisiin vaihtoehtoihin (ECS Fargate, EKS) sinun erityiseen liikenneprofiiliisi, koska kannattavuuspiste riippuu vahvasti pyyntöjen määrästä, suorituksen kestosta, muistivaatimuksista ja liikenteen ennustettavuudesta. Serverless on tyypillisesti kustannustehokkaampi purskeisiin, matalan tai kohtalaisen liikenteen kuormiin (alle 1 miljoona kutsua/päivä per funktio), kun taas konttipohjaiset mikropalvelut muuttuvat edullisemmiksi suuren suorituskyvyn vakaan tilan kuormissa, joissa varattu kapasiteetti on täysin hyödynnetty. MicrocosmWorks suosittelee usein hybridiarkkitehtuureja, joissa jotkin palvelut toimivat serverless-periaatteella joustavuuden vuoksi, kun taas suuren liikenteen palvelut toimivat oikein mitoitetuissa konteissa kustannustehokkuuden vuoksi.