Oversættelse
Beskedudveksling er en grundlæggende del af ethvert distribueret system. Det giver en producent mulighed for at sende en besked til et vilkårligt antal forbrugere, og det er ikke nødvendigt at kende nogen information om forbrugeren. Dette er en stor hjælp til virkelig asynkron og afkoblet kommunikation.
Når du bruger RabbitMQ, viser diagrammet ovenfor en meget grundlæggende, men typisk struktur. En producer sender en besked til switchen. Ifølge routinglogikken lægger switchen beskeden i køen, der er bundet til switchen. Mere specifikt, hvis det er en broadcast-type switch, vil kopien af denne besked blive sendt til hver kø gentagne gange. En forbruger kan derefter modtage og behandle beskeden.
En vigtig antagelse for, at ovenstående struktur kan fungere succesfuldt for producenter og forbrugere, er, at alle RabbitMQ-komponenter (dvs. køer, switche og bindings) skal oprettes på forhånd. En forbruger kan ikke sende en besked til en switch. Hvis switchen ikke eksisterer, kan en forbruger ikke behandle beskeder fra en kø, der ikke eksisterer.
Derfor er det ikke svært at forstå, at før producent/forbruger sender/modtager beskeden, skal en producent/forbruger-værdi oprette et kø-, skifte- og bindingsforhold. Lad os se på fordele og ulemper ved hver metode.
1. Skel mellem ansvarsområder
Billedoversættelse (1. Producenten opretter en switch 2. Forbrugeren opretter en kø og binder køen til switchen)
For at producenter og forbrugere fuldt ud kan adskille sig, ved producenterne ideelt set kun information om switchen (ikke køen), og forbrugerne kender kun til køen (ikke switchen). Bindingsforholdet angiver forholdet mellem switchen og køen
En mulig måde er, at producenten håndterer oprettelsen af switchen, og forbrugeren opretter køen og binder køen til switchen. Fordelen ved denne frakoblingsmetode er, at hvis forbrugeren har brug for en kø, er det blot nødvendigt at oprette en kø og binde dem efter efterspørgslen, og producenten behøver ikke kende nogen information om køen. Men dette er ikke en tilstrækkelig afkobling: fordi forbrugeren skal kende kontakten for at kunne binde den.
2. Producenter skaber alting
Når produceren kører, kan den konfigureres til at skabe alle de nødvendige komponenter (switches, køer og bindings). Fordelen ved denne tilgang er, at ingen beskeder går tabt (fordi køen allerede er oprettet og bundet til switchen, og ingen forbruger behøver at starte den først).
Det betyder dog, at producenten skal kende alle køer, der skal knyttes til switchen. Dette er en meget koblet måde. Årsagen er, at hver gang en ny kø skal tilføjes, skal producenten omkonfigurere og implementere for at oprette og binde køer
3. Forbrugerne skaber alting
Det modsatte er at lade forbrugeren oprette de switches, køer og bindings, den har brug for, mens den kører. Som i den tidligere tilgang skaber denne metode kobling, fordi forbrugeren skal kende informationen om den switch, de er bundet til køen. Enhver ændring af switchen (såsom omdøbning) betyder, at alle forbrugere skal omkonfigureres og implementeres. Når der er store køer og forbrugere, kan denne kompleksitet være for meget.
4. Ingen af dem skaber noget
En helt anden tilgang er, at hverken producenten eller forbrugeren skal skabe de nødvendige komponenter. I stedet oprettes det ved hjælp af brugergrænsefladen i admin-plugin'et eller admin-CLI'en på forhånd. Denne metode er baseret på følgende fordele:
- Producenter og forbrugere kan være fuldstændig adskilte. Producenterne kender kun udvekslingen, og forbrugerne kender kun køen.
- Dette kan nemt scriptes og automatiseres som en del af deployment-pipelinen
- Enhver ændring, såsom nye køer, kan tilføjes uden at røre eksisterende, implementerede udgivere og forbrugere
resumé
I distribuerede systemer er asynkrone beskeder en nyttig måde at afkoble på, men for at holde dem adskilt er det nødvendigt at opretholde en effektiv strategi for vedligeholdelse af den underliggende beskedstruktur (i RabbitMQ er det køer, switches og bindings).
Selvom udgiver- og forbrugertjenester kan være ansvarlige for selv at skabe det, de har brug for, kan de være dyre i forhold til indledende beskedtab, kobling og operationel vedligeholdelse (i forhold til konfiguration og implementering).
Sandsynligvis den bedste måde at håndtere beskedsystemkonfiguration, hvor det hører hjemme: skriv scripts uden for applikationen. Dette sikrer, at tjenester forbliver adskilte, og at køsystemet kan ændres dynamisk efter behov uden at påvirke et stort antal eksisterende tjenester.
Oprindelig:Hyperlink-login er synlig.
Originalengelsk:Hyperlink-login er synlig.
|
Opslået på 03/05/2023 22.31.59
|
|
|
|
