Java >> Java tutorial >  >> Java

Opbygning af mikrotjenester med begivenhedsdrevet arkitektur

Java

I dette indlæg vil vi diskutere, hvordan vi kan bygge mikrotjenester med begivenhedsdrevet arkitektur. Som en del af indlægget vil jeg også vise et eksempel på en begivenhedsdrevet mikroservice. Hvis du ikke ved, hvad en mikroservice er, kan du starte med min primer her.

Mikrotjenester – begivenhedsdrevet arkitektur

Traditionelt ville vi bruge en REST-baseret mikroservice. I denne mikrotjeneste ville en klient anmode om data, og derefter ville serveren svare med dataene. Men der var ulemper ved, at klienten skal vente på, at serveren reagerer. En server kan være nede eller betjene andre anmodninger, i gang med at forsinke svaret på de aktuelle klientanmodninger.

Kort sagt, når et system bliver langsomt på grund af synkroniserede forbindelser, kan vi bruge hændelsesdrevet arkitektur til at gøre systemet asynkront.

Event-Drive-mikrotjenester bruger en efterhånden ensartet tilgang. Hver tjeneste udgiver hændelsesdata, når der er en opdatering eller transaktion. Andre tjenester abonnerer på denne tjenestes udgivelsesbegivenheder. Når disse abonnerede tjenester modtager en begivenhed, opdaterer de deres data.

Et simpelt eksempel på denne fremgangsmåde:Når en kunde indløser et gavekort, oprettes en enkelt indløsningsbegivenhed og forbruges af forskellige tjenester.

  1. En belønningstjeneste, der kan skrive en indløsningspost i databasen
  2. En kunde, der modtager en vare købt via et gavekort
  3. En partnerservice, der bekræfter gavekortet og tillader indløsning og tilsvarende behandling af varen, som kunden har købt.

Event-drevet arkitektur er enten gennem køer eller pub-sub-modellen. I Pub/Sub-modellen udgiver en tjeneste hændelsen, og abonnerede tjenester forbruger denne hændelse. Det er ikke meget anderledes end hvad køer og emner gør.

Fordele ved begivenhedsdrevet arkitektur

  • Løs kobling – Tjenester behøver ikke at være afhængige af andre tjenester. I betragtning af at arkitekturen er reaktiv, kan tjenester være uafhængige af hinanden.
  • Asynkron – En forlagstjeneste vil offentliggøre begivenheden. En abonnementstjeneste kan forbruge begivenheden, når den er klar til at forbruge. Den største fordel ved asynkron arkitektur er, at tjenester ikke blokerer for ressourcer.
  • Skalering – Da tjenesterne er uafhængige, udfører de fleste tjenester en enkelt opgave. Det bliver også nemmere at skalere at finde ud af flaskehals.

Ulemper ved begivenhedsdrevet arkitektur

Hvert design er en afvejning. Vi har ikke et perfekt design i distribuerede systemer. Med begivenhedsdrevet arkitektur kan man nemt overkonstruere løsningen ved at adskille bekymringer.

Event-drevet arkitektur kræver forudgående investering. Da dataene ikke nødvendigvis er tilgængelige med det samme, kan det forårsage nogle bekymringer med transaktioner. Eventuel konsistens kan være svær at undersøge, hvis der er problemer med data. Der kan være muligheder for duplikerede hændelser, hvilket resulterer i duplikerede data. Hændelsesdrevne modeller understøtter ikke ACID-transaktioner.

Ramme for arkitektur

Uanset disse ulemper er begivenhedsdrevet arkitektur hurtig og leverer succesfulde resultater. Så det næste spørgsmål opstår, hvilken ramme man skal vælge for at bygge denne arkitektur. I øjeblikket er der to valgmuligheder

  • Beskedbehandling
  • Strømbehandling

Beskedbehandling

Ved meddelelsesbehandling opretter en tjeneste en meddelelse og sender den til destinationen. En abonnementstjeneste henter beskeden fra den destination. I AWS bruger vi SNS (Simple Notification Service) og SQS (Simple Queue Service). En tjeneste sender en besked til et emne, og en kø, der abonnerer på det pågældende emne, opfanger den besked og behandler den videre.

SNS og SQS er ikke de eneste rammer derude. Meddelelseskøer bruger et butiks- og videresendingssystem af mæglere, hvor begivenheder rejser fra mægler til mægler. ActiveMQ og RabbitMQ er de to andre eksempler på beskedkøer

Strømbehandling

