Oversettelse
Meldinger er en grunnleggende del av ethvert distribuert system. Det lar en produsent sende en melding til et hvilket som helst antall forbrukere, og det er ikke nødvendig å vite noe informasjon om forbrukeren. Dette er til stor hjelp for virkelig asynkron og frakoblet kommunikasjon.
Når du bruker RabbitMQ, viser diagrammet over en veldig enkel, men typisk struktur. En produsent sender en melding til bryteren. Ifølge rutingslogikken legger svitsjen meldingen inn i køen som er bundet til svitsjen. Mer spesifikt, hvis det er en broadcast-type switch, vil kopien av denne meldingen bli sendt til hver kø gjentatte ganger. En forbruker kan da motta og behandle meldingen.
En viktig forutsetning for at strukturen ovenfor skal fungere vellykket for produsenter og forbrukere, er at alle RabbitMQ-komponenter (dvs. køer, brytere og bindinger) må opprettes på forhånd. En forbruker kan ikke sende en melding til en svitsj Hvis svitsjen ikke eksisterer, kan en forbruker ikke behandle meldinger fra en kø som ikke eksisterer.
Derfor er det ikke vanskelig å forstå at før produsent/forbruker sender/mottar meldingen, la en produsent/forbruker-verdi opprette et kø-, bytte- og bindingsforhold. La oss se på fordeler og ulemper ved hver metode.
1. Skille ansvarsområder
Bildeoversettelse (1. Produsenten lager en bryter 2. Forbrukeren lager en kø og binder køen til bryteren)
For at produsenter og forbrukere skal kunne skille seg helt, vet produsentene ideelt sett bare informasjon om svitsjen (ikke køen), og forbrukerne kjenner kun til køen (ikke svitsjen). Bindingsforholdet indikerer forholdet mellom bryteren og køen
En mulig måte er at produsenten håndterer opprettelsen av bryteren, og forbrukeren oppretter køen og binder køen til bryteren. Fordelen med denne frakoblingsmetoden er at hvis forbrukeren trenger en kø, er det bare nødvendig å opprette en kø og binde dem etter etterspørsel, og produsenten trenger ikke å vite noe om køen. Men dette er ikke en tilstrekkelig avkobling: fordi forbrukeren må kjenne bryteren for å binde den.
2. Produsenter skaper alt
Når produsenten kjører, kan den konfigureres til å lage alle nødvendige komponenter (brytere, køer og bindings). Fordelen med denne tilnærmingen er at ingen meldinger går tapt (fordi køen allerede er opprettet og bundet til switchen, og ingen forbruker trenger å starte den først).
Dette betyr imidlertid at produsenten må kjenne til alle køene som må knyttes til bryteren. Dette er en svært sammenkoblet måte. Årsaken er at hver gang en ny kø må legges til, må produsenten rekonfigurere og distribuere for å opprette og binde køer
3. Forbrukere skaper alt
Det motsatte er å la forbrukeren lage svitsjene, køene og bindingene den trenger når den kjører. Som i den forrige tilnærmingen gir denne metoden kobling fordi forbrukeren må kjenne informasjonen om svitsjen de er bundet til køen. Eventuelle endringer i svitsjen (som omdøping) betyr at alle brukere må omkonfigureres og distribueres. Når det er store køer og forbrukere, kan denne kompleksiteten bli for uoverkommelig.
4. Ingen av dem skaper noe
En helt annen tilnærming er at verken produsenten eller forbrukeren skal lage nødvendige komponenter. I stedet opprettes det ved å bruke brukergrensesnittet til admin-pluginen eller admin-CLI-en på forhånd. Denne metoden er basert på følgende fordeler:
- Produsenter og forbrukere kan være fullstendig frakoblet. Produsentene kjenner bare utvekslingen, og forbrukerne kjenner bare køen.
- Dette kan enkelt skriptes og automatiseres som en del av distribusjonsprosessen
- Eventuelle endringer, som nye køer, kan legges til uten å berøre eksisterende, utplasserte utgivere og forbrukere
sammendrag
I distribuerte systemer er asynkrone meldinger en nyttig måte å koble fra hverandre på, men for å holde dem frakoblet er det nødvendig å opprettholde en effektiv strategi for å opprettholde den underliggende meldingsstrukturen (i RabbitMQ er dette køer, brytere og bindings).
Selv om utgiver- og forbrukertjenester kan være ansvarlige for å lage det de trenger selv, kan de være kostbare når det gjelder innledende meldingstap, kobling og operasjonell vedlikehold (når det gjelder konfigurasjon og distribusjon).
Sannsynligvis den beste måten å håndtere meldingssystemkonfigurasjon der den hører hjemme på: skriv skript utenfor applikasjonen. Dette sikrer at tjenestene forblir frakoblet og at køsystemet kan endres dynamisk etter behov uten å påvirke et stort antall eksisterende tjenester.
Original:Innloggingen med hyperkoblingen er synlig.
Original engelsk:Innloggingen med hyperkoblingen er synlig.
|
Publisert på 03.05.2023 22:31:59
|
|
|
|
