Ako zdieľať DTO naprieč mikroslužbami

1. Prehľad

Mikroslužby sa v posledných rokoch stali populárnymi. Jednou zo základných charakteristík mikroslužieb je to, že sú modulárne, izolované a ľahko škálovateľné. Mikroslužby musia spolupracovať a vymieňať si údaje. Aby sme to dosiahli, vytvárame zdieľané objekty na prenos dát, ktoré sa nazývajú DTO.

V tomto článku predstavíme spôsoby zdieľania DTO medzi mikroslužbami.

2. Vystavenie doménových objektov ako DTO

Modely, ktoré predstavujú doménu aplikácie, sa spravujú pomocou mikroslužieb. Doménové modely sa líšia a oddelíme ich od dátových modelov vo vrstve DAO.

Hlavným dôvodom je to, že nechceme klientom vystavovať komplexnosť našej domény prostredníctvom služieb. Namiesto toho vystavujeme DTO medzi našimi službami, ktoré slúžia aplikačným klientom prostredníctvom rozhraní REST API. Zatiaľ čo DTO prechádzajú medzi týmito službami, prevádzame ich na objekty domény.

Vyššie uvedená architektúra orientovaná na služby zobrazuje schematicky komponenty a tok DTO k objektom Domain.

3. Zdieľanie DTO medzi mikroslužbami

Vezmime si ako príklad proces objednávania produktu zákazníkom. Tento proces je založený na Zákaznícka objednávka Model. Pozrime sa na proces zo strany architektúry služieb.

Povedzme, že zákaznícka služba odosiela údaje žiadosti objednávkovej službe ako:

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

Služby Zákazník a Objednávka navzájom komunikujú pomocou zmluvy.Zmluva, ktorá je inak požiadavkou na službu, sa zobrazuje vo formáte JSON. Ako model Java je OrderDTO trieda predstavuje zmluvu medzi zákazníckou službou a objednávkovou službou:

verejná trieda OrderDTO {private int customerId; private String itemId; // konštruktor, getri, nastavovatelia}

3.1. Zdieľanie DTO pomocou klientskych modulov (knižnice)

Mikroslužba vyžaduje na spracovanie akejkoľvek žiadosti určité informácie od iných služieb. Povedzme, že existuje tretia mikroslužba, ktorá prijíma žiadosti o platbu za objednávku. Na rozdiel od objednávkovej služby vyžaduje táto služba odlišné informácie o zákazníkovi:

verejná trieda CustomerDTO {private String firstName; private String priezvisko; privátny reťazec cardNumber; // konštruktor, getri, nastavovatelia}

Ak pridáme aj doručovateľskú službu, informácie o zákazníkovi by mali:

verejná trieda CustomerDTO {private String firstName; private String priezvisko; private String homeAddress; private String contactNumber; // konštruktor, getri, nastavovatelia}

Takže umiestnenie CustomerDTO trieda v zdieľanom module už neslúži zamýšľanému účelu. Aby sme to vyriešili, pristupujeme k inej metóde.

V rámci každého modulu mikroslužieb vytvorme klientský modul (knižnicu)a vedľa neho modul servera:

objednávková služba | __ objednávkový klient | __ objednávkový server

The objednávkový klient modul obsahuje DTO zdieľaný so zákazníckym servisom. Preto objednávkový klient modul má nasledujúcu štruktúru:

order-service └──order-client OrderClient.java OrderClientImpl.java OrderDTO.java 

The OrderClient je rozhranie, ktoré definuje objednať spôsob spracovania požiadaviek na objednávku:

verejné rozhranie OrderClient {OrderResponse order (OrderDTO orderDTO); }

Implementovať objednať metóda, používame RestTemplate objekt na odoslanie žiadosti POST službe Objednávka:

Reťazec serviceUrl = "// localhost: 8002 / order-service"; OrderResponse orderResponse = restTemplate.postForObject (serviceUrl + "/ create", request, OrderResponse.class);

Okrem toho objednávkový klient modul je pripravený na použitie. Teraz sa stáva závislou knižnicou zákaznícky servis modul:

[INFO] --- plugin maven-dependency: 3.1.2: list (default-cli) @ customer-service --- [INFO] Boli vyriešené nasledujúce súbory: [INFO] com.baeldung.orderservice: order- klient: jar: 1.0-SNAPSHOT: kompilácia

Toto samozrejme nemá účel bez objednávkový server modul vystaviť koncový bod služby „/ create“ klientovi objednávky:

@PostMapping ("/ create") verejná OrderResponse createOrder (požiadavka @RequestBody OrderDTO)

Vďaka tomuto koncovému bodu služby môže zákaznícky servis poslať požiadavku na objednávku prostredníctvom svojho objednávkového klienta. Pomocou klientskeho modulu komunikujú mikroslužby medzi sebou izolovanejšie. Atribúty v DTO sa aktualizujú v rámci klientskeho modulu. Preto sa porušovanie zmlúv obmedzuje na služby, ktoré používajú rovnaký klientský modul.

4. Záver

V tomto článku sme vysvetlili spôsob zdieľania objektov DTO medzi mikroslužbami. V najlepšom prípade to dosiahneme vytvorením osobitných zmlúv ako súčasti modulov klienta (knižnice) mikroslužieb. Týmto spôsobom oddelíme klienta služby od časti servera, ktorá obsahuje prostriedok API. Výsledkom sú určité výhody:

  • V kóde DTO medzi službami nie je redundancia
  • Porušenie zmluvy je obmedzené na služby, ktoré používajú rovnakú knižnicu klientov

Ukážka kódu aplikácie Spring Boot je k dispozícii na GitHub.


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