Hoe u DTO kunt delen met microservices

1. Overzicht

Microservices zijn de afgelopen jaren populair geworden. Een van de essentiële kenmerken van microservices is dat ze modulair, geïsoleerd en eenvoudig schaalbaar zijn. De microservices moeten samenwerken en gegevens uitwisselen. Om dit te bereiken, maken we objecten voor gedeelde gegevensoverdracht, genaamd DTO's.

In dit artikel zullen we manieren presenteren waarop DTO's worden gedeeld tussen microservices.

2. Domeinobjecten blootstellen als DTO

Modellen die het toepassingsdomein vertegenwoordigen, worden beheerd met behulp van microservices. Domeinmodellen zijn verschillende zorgen, en we onderscheiden ze van datamodellen in de DAO-laag.

De belangrijkste reden hiervoor is dat we de complexiteit van ons domein via de diensten niet aan de klanten willen blootstellen. In plaats daarvan stellen we bloot DTO's tussen onze services die applicatieclients bedienen via REST API's. Terwijl DTO's tussen deze services doorgaan, converteren we ze naar domeinobjecten.

De servicegeoriënteerde architectuur hierboven toont schematisch de componenten en de stroom van DTO naar Domain-objecten.

3. DTO-uitwisseling tussen microservices

Neem als voorbeeld het proces van een klant die een product bestelt. Dit proces is gebaseerd op de Klantenorder model. Laten we het proces eens bekijken vanuit de service-architectuur.

Stel dat de klantenservice verzoekgegevens naar de besteldienst stuurt als:

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

De Klant- en Besteldiensten communiceren met elkaar via contracten.Het contract, dat anders een serviceverzoek is, wordt weergegeven in JSON-formaat. Als een Java-model is het BestelDTO class vertegenwoordigt een contract tussen de klantenservice en de besteldienst:

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

3.1. DTO delen met clientmodules (bibliotheken)

Een microservice heeft bepaalde informatie van andere services nodig om een ​​verzoek te verwerken. Stel dat er een derde microservice is die betalingsverzoeken voor bestellingen ontvangt. In tegenstelling tot de bestelservice vereist deze service andere klantinformatie:

openbare klasse CustomerDTO {private String firstName; private String achternaam; privé String cardNumber; // constructor, getters, setters}

Als we ook een bezorgservice toevoegen, zou de klantinformatie het volgende hebben:

openbare klasse CustomerDTO {private String firstName; private String achternaam; private String homeAddress; privé String contactNumber; // constructor, getters, setters}

Dus het plaatsen van de KlantDTO klasse in een gedeelde module dient niet langer het beoogde doel. Om dit op te lossen, benaderen we een andere methode.

Laten we binnen elke microservicemodule een clientmodule (bibliotheek) makenen daarnaast een servermodule:

bestelservice | __ order-client | __ bestelserver

De order-klant module bevat een DTO die wordt gedeeld met de klantenservice. Daarom, de order-klant module heeft de volgende structuur:

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

De OrderClient is een interface die een bestellen methode voor het verwerken van bestelaanvragen:

openbare interface OrderClient {OrderResponse order (OrderDTO orderDTO); }

Om het bestellen methode gebruiken we de RestTemplate bezwaar maken om een ​​POST-verzoek naar de besteldienst te sturen:

String serviceUrl = "// localhost: 8002 / bestelservice"; OrderResponse orderResponse = restTemplate.postForObject (serviceUrl + "/ create", verzoek, OrderResponse.class);

Naast de order-klant module is klaar voor gebruik. Het wordt nu een afhankelijke bibliotheek van het klantenservice module:

[INFO] --- maven-dependency-plugin: 3.1.2: list (default-cli) @ customer-service --- [INFO] De volgende bestanden zijn opgelost: [INFO] com.baeldung.orderservice: order- client: jar: 1.0-SNAPSHOT: compileren

Dit heeft natuurlijk geen zin zonder de bestelserver module om het "/ create" -service-eindpunt bloot te stellen aan de ordercliënt:

@PostMapping ("/ create") openbare OrderResponse createOrder (@RequestBody OrderDTO-verzoek)

Dankzij dit service-eindpunt kan de klantenservice een bestelaanvraag verzenden via zijn bestelklant. Door gebruik te maken van de clientmodule communiceren microservices op een meer geïsoleerde manier met elkaar. Attributen in de DTO worden bijgewerkt binnen de clientmodule. Daarom is het verbreken van contracten beperkt tot services die dezelfde clientmodule gebruiken.

4. Conclusie

In dit artikel hebben we een manier uitgelegd om DTO-objecten tussen microservices te delen. Dit bereiken we in het beste geval door speciale contracten af ​​te sluiten als onderdeel van microserviceklantenmodules (bibliotheken). Op deze manier scheiden we de serviceclient van het servergedeelte dat de API-bron bevat. Als gevolg hiervan zijn er enkele voordelen:

  • Er is geen redundantie in de DTO-code tussen services
  • Het verbreken van contracten is beperkt tot services die dezelfde clientbibliotheek gebruiken

Een codevoorbeeld van een Spring Boot-applicatie is beschikbaar op GitHub.


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