streamalism.org

1. Oversigt

Mikrotjenester er blevet populære i de senere år. En af de væsentligste egenskaber ved mikrotjenester er, at de er modulære, isolerede og lette at skalere. Mikrotjenesterne skal arbejde sammen og udveksle data. For at opnå dette opretter vi delte dataoverførselsobjekter kaldet DTO'er.

I denne artikel præsenterer vi måder, hvorpå DTO'er deles mellem mikrotjenester.

2. Eksponering af domæneobjekter som DTO

Modeller, der repræsenterer applikationsdomænet, administreres ved hjælp af mikrotjenester. Domæne modeller er forskellige bekymringer, og vi adskiller dem fra datamodeller i DAO laget.

Hovedårsagen til dette er, at vi ikke ønsker at eksponere kompleksiteten i vores domæne gennem tjenesterne til kunderne. I stedet udsætter vi DTO'er mellem vores tjenester, der betjener applikationsklienter via REST API'er. Mens DTO'er passerer mellem disse tjenester, konverterer vi dem til domæneobjekter.

Den serviceorienterede arkitektur ovenfor viser skematisk komponenterne og flowet af DTO til domæneobjekter.

3. DTO-deling mellem mikrotjenester

Tag som et eksempel processen med, at en kunde bestiller et produkt. Denne proces er baseret på Kundeordre model. Lad os se på processen fra siden af ​​servicearkitekturen.

Lad os sige, at kundeservicen sender anmodningsdata til ordretjenesten som:

"ordre": {"customerId": 1, "itemId": "A152"}

Kunde- og ordretjenesterne kommunikerer med hinanden vha kontrakter.Kontrakten, som ellers er en serviceanmodning, vises i JSON-format. Som en Java-model er BestilDTO klasse repræsenterer en kontrakt mellem kundeservice og ordretjenesten:

offentlig klasse OrderDTO {private int customerId; privat streng itemId; // konstruktør, getters, setters}

3.1. Deling af DTO ved hjælp af klientmoduler (biblioteker)

En mikroservice kræver visse oplysninger fra andre tjenester for at behandle enhver anmodning. Lad os sige, at der er en tredje mikroservice, der modtager ordrebetalingsanmodninger. I modsætning til ordretjenesten kræver denne service forskellige kundeoplysninger:

offentlig klasse CustomerDTO {privat streng fornavn; privat streng efternavn; private String cardNumber; // konstruktør, getters, setters}

Hvis vi også tilføjer en leveringstjeneste, vil kundeoplysninger have:

offentlig klasse CustomerDTO {privat streng fornavn; privat streng efternavn; private String homeAddress; private String contactNumber; // konstruktør, getters, setters}

Så placere CustomerDTO klasse i et delt modul tjener ikke længere det tilsigtede formål. For at løse dette nærmer vi os en anden metode.

Lad os oprette et klientmodul (bibliotek) inden for hvert mikroservicemodulog ved siden af ​​det et servermodul:

ordreservice | __ ordre-klient | __ ordreserver

Det ordre-klient modul indeholder en DTO delt med kundeservice. Derfor er den ordre-klient modul har følgende struktur:

ordreservice └── ordre-klient OrderClient.java OrderClientImpl.java OrderDTO.java 

Det Bestil klient er en grænseflade, der definerer en bestille metode til behandling af ordreanmodninger:

offentlig grænseflade OrderClient {OrderResponse order (OrderDTO orderDTO); }

At implementere bestille metode bruger vi RestTemplate gør indsigelse mod at sende en POST-anmodning til ordretjenesten:

String serviceUrl = "// localhost: 8002 / order-service"; OrderResponse orderResponse = restTemplate.postForObject (serviceUrl + "/ create", anmodning, OrderResponse.class);

Udover det ordre-klient modulet er klar til brug. Det bliver nu et afhængigt bibliotek af kunde service modul:

[INFO] --- maven-afhængigheds-plugin: 3.1.2: liste (standard-cli) @ kundeservice --- [INFO] Følgende filer er løst: [INFO] com.baeldung.orderservice: ordre- klient: jar: 1.0-SNAPSHOT: kompilering

Selvfølgelig har dette intet formål uden ordreserver modul for at eksponere “/ create” -tjenesteendepunktet for ordreklienten:

@PostMapping ("/ create") offentlig OrderResponse createOrder (@RequestBody OrderDTO anmodning)

Takket være dette serviceslutpunkt kan kundeservicen sende en ordreanmodning gennem sin ordreklient. Ved at bruge klientmodulet kommunikerer mikrotjenester med hinanden på en mere isoleret måde. Attributter i DTO opdateres inden for klientmodulet. Derfor er kontraktbrud begrænset til tjenester, der bruger det samme klientmodul.

4. Konklusion

I denne artikel forklarede vi en måde at dele DTO-objekter på mellem mikrotjenester. I bedste fald opnår vi dette ved at indgå specielle kontrakter som dele af mikroservice-klientmoduler (biblioteker). På denne måde adskiller vi serviceklienten fra den serverdel, der indeholder API-ressourcen. Som et resultat er der nogle fordele:

• Der er ingen redundans i DTO-koden mellem tjenester
• Kontraktsbrud er begrænset til tjenester, der bruger det samme klientbibliotek

En kodeeksempel på en Spring Boot-applikation er tilgængelig på GitHub.