Käännös
Viestintä on olennainen osa mitä tahansa hajautettua järjestelmää. Sen avulla tuottaja voi lähettää viestin monelle määrälle kuluttajia, eikä kuluttajasta tarvitse tietää mitään tietoa. Tämä on erinomainen apu aidosti asynkroniseen ja irtautuvaan viestintään.
Kun käytät RabbitMQ:ta, yllä oleva kaavio näyttää hyvin yksinkertaisen mutta tyypillisen rakenteen. Tuottaja lähettää viestin kytkimelle. Reitityslogiikan mukaan kytkin sijoittaa viestin kytkimeen sidottu jonoon. Tarkemmin sanottuna, jos kyseessä on lähetystyyppinen kytkin, tämän viestin kopio lähetetään jokaiselle jonolle toistuvasti. Kuluttaja voi sitten vastaanottaa ja käsitellä viestin.
Tärkeä oletus yllä olevan rakenteen toimivuudelle tuottajille ja kuluttajille on, että kaikki RabbitMQ-komponentit (eli jonot, kytkimet ja sidonnat) on luotava etukäteen. Kuluttaja ei voi lähettää viestiä kytkimelle. Jos kytkintä ei ole olemassa, kuluttaja ei voi käsitellä viestejä jonosta, jota ei ole olemassa.
Siksi ei ole vaikea ymmärtää, että ennen kuin tuottaja/kuluttaja lähettää/vastaanottaa viestin, annetaan tuottaja/kuluttaja-arvon luoda jono-, kytkin- ja sitomissuhde. Katsotaanpa kummankin tavan etuja ja haittoja.
1. Erottele vastuut
Kuvan kääntäminen (1. Tuottaja luo kytkimen 2. Kuluttaja luo jonon ja sitoo jonon kytkimeen)
Jotta tuottajat ja kuluttajat voisivat irrottautua toisistaan, ihanteellisesti tuottajat tietäisivät vain tiedot kytkimestä (eivät jonosta), ja kuluttajat tietävät vain jonosta (eivät kytkimestä). Sitomissuhde ilmaisee kytkimen ja jonon välisen suhteen
Yksi mahdollinen tapa on, että tuottaja hoitaa kytkimen luomisen, ja kuluttaja luo jonon ja sitoo jonon kytkimeen. Tämän irrotusmenetelmän etuna on, että jos kuluttaja tarvitsee jonon, on yksinkertaisesti tarpeen luoda jono ja sitoa hänet kysynnän mukaan, eikä tuottajan tarvitse tietää jonosta mitään tietoa. Mutta tämä ei ole riittävä irrotus: koska kuluttajan täytyy tuntea kytkin voidakseen sitoa sen.
2. Tuottajat luovat kaiken
Kun tuottaja on käynnissä, se voidaan konfiguroida luomaan kaikki tarvittavat komponentit (kytkimet, jonot ja sidonnat). Tämän lähestymistavan etuna on, ettei viestejä katoa (koska jono on jo luotu ja sidottu kytkimeen, eikä kuluttajan tarvitse aloittaa sitä).
Tämä tarkoittaa kuitenkin, että tuottajan täytyy tietää kaikki jonot, jotka täytyy kytkeä kytkimeen. Tämä on vahvasti yhdistetty tapa. Syynä on se, että aina kun uusi jono täytyy lisätä, tuottajan täytyy konfiguroida ja ottaa käyttöön jonojen luominen ja sitominen
3. Kuluttajat luovat kaiken
Päinvastoin antaa kuluttajan luoda kytkimet, jonot ja sidokset, joita se tarvitsee käynnissä ollessaan. Kuten aiemmassa lähestymistavassa, tämä menetelmä tuottaa kytkennän, koska kuluttajan on tiedettävä tiedot kytkimestä, johon hän on sidottu jonoon. Kaikki muutokset kytkimeen (kuten uudelleennimeäminen) tarkoittavat, että kaikki kuluttajat on konfiguroitava uudelleen ja otettava käyttöön. Kun jonot ja kuluttajat ovat suuria, tämä monimutkaisuus voi olla liikaa.
4. Kumpikaan ei luo mitään
Täysin erilainen lähestymistapa on, ettei valmistaja eikä kuluttaja luo tarvittavia komponentteja. Sen sijaan se luodaan ensin admin-lisäosan käyttöliittymän tai admin CLI:n kautta. Tämä menetelmä perustuu seuraaviin etuihin:
- Tuottajat ja kuluttajat voidaan täysin erottaa toisistaan. Tuottajat tuntevat vain vaihdon, ja kuluttajat tuntevat vain jonon.
- Tämä voidaan helposti skriptata ja automatisoida osana käyttöönottoputkea
- Kaikki muutokset, kuten uudet jonot, voidaan lisätä koskettamatta olemassa olevia julkaisijoita ja kuluttajia
yhteenveto
Hajautetuissa järjestelmissä asynkroniset viestit ovat hyödyllinen tapa irrottautua, mutta niiden pitämiseksi erillisinä on tarpeen ylläpitää tehokasta strategiaa viestirakenteen ylläpitämiseksi (RabbitMQ:ssa nämä ovat jonot, kytkimet ja sidonnat).
Vaikka julkaisija- ja kuluttajapalvelut voivat itse olla vastuussa tarpeidensa luomisesta, ne voivat olla kalliita alkuperäisen viestin häviämisen, kytkennän ja operatiivisen ylläpidon (konfiguroinnin ja käyttöönoton osalta) osalta.
Todennäköisesti paras tapa hoitaa viestijärjestelmän konfigurointi siellä, mihin se kuuluu: kirjoittaa skriptejä sovelluksen ulkopuolelta. Tämä varmistaa, että palvelut pysyvät erillään ja että jonotusjärjestelmä voi muuttua dynaamisesti tarpeen mukaan vaikuttamatta suureen määrään olemassa olevia palveluita.
Alkuperäinen:Hyperlinkin kirjautuminen on näkyvissä.
Alkuperäinen englanti:Hyperlinkin kirjautuminen on näkyvissä.
|
Julkaistu 3.5.2023 22.31.59
|
|
|
|
