Kako podijeliti DTO na mikroservisima

1. Pregled

Mikroservisi postali su popularni posljednjih godina. Jedna od bitnih karakteristika mikro usluga je njihova modularnost, izoliranost i lako skaliranje. Mikroservisi moraju surađivati ​​i razmjenjivati ​​podatke. Da bismo to postigli, stvaramo zajedničke objekte za prijenos podataka koji se nazivaju DTO.

U ovom ćemo članku predstaviti načine na koje se DTO dijele između mikro usluga.

2. Izlaganje objekata domene kao DTO

Modeli koji predstavljaju domenu aplikacije upravljaju se pomoću mikroservisa. Modeli domena su različita briga i mi ih odvajamo od modela podataka u sloju DAO.

Glavni razlog tome je što klijentima ne želimo izložiti složenost naše domene putem usluga. Umjesto toga, mi izlažemo DTO između naših usluga koje opslužuju klijente aplikacija putem REST API-ja. Dok DTO prolaze između ovih usluga, mi ih pretvaramo u objekte domene.

Uslužno orijentirana arhitektura gore shematski prikazuje komponente i protok DTO-a u objekte domene.

3. DTO dijeljenje između mikro usluga

Uzmimo za primjer postupak kupca koji naručuje proizvod. Ovaj se postupak temelji na Narudžba kupca model. Pogledajmo postupak sa strane arhitekture usluge.

Recimo da Korisnička služba šalje podatke zahtjeva usluzi Naručivanje kao:

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

Usluge kupca i narudžbe međusobno komuniciraju pomoću ugovorima.Ugovor, koji je inače zahtjev za uslugom, prikazuje se u JSON formatu. Kao Java model, NaručiDTO klasa predstavlja ugovor između korisničke službe i usluge narudžbe:

javni razred OrderDTO {private int customerId; private String itemId; // konstruktor, getteri, postavljači}

3.1. Dijeljenje DTO-a pomoću klijentskih modula (knjižnica)

Mikroservis zahtijeva određene podatke drugih službi za obradu bilo kojeg zahtjeva. Recimo da postoji treća mikro usluga koja prima zahtjeve za plaćanje naloga. Za razliku od usluge Naručivanje, ova usluga zahtijeva drugačije podatke o kupcu:

javna klasa CustomerDTO {private String firstName; private String lastName; private String cardNumber; // konstruktor, getteri, postavljači}

Ako dodamo i uslugu dostave, podaci o kupcu imali bi:

javna klasa CustomerDTO {private String firstName; private String lastName; private String homeAddress; private String contactNumber; // konstruktor, getteri, postavljači}

Dakle, postavljanje CustomerDTO klasa u zajedničkom modulu više ne služi namjeni. Da bismo to riješili, pristupamo drugoj metodi.

Unutar svakog mikroservisnog modula napravimo klijentski modul (knjižnicu)a pored njega poslužiteljski modul:

narudžba-usluga | __ narudžba-klijent | __ poslužitelj narudžbe

The narudžba-klijent modul sadrži DTO koji se dijeli s korisničkom službom. Stoga je narudžba-klijent modul ima sljedeću strukturu:

narudžba-usluga └── narudžba-klijent OrderClient.java OrderClientImpl.java OrderDTO.java 

The Naručitelj je sučelje koje definira narudžba način obrade zahtjeva za narudžbu:

javno sučelje OrderClient {OrderResponse order (OrderDTO orderDTO); }

Za provedbu narudžba metodu koristimo RestTemplate objekt za slanje POST zahtjeva službi za narudžbe:

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

Osim toga, narudžba-klijent modul je spreman za upotrebu. Sada postaje ovisna knjižnica služba za korisnike modul:

[INFO] --- dodatak za ovisnost maven: 3.1.2: popis (zadana-kli) @ korisnička usluga --- [INFO] Riješene su sljedeće datoteke: [INFO] com.baeldung.orderservice: order- klijent: jar: 1.0-SNAPSHOT: kompajliranje

Naravno, ovo nema svrhu bez poslužitelj naloga modul za izlaganje krajnje točke usluge „/ create“ klijentu narudžbe:

@PostMapping ("/ create") javni OrderResponse createOrder (@RequestBody OrderDTO zahtjev)

Zahvaljujući ovoj krajnjoj točki usluge, korisnička služba može poslati zahtjev za narudžbu putem svog klijenta narudžbe. Korištenjem klijentskog modula mikrousluge međusobno komuniciraju na izoliraniji način. Atributi u DTO-u ažuriraju se u modulu klijenta. Stoga je raskid ugovora ograničen na usluge koje koriste isti klijentski modul.

4. Zaključak

U ovom smo članku objasnili način dijeljenja DTO objekata između mikro usluga. U najboljem slučaju to postižemo sklapanjem posebnih ugovora kao dijelova klijentskih modula mikroservisa (knjižnica). Na taj način odvajamo klijenta usluge od poslužiteljskog dijela koji sadrži API resurs. Kao rezultat, postoje neke prednosti:

  • U DTO kodu nema suvišnosti između usluga
  • Prekid ugovora ograničen je na usluge koje koriste istu knjižnicu klijenta

Uzorak koda aplikacije Spring Boot dostupan je na GitHubu.


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