Mikropalveluiden viestintämallit (Saga, Circuit Breaker) · Oppitunti

Edistynyt kompensaatiologiikka

Kehittäkää kehittynyttä kompensaatiologiikkaa monimutkaisiin tilanteisiin ja varmistakaa tietojen yhdenmukaisuus myös häiriötilanteissa.

Oppitunti 3/410 vaihetta

Edistynyt kompensaatiologiikka on ilmainen Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-oppitunti CoddyKitissä. Tämä on oppitunti 3/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-kurssilla on yhteensä 4 oppituntia.

Kompensoinnin syvemmät tarpeet

Edellisissä oppitunneissa opimme Saga-mallista ja siitä, kuinka kompensaatiovaiheet kumoavat toimintoja virheen sattuessa. Mutta mitä tapahtuu, kun virheet ovat monimutkaisempia?

Yksinkertaiset palautukset eivät aina riitä hajautetussa järjestelmässä. Tarvitsemme edistynyttä kompensointilogiikkaa monimutkaisten tilanteiden käsittelyyn ja tietojen eheyden varmistamiseen.

Kun yksinkertainen ei riitä

Edistynyt kompensointi on välttämätöntä, kun:

  • Osittainen onnistuminen: Jotkin vaiheet on suoritettu, mutta toiset epäonnistuvat, mikä johtaa epäyhtenäiseen tilaan.
  • Ulkoiset järjestelmät: Ollaan vuorovaikutuksessa kolmannen osapuolen palveluiden kanssa, jotka eivät tarjoa välitöntä palautusta.
  • Ei-idempotentit operaatiot: Toimintoja ei voi yksinkertaisesti kumota suorittamalla peruskompensaatiovaihe uudelleen.
  • Monimutkaiset liiketoimintasäännöt: Kompensointilogiikka riippuu tietyistä ehdoista tai tiedoista.

Idempotentin kompensoinnin suunnittelu

Vankan kompensoinnin tärkeä osa on tehdä siitä idempotenttia. Tämä tarkoittaa, että kompensaatiotoiminnon suorittaminen useita kertoja tuottaa saman vaikutuksen kuin sen suorittaminen kerran.

Tämä on tärkeää luotettavuuden kannalta, koska viestejä voidaan monistaa tai yrittää uudelleen. Kompensointilogiikan tulisi aina tarkistaa nykyinen tila ennen toiminnon kumoamisen yrittämistä.

Kokeilkaa tämän esimerkin suorittamista:

public class OrderService {

    private boolean isRefunded(String orderId) {
        // Simulate checking a database or payment system
        System.out.println("Checking if order " + orderId + " is already refunded...");
        // In a real system, this would query a persistent store
        return false; // For demo, assume not refunded initially
    }

    public void compensateOrderPayment(String orderId) {
        System.out.println("Attempting compensation for order: " + orderId);
        if (isRefunded(orderId)) {
            System.out.println("Order " + orderId + " already refunded. No action needed.");
            return;
        }
        // Simulate refunding logic
        System.out.println("Initiating refund for order: " + orderId);
        // ... actual refund processing ...
        System.out.println("Refund processed for order: " + orderId);
        // In a real system, this would update the 'refunded' status
    }

    public static void main(String[] args) {
        OrderService service = new OrderService();
        String orderId = "ORDER-123";
        service.compensateOrderPayment(orderId);
        System.out.println("\nSimulating a retry or duplicate message:");
        service.compensateOrderPayment(orderId); // Should ideally be idempotent
    }
}

Tilasta riippuva kompensointi

Joskus itse kompensaatiotoiminto riippuu tietystä virheestä tai järjestelmän nykyisestä tilasta. Jos esimerkiksi varastotuote on varattu mutta sitä ei ole lähetetty, varaus voidaan vain vapauttaa täyden hyvityksen käsittelyn sijaan.

Tämä edellyttää ehtotarkistusten lisäämistä kompensointilogiikkaan.

Kokeilkaa tämän esimerkin suorittamista:

public class InventoryService {

    private enum InventoryState { RESERVED, SHIPPED, AVAILABLE }

    private InventoryState getItemState(String itemId) {
        // Simulate checking inventory status from a database
        System.out.println("Checking state for item: " + itemId);
        // In a real system, this would query a persistent store
        return InventoryState.RESERVED; // Let's assume it's reserved for this demo
    }

    public void compensateInventoryReservation(String itemId) {
        System.out.println("Attempting compensation for item: " + itemId);
        InventoryState currentState = getItemState(itemId);

        if (currentState == InventoryState.SHIPPED) {
            System.out.println("Item " + itemId + " was already shipped. Cannot directly un-reserve.");
            System.out.println("Manual intervention or a different compensation for shipped items might be needed.");
        } else if (currentState == InventoryState.RESERVED) {
            System.out.println("Item " + itemId + " is reserved. Releasing reservation.");
            // Simulate releasing the reservation
            System.out.println("Reservation released for item: " + itemId);
        } else {
            System.out.println("Item " + itemId + " is not reserved or is available. No action needed.");
        }
    }

    public static void main(String[] args) {
        InventoryService service = new InventoryService();
        String itemId = "ITEM-456";
        service.compensateInventoryReservation(itemId);
    }
}

Ulkoiset järjestelmät ja kompensointi

