Hvordan dele DTO på tvers av mikrotjenester

1. Oversikt

Mikrotjenester har blitt populære de siste årene. En av de viktigste egenskapene til mikrotjenester er at de er modulære, isolerte og enkle å skalere. Mikrotjenestene trenger å jobbe sammen og utveksle data. For å oppnå dette oppretter vi delte dataoverføringsobjekter kalt DTO.

I denne artikkelen vil vi presentere måter DTO-er deles mellom mikrotjenester.

2. Å eksponere domeneobjekter som DTO

Modeller som representerer applikasjonsdomenet administreres ved hjelp av mikrotjenester. Domenemodeller er forskjellige bekymringer, og vi skiller dem fra datamodeller i DAO-laget.

Hovedårsaken til dette er at vi ikke ønsker å avsløre kompleksiteten i domenet vårt gjennom tjenestene til kundene. I stedet avslører vi DTO mellom tjenestene våre som betjener applikasjonsklienter gjennom REST APIer. Mens DTO-er passerer mellom disse tjenestene, konverterer vi dem til domeneobjekter.

Den serviceorienterte arkitekturen ovenfor viser skjematisk komponentene og flyt av DTO til domeneobjekter.

3. DTO-deling mellom mikrotjenester

Ta som et eksempel prosessen med at en kunde bestiller et produkt. Denne prosessen er basert på Kundebestilling modell. La oss se på prosessen fra siden av tjenestearkitekturen.

La oss si at kundetjenesten sender forespørselsdata til bestillingstjenesten som:

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

Kunde- og bestillingstjenestene kommuniserer med hverandre ved hjelp av kontrakter.Kontrakten, som ellers er en tjenesteforespørsel, vises i JSON-format. Som en Java-modell er BestillDTO klasse representerer en kontrakt mellom kundeservice og ordretjenesten:

offentlig klasse OrderDTO {private int customerId; private String itemId; // constructor, getters, setters}

3.1. Deling av DTO ved hjelp av klientmoduler (biblioteker)

En mikroservice krever viss informasjon fra andre tjenester for å behandle forespørsler. La oss si at det er en tredje mikrotjeneste som mottar bestillingsforespørsler. I motsetning til bestillingstjenesten krever denne tjenesten annen kundeinformasjon:

offentlig klasse CustomerDTO {privat streng fornavn; privat streng etternavn; private String cardNumber; // constructor, getters, setters}

Hvis vi også legger til en leveringstjeneste, vil kundeinformasjon ha:

offentlig klasse CustomerDTO {privat streng fornavn; privat streng etternavn; private String homeAdresse; privat streng kontaktNummer; // constructor, getters, setters}

Så, plassere CustomerDTO klasse i en delt modul ikke lenger tjener det tiltenkte formålet. For å løse dette, nærmer vi oss en annen metode.

La oss lage en klientmodul (bibliotek) i hver mikroservicemodulog ved siden av en servermodul:

ordretjeneste | __ ordre-klient | __ ordreserver

De ordre-klient modulen inneholder en DTO delt med kundeservice. derfor ordre-klient modulen har følgende struktur:

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

De Bestill klient er et grensesnitt som definerer et rekkefølge metode for behandling av ordreforespørsler:

offentlig grensesnitt OrderClient {OrderResponse order (OrderDTO orderDTO); }

Å implementere rekkefølge metoden bruker vi RestTemplate protesterer mot å sende en POST-forespørsel til bestillingstjenesten:

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

Ved siden av ordre-klient modulen er klar til bruk. Det blir nå et avhengig bibliotek av kundeservice modul:

[INFO] --- maven-avhengighets-plugin: 3.1.2: liste (standard-cli) @ kundeservice --- [INFO] Følgende filer er løst: [INFO] com.baeldung.orderservice: order- klient: jar: 1.0-SNAPSHOT: kompilere

Selvfølgelig har dette ingen hensikt uten ordreserver modul for å eksponere tjenestens endepunkt “/ create” for ordreklienten:

@PostMapping ("/ create") offentlig OrderResponse createOrder (@RequestBody OrderDTO-forespørsel)

Takket være dette tjenestens endepunkt kan kundeservicen sende en bestillingsforespørsel gjennom bestillingsklienten. Ved å bruke klientmodulen kommuniserer mikrotjenester med hverandre på en mer isolert måte. Attributter i DTO oppdateres i klientmodulen. Derfor er kontraktsbrudd begrenset til tjenester som bruker samme klientmodul.

4. Konklusjon

I denne artikkelen forklarte vi en måte å dele DTO-objekter mellom mikrotjenester. I beste fall oppnår vi dette ved å lage spesielle kontrakter som deler av mikroserviceklientmoduler (biblioteker). På denne måten skiller vi tjenesteklienten fra serverdelen som inneholder API-ressursen. Som et resultat er det noen fordeler:

  • Det er ingen redundans i DTO-koden mellom tjenestene
  • Kontraktsbrudd er begrenset til tjenester som bruker samme klientbibliotek

En kodeeksempel på en Spring Boot-applikasjon er tilgjengelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found