Microservices communicating via Axon

Selles lihtsas juhendis loome paar mikroteenust Spring Booti abil ja organiseerime nende vahelise suhtluse Axon raamistikuga.

Oletame, et meil on selline ülesanne.

On olemas tehingute allikas börsil. See allikas edastab meile tehingud REST liidese kaudu.

Me peame need tehingud kätte saama, andmebaasi salvestama ja looma mugava in-memory salvestussüsteemi.

See salvestussüsteem peab täitma järgmisi funktsioone:

• tagastama tehingute loendi;
• tagastama täieliku positsiooni, st tabeli "vahend" — "praegune aktsiate arv";
• tagastama positsiooni antud vahendi kohta.

Kuidas me sellele ülesandele läheneme?

Mikroteenuste moodi kohaselt peame ülesande jagama komponentideks mikroteenusteks:

• saama tehingud RESTi kaudu;
• salvestama tehingud andmebaasi;
• in-memory salvestussüsteem positsioonide andmete esitlemiseks.

Käesoleva juhendi raames loome esmase ja kolmanda teenuse, teise jätame teise osa jaoks (kommentaaridesse kirjutage, kui see huvitab).

Nii et meil on kaks mikroteenust.

Esimene saadab andmeid väljast.

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

Me tahame muidugi saavutada horisontaalset skaleeritavust, katkestusvaba värskendamist ja muid mikroteenuste eeliseid.

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

Tegelikult on neid palju, aga räägime nüüd sellest, kuidas andmed nende mikroteenuste vahel liiguvad. Nende vahel võib ka teha RESTi, kasutada mõnda järjekorda, välja mõelda palju muid asju oma plusside ja miinustega.

Vaadakem ühte võimalikku lähenemist – asünkroonset suhtlemist läbi Axon raamistik.

Millised on sellise lahenduse plussid?

Esiteks, asünkroonne suhtlemine suurendab paindlikkust (jah, siin on ka miinus, kuid räägime praegu ainult plussidest).

Teiseks, saame otse välja arvatud Sündmuste allikaks ja CQRS.
Kolmandaks, Axon annab valmis infrastruktuuri, nii et meie peame keskenduma ainult äriloogika arendamisele.

Hakkame pihta.

Projekt põhineb gradle'il. See sisaldab kolm moodulit:

• common. moodul üldiste andmestruktuuridega (me ei armasta kopeerimist);
• tradeCreator. moodul mikroteenuse jaoks, et vastu võtta tehinguid RESTi kaudu;
• tradeQueries. moodul mikroteenuse jaoks positsiooni kuvamiseks.

Võtame aluseks Spring Booti ja ühendame Axoni aluse.

Axon töötab suurepäraselt ka ilma Springita, kuid me kasutame neid koos.

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

See on klient-server süsteem. On server – see on eraldi rakendus, mida käivitame Dockeris.

Ja on kliendid, mis integreeruvad mikroteenustesse.
Nii et pilt on järgmine. Esiteks käivitatakse Axon-server (Dockeris), seejärel meie mikroteenused.

Käivitusel otsivad mikroteenused serverit ja hakkavad temaga suhtlema. Suhtlemine on tinglikult jagatud kaheks: tehniliseks ja äriliseks.

Tehniline – see on sõnumite vahetus "ma olen elus" (selliseid sõnumeid võib näha debug-režiimis).

Äriline – see on sõnumite vahetus nagu "uus tehing".

Oluline omadus on see, et pärast käivitamist võib mikroteenus küsida Axon-serverilt "mis juhtus" ja server edastab mikroteenusele kogunenud sündmused. Nii saab mikroteenus suhteliselt ohutult taaskäivituda ilma andmete kaota.
Sellise suhtlemise skeemi puhul saame väga lihtsalt käivitada mitu mikroteenuse eksemplari,
isegi erinevates hostides.

Jah, üks Axon-serveri eksemplar ei ole usaldusväärne, aga praegu on see nii.

Me töötame Event Sourcing ja CQRS paradigmades. See tähendab, et meil peavad olema 'käsklused', 'sündmused' ja 'valikud'.

