Mikroteenused, mis suhtlevad Axoni kaudu

Selles lihtsas juhendis loome paar mikroteenust Spring Bootiga ja korraldame nendevahelise suhtluse Axoni raamistikuga.

Oletame, et meil on selline ülesanne.

On olemas tehingute allikas aktsiaturul. See allikas edastab meile tehingud REST-liidese kaudu.

Me peame need tehingud kätte saama, salvestama andmebaasi ja looma mugava mälu salvestuse.

See salvestus peab täitma järgmisi funktsioone:

• tagastama tehingute nimekirja;
• tagastama täieliku positsiooni, st tabeli „instrument” — „kehtiv aktsiate arv”;
• tagastama positsiooni määratud instrumendi kohta.

Kuidas me selle ülesande lahendamisele läheneme?

Mikroteenuste trendide kohaselt peame ülesande jagama mikroteenusteks:

• tehingute saamine REST-i kaudu;
• tehingute salvestamine andmebaasi;
• mälu salvestus andmete esitamiseks positsiooni kohta.

Teeme selle juhendi raames esimesed ja kolmanda teenuse, teise jätame teise osa jaoks (kirjutage kommentaaridesse, kui see on huvitav).

Nii et meil on kaks mikroteenust.

Esimene saab andmeid väljastpoolt.

Teine töötleb neid andmeid ja vastab sissetulevatele päringutele.

Me tõepoolest soovime horisontaalset skaleerimist, katkematut uuendamist ja teisi mikroteenuste eeliseid.

Milline, üsna keeruline, ülesanne meie ees seisab?

Tegelikult on neid palju, aga räägime praegu, kuidas andmed nende mikroteenuste vahel liiguvad. Nende vahel saab samuti teha Rest-i, kasutada mingit järjekorda, leiutada palju asju, millel on omad plussid ja miinused.

Vaatame üht võimalikku lähenemist – asünkroonset suhtlemist kaudu Axon-raamistiku.

Millised on sellise lahenduse eelised?

Esiteks, asünkroonse suhtlemisega suureneb paindlikkus (jah, siin on ka miinus, aga räägime praegu ainult plussidest).

Teiseks, saame otse välja pakutud lahenduse. Event Sourcing ja CQRS.
Kolmandaks, Axon pakub valmis infrastruktuuri, ja meie peame keskenduma ainult äriloogika arendamisele.

Alustame.

Meie projekt põhineb gradle-l. See sisaldab kolme moodulit:

• common. moodul, kus on ühised andmestruktuurid (me ei armasta kopeerimist);
• tradeCreator. moodul mikroteenusega tehingute vastuvõtmiseks Rest-i kaudu;
• tradeQueries. moodul mikroteenusega positsiooni kuvamiseks.

Võtame Spring Booti aluseks ja ühendame Axon starter-i.

Axon töötab väga hästi ka ilma Springita, kuid me kasutame neid koos.

Siin tasub peatuda ja paar sõna Axonist rääkida.

See on kliendiserveri süsteem. On server – see on eraldi rakendus, mille käivitame Dockeris.

Ja on kliendid, mis integreeruvad mikroteenustesse.
Saame sellise pildi. Esiteks käivitatakse Axon-server (Dockeris), seejärel meie mikroteenused.

Mikroteenused otsivad serverit ja hakkavad temaga suhtlema. Suhtlemine jaguneb tinglikult kaheks: tehniliseks ja äriliseks.

Tehniline – see on teadevahetus, et "ma olen elus" (selliseid teateid võib näha debug-logimise režiimis).

Äriline – see on teadevahetus, kus on midagi nagu "uus tehing".

Oluline omadus on see, et pärast käivitamist võib mikroteenus küsida Axon-serverilt "mida juhtus" ja server edastab mikroteenusele kogunenud sündmused. Nii võib mikroteenust suhteliselt ohutult taaskäivitada ilma andmete kaotuseta.
Sellise vahetusskeemi korral saame väga lihtsalt käivitada palju mikroteenuste eksemplare,
ja isegi erinevates hostides.

Jah, üks eksemplar Axon-serverist – see pole usaldusväärne, aga praegu on see nii.

Me töötame Event Sourcing ja CQRS paradigmas. See tähendab, et meil peavad olema „käsklused”, „sündmused” ja „valimised”.

Meil on üks käsklus: „luua tehing”, üks sündmus „tehing loodud” ja kolm valikut: „näita kõiki tehinguid”, „näita positsiooni”, „näita positsiooni instrumendi järgi”.

Töö skeem on järgmine:

1. Mikroteenus tradeCreator vastutab tehingu vastuvõtmise eest Rest'i kaudu.
2. Mikroteenus tradeCreator loob käsu „luua tehing” ja saadab selle Axon-serverisse.
3. Axon-server aktsepteerib käsku ja edastab selle huvitatud vastuvõtjale, meie puhul mikroteenusele tradeCreator.
4. Mikroteenus tradeCreator saab käsu, loob sündmuse „tehing loodud” ja saadab selle Axon-serverisse.
5. Axon-server aktsepteerib sündmuse ja edastab selle ettevaatlikult huvitatud tellijatele.
6. Praegu on meil ainult üks huvitatud vastuvõtja – mikroteenus tradeQueries.
7. Mikroteenus tradeQueries saab sündmuse ja värskendab sisemisi andmeid.

