Vertimas
Pranešimai yra pagrindinė bet kurios paskirstytos sistemos dalis. Tai leidžia gamintojui siųsti žinutę bet kokiam vartotojų skaičiui ir nebūtina žinoti jokios informacijos apie vartotoją. Tai puiki pagalba tikrai asinchroniniam ir atsiejančiam bendravimui.
Kai naudojate RabbitMQ, aukščiau pateiktoje diagramoje parodyta labai paprasta, bet tipiška struktūra. Prodiuseris siunčia žinutę komutatoriui. Pagal maršruto parinkimo logiką, komutatorius perkelia pranešimą į eilę, susietą su komutatoriumi. Tiksliau, jei tai transliacijos tipo jungiklis, šio pranešimo kopija bus pakartotinai siunčiama į kiekvieną eilę. Tada vartotojas gali gauti ir apdoroti pranešimą.
Svarbi prielaida, kad minėta struktūra sėkmingai veiktų gamintojams ir vartotojams, yra ta, kad visi RabbitMQ komponentai (t. y. eilės, jungikliai ir apkaustai) turi būti sukurti iš anksto. Vartotojas negali siųsti pranešimo komutatoriui Jei komutatoriaus nėra, vartotojas negali apdoroti pranešimų iš neegzistuojančios eilės.
Todėl nesunku suprasti, kad prieš gamintojui/vartotojui siunčiant/gaunant žinutę, tegul gamintojas/vartotojas sukuria eilę, perjungimo ir įpareigojantį santykį. Pažvelkime į kiekvieno būdo privalumus ir trūkumus.
1. Atskirkite atsakomybę
Vaizdo vertimas (1. Gamintojas sukuria jungiklį 2. Vartotojas sukuria eilę ir susieja eilę su komutatoriumi)
Kad gamintojai ir vartotojai galėtų visiškai atsieti, idealiu atveju gamintojai žino tik informaciją apie jungiklį (ne eilę), o vartotojai žino tik apie eilę (ne jungiklį). Susiejimo ryšys nurodo ryšį tarp jungiklio ir eilės
Vienas iš galimų būdų yra tai, kad gamintojas tvarkytų jungiklio sukūrimą, o vartotojas sukuria eilę ir susieja eilę su komutatoriumi. Šio atskyrimo metodo privalumas yra tas, kad jei vartotojui reikia eilės, tiesiog reikia sukurti eilę ir surišti juos pagal paklausą, o gamintojui nereikia žinoti jokios informacijos apie eilę. Tačiau tai nėra pakankamas atsiejimas: nes vartotojas turi žinoti jungiklį, kad jį surištų.
2. Gamintojai sukuria viską
Kai gamintojas veikia, jį galima sukonfigūruoti taip, kad būtų sukurti visi reikalingi komponentai (jungikliai, eilės ir susiejimai). Šio metodo privalumas yra tas, kad jokie pranešimai neprarandami (nes eilė jau sukurta ir susieta su komutatoriumi, ir nė vienam vartotojui nereikia jos paleisti).
Tačiau tai reiškia, kad gamintojas turi žinoti visas eiles, kurias reikia pririšti prie jungiklio. Tai labai susietas būdas. Priežastis ta, kad kiekvieną kartą, kai reikia pridėti naują eilę, gamintojas turi iš naujo sukonfigūruoti ir įdiegti, kad sukurtų ir susietų eiles
3. Vartotojai sukuria viską
Priešingai yra leisti vartotojui sukurti jungiklius, eiles ir apkaustus, kurių jam reikia, kai jis veikia. Kaip ir ankstesniame metode, šis metodas sukuria susiejimą, nes vartotojas turi žinoti informaciją apie jungiklį, kurį jis yra pririštas prie eilės. Bet kokie komutatoriaus pakeitimai (pvz., pervadinimas) reiškia, kad visi vartotojai turi būti iš naujo sukonfigūruoti ir įdiegti. Kai yra didelės eilės ir vartotojai, šis sudėtingumas gali būti pernelyg didelis.
4. Nei vienas, nei kitas nieko nesukuria
Visiškai kitoks požiūris yra nei gamintojui, nei vartotojui sukurti reikiamus komponentus. Vietoj to, jis sukuriamas naudojant administratoriaus papildinio vartotojo sąsają arba administratoriaus CLI iš anksto. Šis metodas pagrįstas šiais privalumais:
- Gamintojai ir vartotojai gali būti visiškai atsieti. Gamintojai žino tik biržą, o vartotojai žino tik eilę.
- Tai gali būti lengvai scenarijus ir automatizuota kaip diegimo srauto dalis
- Bet kokius pakeitimus, pvz., naujas eiles, galima pridėti neliečiant esamų, įdiegtų leidėjų ir vartotojų
suvestinė
Paskirstytose sistemose asinchroniniai pranešimai yra naudingas būdas atsieti, tačiau norint juos atsieti, būtina išlaikyti veiksmingą pagrindinės pranešimų struktūros palaikymo strategiją (RabbitMQ tai yra eilės, jungikliai ir susiejimai).
Nors leidėjų ir vartotojų paslaugos gali būti atsakingos už tai, ko jiems reikia, jos gali brangiai kainuoti pradinio pranešimo praradimo, susiejimo ir veiklos priežiūros (konfigūracijos ir diegimo požiūriu).
Tikriausiai geriausias būdas tvarkyti pranešimų sistemos konfigūraciją ten, kur ji priklauso: rašyti scenarijus už programos ribų. Taip užtikrinama, kad paslaugos išliktų atsietos ir kad eilių sistema galėtų dinamiškai keistis pagal poreikį, nedarant poveikio daugeliui esamų paslaugų.
Originalus:Hipersaito prisijungimas matomas.
Anglų kalbos originalas:Hipersaito prisijungimas matomas.
|
Paskelbta 2023-05-03 22:31:59
|
|
|
|