Meil on üks käsklus: 'loo tehing', üks sündmus 'tehing loodud' ja kolm valikut: 'näita kõiki tehinguid', 'näita positsiooni', 'näita positsiooni tööriista järgi'.

Töö skeem on järgmine:

1. Mikroteenus tradeCreator võtab tehingu vastu Rest kaudu.
2. Mikroteenus tradeCreator loob käskluse 'loo tehing' ja saadab selle Axon-serverile.
3. Axon-server võtab käskluse vastu ja edastab selle huvitatud adressaadile, meie puhul mikroteenusele tradeCreator.
4. Mikroteenus tradeCreator saab käskluse, vormib sündmuse 'tehing loodud' ja saadab selle Axon-serverile.
5. Axon-server võtab sündmuse vastu ja edastab selle huvitatud tellijatele.
6. Praegu on meil ainult üks huvitatud adressaat – mikroteenus tradeQueries.
7. Mikroteenus tradeQueries saab sündmuse ja uuendab siseandmeid.

(Oluline, et sündmuse loomise hetkel võib mikroteenus tradeQueries olla mitte kättesaadav, kuid niipea, kui ta käivitub, saab ta kohe sündmuse).

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

Hakake edasi kodeerimisele.

Kuna postitust ei taha koormata koodiga, toon allpool ainult fragmendid, link täispikale näitele tuleb samuti allpool.

Alustame üldise mooduliga common.

Selles on üldised osad - see on sündmus (class CreatedTradeEvent). Pange tähele nimetust, see on põhimõtteliselt meeskonna nimi, mis selle sündmuse tekitas, kuid minevikuvormis. Minevikuvormis, kuna kõigepealt tekib meeskond, mis viib sündmuse loomiseni.

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

Liigume tradeCreator moodulisse.

Selles moodulis on Rest-liidese (class TradeController) jaoks tehingute vastuvõtmise võimalus.
Saadud tehingust moodustatakse käsk «loo 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äsku töödeldakse klassi class TradeAggregate abil.
Kuna Axon peab selle leidma, asetame annotatsiooni @Aggregate.
Käskude töötlemise meetod näeb välja selline (lühendatult):

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

Käskude põhjal moodustatakse sündmus ja saadetakse serverisse.
Käsk asub klassis CreateTradeCommand.

Nüüd vaatame viimast moodulit tradeQueries.

Küsimused on kirjeldatud paketis queries.
Selles moodulis on samuti Rest-liides.
public class TradeController.

Näiteks vaatame päringute töötlemist: «näita kõiki tehinguid».

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

Loetakse päring valiku tegemiseks ja saadetakse serverisse.

Päringu töötlemiseks kasutatakse klassi TradesEventHandler.
Selles on meetod, mis on märgitud annotatsiooniga.

   @QueryHandler
    public List handleFindCurrentPositionQuery(FindCurrentPositionQuery query)

Just tema vastutab andmete valimise eest in-memory andmehoidlast.

Küsimus on, kuidas selles andmehoidlas uut teavet uuendatakse.

Alustame sellest, et see on lihtsalt hulk ConcurrentHashMap'e, mis on suunatud konkreetsetele päringutele.
Nende uuendamiseks kasutatakse 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);
    }

See sündmus "kaubanduse loomine" ja uuendab kaardid.

Need on mikroteenuste arendamise peamised punktid.

Mida saab öelda Axoni puuduste kohta?

Esiteks, see keerustab infrastruktuuri, tekib rikke punkt – Axon server, kõik suhtlused käivad läbi selle.

Teiseks, sarnaste hajutatud süsteemide puudus avaldub selgelt – andmete ajutine konsistentsus. Meie puhul võib uue tehingu saamise ja andmete uuendamise vahel läbida liiga palju aega.

Mis jäi varju?

Kohapeal ei ole midagi öeldud Event Sourcing ja CQRS kohta, mis need on ja milleks neid vaja on.
Ilma nende mõistete selgitamiseta võivad mõned punktid jääda arusaamatuks.

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

Sellest räägime avatud veebinaril 21. septembril.

Täielik näide.

Allikas: habr.com