Ulkoisia kolmannen osapuolen palveluita, kuten maksunvälityspalveluita, kuljetusliikkeitä ja CRM-järjestelmiä, käyttävät kompensaatiotoiminnot tuovat mukanaan erityisiä haasteita.

  • Suoraa palautusta ei ole: Ulkoista API-kutsua ei voi suoraan ”kumota”. On käytettävä palvelun tarjoamia kompensaatiomekanismeja, kuten hyvitys- tai peruutus-APIa.
  • Asynkronisuus: Ulkoiset järjestelmät saattavat käsitellä pyynnöt asynkronisesti, mikä vaikeuttaa kompensoinnin kannalta tarkan tilan määrittämistä.
  • Rajoitukset ja käytettävyys: Kompensaatiokutsut voivat epäonnistua ulkoisten järjestelmien ongelmien vuoksi, mikä edellyttää uudelleenyrityksiä ja vankkaa virheenkäsittelyä.

Kun ihmiset astuvat mukaan

Parhaista yrityksistämme huolimatta joitakin monimutkaisia virheitä tai kriittisiä epäyhtenäisyyksiä ei voida ratkaista kokonaan pelkän automaattisen kompensointilogiikan avulla. Tällöin tarvitaan manuaalista puuttumista tai ”ihmisten sagaa”.

Ihmisten saga tarkoittaa, että operaattorille tai tukitiimille ilmoitetaan, kun automaattinen kompensointi epäonnistuu tai järjestelmä havaitsee tilan, josta ei voida palautua. Näin he voivat korjata ongelman manuaalisesti.

  • Hälytykset: Määrittäkää hälytykset epäonnistuneille kompensaatiovaiheille.
  • Koontinäytöt: Tarjotkaa näkyvyys odottaviin tai epäonnistuneisiin sagoihin.
  • Työkalut: Kehittäkää sisäisiä työkaluja tietojen manuaaliseen korjaamiseen tai kompensoinnin käynnistämiseen uudelleen.

Kompensoinnin kehittäminen

Mikropalvelut kehittyvät, samoin niiden tietomallit ja liiketoimintalogiikka. Tämä tarkoittaa, että myös kompensointilogiikan on kehityttävä. Mitä tapahtuu sagalle, joka käynnistyi palvelun vanhalla versiolla, kun virhe ilmenee päivityksen jälkeen?

Kompensoinnin versiointistrategioita:

  • Taaksepäin yhteensopivuus: Suunnitelkaa uusi kompensointilogiikka käsittelemään vanhempia sagan tiloja.
  • Sagan versiointi: Tallentakaa sagan määritelmän versio sagan tilan yhteyteen.
  • Siirto: Merkittävissä muutoksissa siirtäkää käynnissä olevat sagat uuteen kompensointilogiikkaan, jos mahdollista.

Kompensoinnin seuranta

Kompensaatiovaiheen epäonnistuminen on kriittinen tapahtuma. Jos itse kompensointi epäonnistuu, järjestelmä voi jäädä epäyhtenäiseen tilaan, mikä voi johtaa tietojen korruptoitumiseen tai haittoihin liiketoiminnalle.

On tärkeää:

  • Kirjata kompensointiyritykset: Tallentaa jokainen kompensaatiotoiminto, sen tila ja mahdolliset virheet.
  • Seurata epäonnistumisasteita: Seurata, kuinka usein kompensaatiovaiheet epäonnistuvat.
  • Määrittää hälytykset: Ilmoittaa käyttötiimeille välittömästi, jos kompensoinnin epäonnistumiset ylittävät raja-arvot.
  • Jäljittää kompensointipolut: Käyttää hajautettua jäljitystä sen ymmärtämiseen, miksi kompensointi epäonnistui.

Kompensoinnin haasteet

Mitkä seuraavista ovat keskeisiä näkökohtia suunniteltaessa edistynyttä kompensointilogiikkaa mikropalveluille?

Kertaus: Kehittyneet palautukset

Tutustuimme siihen, kuinka mikropalveluissa voidaan siirtyä peruspalautuksista edistyneeseen kompensointilogiikkaan.

  • Korostimme idempotenssia ja ehtologiikkaa vankan kompensoinnin perustana.
  • Käsittelimme ulkoisten järjestelmien monimutkaisuutta ja manuaalisen puuttumisen välttämättömyyttä kriittisissä virheissä.
  • Lopuksi käsittelimme kompensoinnin versiointia ja valvontaa koskevia strategioita pitkäaikaisen eheyden ja luotettavuuden varmistamiseksi.

Näiden tekniikoiden hallinta on olennaista aidosti vikasietoisten hajautettujen järjestelmien rakentamisessa.

Aloita maksutta

Opi Mikropalveluiden viestintämallit (Saga, Circuit Breaker) tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit
12
Oppitunnit
48

Usein kysytyt kysymykset

Onko oppitunti ”Edistynyt kompensaatiologiikka” ilmainen?

Kyllä – oppitunnin ”Edistynyt kompensaatiologiikka” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-kurssin, päivitä CoddyKit PROhon. Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”Edistynyt kompensaatiologiikka”?

Kehittäkää kehittynyttä kompensaatiologiikkaa monimutkaisiin tilanteisiin ja varmistakaa tietojen yhdenmukaisuus myös häiriötilanteissa. Harjoittelet Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 3/4.

Kuinka kauan ”Edistynyt kompensaatiologiikka”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-oppitunnilla?

Kyllä. Jokainen Mikropalveluiden viestintämallit (Saga, Circuit Breaker)-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

  1. Idempotenssin varmistaminen Sagoissa
  2. Sagoihin sovellettavat uudelleenyritysstrategiat
  3. Edistynyt kompensaatiologiikka
  4. Semanttiset lukot ja samanaikaiset sagat
← Takaisin: Mikropalveluiden viestintämallit (Saga, Circuit Breaker)