I stream-behandling sender en tjeneste en begivenhed, og den abonnerede tjeneste afhenter begivenheden. Ikke desto mindre er begivenheder ikke til et bestemt mål.

Normalt udsender en producent af begivenheder begivenheder og kan opbevare dem på lager. En forbruger af begivenheder kan forbruge disse begivenheder fra datalageret. Den mest populære ramme for strømbehandling er Kafka. Grundlæggende følger den en pub-sub-model.

Frem for alt tilbyder stream-processorer (som Kafka) datas holdbarhed. Data går ikke tabt, og hvis systemet går offline, kan det gengive historien om begivenheder.

Demo af begivenhedsdrevet arkitekturbaseret mikroservice

Som en del af denne demo vil vi implementere en Spring Boot-applikation sammen med ActiveMQ-meddelelsesmæglertjenesten.

ActiveMQ Messaging Service

ActiveMQ er en open source-meddelelsesmægler. I øjeblikket understøtter det klienter skrevet i Java, Python, .Net, C++ og mere.

Download ActiveMQ herfra. Når du har udtrukket den downloadede mappe på din maskine, kan du gå til bin bibliotek for at starte ActiveMQ-serveren med kommandoen activemq.bat start . Dette vil starte ActiveMQ-serveren ved http://localhost:8161 .

Afsenderapplikation med Spring Boot

Lad os nu oprette en Message Sender-applikation ved hjælp af Spring Boot. Vi skal bruge følgende afhængigheder


dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-activemq'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

Vi tilføjer JMS-konfiguration for at oprette en ActiveMQ-kø.


@Configuration
public class JmsConfig
{
    @Bean
    public Queue queue()
    {
        return new ActiveMQQueue("demo-queue");
    }
}

Dette skaber en bean for vores kø demo-queue . For at sende besked til denne kø via vores afsenderapplikation, vil vi oprette en REST API som følger:


@RestController
@RequestMapping("/v1/betterjavacode/api")
public class MessageController
{
    @Autowired
    private Queue queue;

    @Autowired
    private JmsTemplate jmsTemplate;

    @GetMapping("/message/")
    public ResponseEntity sendMessage(@RequestBody String message)
    {
        jmsTemplate.convertAndSend(queue, message);
        return new ResponseEntity(message, HttpStatus.OK);
    }

}

Efterfølgende har vi injiceret queue og jmsTemplate bønner i vores RestController, så vi kan sende beskeden.

På den anden side vil vi også have en modtagerapplikation, som vil være en destinationstjeneste eller forbrugertjeneste, der forbruger beskeden fra afsenderapplikationen.

Opret en besked forbrugerklasse i vores modtagerapplikation


@Component
@EnableJms
public class MessageConsumer
{
    private final Logger logger = LoggerFactory.getLogger(MessageConsumer.class);

    @JmsListener(destination = "demo-queue")
    public void receiveMessage(String message)
    {
        // TO-DO
        logger.info("Received a message = {}", message);
    }
}

Annoteringen af ​​@JmsListener med destination gør, at applikationen lytter til den kø. @EnableJms aktiverer annotationen @JmsListener .

Vi mangler stadig at tilføje ActiveMQ-egenskaber, så begge applikationer ved, hvor ActiveMQ-serveren kører. Så tilføj følgende egenskaber til application.properties 


spring.activemq.broker-url=tcp://localhost:61616
spring.activemq.user=admin
spring.activemq.password=admin

Start nu begge Spring Boot-applikationer. Sender Application kører på 8080 og Receiver Application kører på 8081.

Hvis vi nu tjekker logfilerne for modtagerapplikationen, vil vi se, at den har brugt den besked fra ActiveMQ-køen demo-queue .

Vi kan også se status for køen i ActiveMQ-serveren.

Her kan du se, at der har været to beskeder, som køen har modtaget fra afsenderen og leveret til forbrugeren. Koden til denne demo er tilgængelig på mit github-lager.

Konklusion

I dette indlæg diskuterede jeg begivenhedsdrevet arkitektur til mikrotjenester. Vi diskuterede også fordele og ulemper ved denne arkitektur. Til sidst viste vi, hvordan vi kan bruge ActiveMQ til at opsætte en begivenhedsdrevet arkitekturbaseret mikroservice til asynkron kommunikation.

På en anden note, hvis du stadig ikke har købt min bog til Spring Security, kan du købe her ELLER du kan læse mere om den her.

Referencer

Hændelsesdrevne mikrotjenester, der bruger ActiveMQ – ActiveMQ


Java tag