(Oluline on, et sündmuse loomise hetkel võib mikroteenus tradeQueries olla mitteaktiivne, kuid kui see käivitatakse, saab ta koheselt sündmuse).

Jah, axon-server seisab suhtluse keskmes, kõik sõnumid liiguvad läbi selle.

Liigume koodimise juurde.

Kuna postitust ei ole mõtet koormata koodiga, toon allpool vaid osad, lingi täismahud on allpool.

Alustame üldmoduuliga common.

Selles on ühised osad – sündmus (class CreatedTradeEvent). Pange tähele, et nimetus on tegelikult selle meeskonna nimi, mis põhjustas selle sündmuse, kuid minevikus. Minevikus, kuna alguses esineb meeskond, mis viib sündmuse loomisele.

Teiste üldiste struktuuride hulka kuuluvad klassid positsiooni (class Position), tehingu (class Trade) ja tehingu pool (enum Side) kirjeldamiseks, st ost või müük.

Liigume mooduli tradeCreator juurde.

Sellel moodulil on Rest-liides (class TradeController) tehingute vastuvõtmiseks.
Saadud tehingust moodustatakse käsk 'looge tehing' ja saadetakse axon-serverisse.

    @PostMapping("/trade")
    public ResponseEntity create(@RequestBody Trade trade) {
        var createTradeCommand = CreateTradeCommand.builder()
                .tradeId(trade.getTradeId())
	...
                .build();
        var result = commandGateway.sendAndWait(createTradeCommand, 3, TimeUnit.SECONDS);
        return ResponseEntity.ok(result.get().toString());
    }

Käsu töötlemiseks kasutatakse klassi class TradeAggregate.
Kuna Axon peab seda leidma, paneme annotatsiooni @Aggregate.
Käskude töötlemise meetod näeb välja selline (lühendatult):

    @CommandHandler
    public TradeAggregate(CreateTradeCommand command) {
        log.info("käsk: {}", command);
        var event = CreatedTradeEvent.builder()
                .tradeId(command.tradeId())
                ....
                .build();
        AggregateLifecycle.apply(event);
    }

Käsust moodustatakse sündmus ja saadetakse serverisse.
Käsk asub klassis CreateTradeCommand.

Nüüd vaatame viimasest moodulist tradeQueries.

Valikud on kirjeldatud paketis queries.
Selles moodulis on samuti Rest-liides.
public class TradeController.

Näitena vaatame päringu töötlemist: "näita kõiki tehinguid."

    @GetMapping("/trade/all")
    public List findAllTrades() {
        return queryGateway.query(new FindAllTradesQuery(),
                ResponseTypes.multipleInstancesOf(Trade.class)).join();
    }

Käiakse päring ja saadetakse serverisse.

Päringu töötlemiseks kasutatakse klassi TradesEventHandler.
Seal on meetod, millele on lisatud annotatsioon.

   @QueryHandler
    public List handleFindCurrentPositionQuery(FindCurrentPositionQuery query)

Just tema vastutab andmete valimise eest in-memory salvestusest.

Küsimus on, kuidas selles salvestuses teave uuendatakse.

Alustame faktist, et see on lihtsalt komplekt ConcurrentHashMap'e, mis on kohandatud konkreetsete valikute jaoks.
Nende värskendamiseks rakendatakse meetodit:

    @EventHandler
    public void on(CreatedTradeEvent event) {
        log.info("event:{}", event);

        var trade = Trade.builder()
	...
                .build();
        trades.put(event.tradeId(), trade);
        position.merge(event.shortName(), event.size(),
                (oldValue, value) -> event.side() == Side.BUY ? oldValue + value : oldValue - value);
    }

Ta aktsepteerib sündmust 'tehing loodud' ja uuendab kaarte.

Need on mikroteenuste arenduse põhijooned.

Mida saab öelda Axoni puuduste kohta?

Esiteks, see keerustab infrastruktuuri, tekib tõrke koht – Axon-server, kõik suhtlused käivad läbi selle.

Teiseks, ilmneb selgelt sarnaste jaotatud süsteemide puudujääk – andmete ajutine järjepidevus. Meie puhul võib uue tehingu saamise ja andmete uuendamise vahel minna lubamatult palju aega.

Mis jäi varju?

Ei ole midagi öeldud Event Sourcingi ja CQRS-i kohta, mis need on ja milleks neid vajatakse.
Ilma nende mõistete selgitamiseta võivad mõned punktid jääda arusaamatuks.

Võib-olla vajavad ka mõned koodifragmentid selgitamist.

Sellest räägime avatud veebinaril 21. septembril.

Täielik näide.

Allikas: habr.com