Traducere
Mesageria este o parte fundamentală a oricărui sistem distribuit. Permite unui producător să transmită un mesaj oricărui număr de consumatori și nu este necesar să cunoască informații despre consumator. Acest lucru este de mare ajutor pentru comunicarea cu adevărat asincronă și de decuplare.
Când folosești RabbitMQ, diagrama de mai sus arată o structură foarte de bază, dar tipică. Un producător trimite un mesaj către comutator. Conform logicii de rutare, comutatorul plasează mesajul în coada legată de comutator. Mai exact, dacă este un comutator de tip broadcast, copia acestui mesaj va fi trimisă fiecărei cozi în mod repetat. Un consumator poate apoi să primească și să proceseze mesajul.
O presupunere importantă pentru ca structura de mai sus să funcționeze cu succes pentru producători și consumatori este că toate componentele RabbitMQ (adică cozi, switch-uri și binding-uri) trebuie create dinainte. Un consumator nu poate trimite un mesaj către un comutator Dacă comutatorul nu există, un consumator nu poate procesa mesaje dintr-o coadă care nu există.
Prin urmare, nu este greu de înțeles că, înainte ca producătorul/consumatorul să trimită/primească mesajul, să lase o valoare producător/consumator să creeze o coadă, o relație de comutare și legare. Să aruncăm o privire asupra avantajelor și dezavantajelor fiecărei metode.
1. Distinge responsabilitățile
Traducerea imaginii (1. Producătorul creează un switch 2. Consumatorul creează o coadă și leagă coada de switch)
Pentru ca producătorii și consumatorii să se decupleze complet, ideal ar fi ca producătorii să cunoască doar informații despre coadă (nu și despre coadă), iar consumatorii să știe doar despre coadă (nu și despre coadă). Relația de legare indică relația dintre comutator și coadă
O modalitate posibilă este ca producătorul să se ocupe de crearea switch-ului, iar consumatorul să creeze coada și să lege coada de switch. Avantajul acestei metode de decuplare este că, dacă consumatorul are nevoie de o coadă, este pur și simplu necesar să creeze o coadă și să le lege conform cererii, iar producătorul nu trebuie să știe nicio informație despre coadă. Dar aceasta nu este o decuplare suficientă: pentru că consumatorul trebuie să cunoască comutatorul pentru a-l putea lega.
2. Producătorii creează totul
Când producătorul rulează, poate fi configurat să creeze toate componentele necesare (switch-uri, cozi și binding-uri). Avantajul acestei abordări este că nu se pierd niciun mesaj (deoarece coada este deja creată și legată de switch, iar niciun consumator nu trebuie să o pornească primul).
Totuși, asta înseamnă că producătorul trebuie să cunoască toate cozile care trebuie legate de switch. Aceasta este o metodă foarte cuplată. Motivul este că de fiecare dată când trebuie adăugată o coadă nouă, producătorul trebuie să reconfigureze și să implementeze pentru a crea și lega cozi
3. Consumatorii creează totul
Opusul este să lași consumatorul să creeze switch-urile, cozile și binding-urile de care are nevoie atunci când rulează. Ca și în abordarea anterioară, această metodă produce cuplare deoarece consumatorul trebuie să cunoască informațiile despre comutatorul la care este legat de coadă. Orice modificare a switch-ului (cum ar fi redenumirea) înseamnă că toți consumatorii trebuie reconfigurați și implementați. Când există cozi mari și consumatori, această complexitate poate fi prohibitivă.
4. Niciunul nu creează nimic
O abordare complet diferită este ca nici producătorul, nici consumatorul să nu creeze componentele necesare. În schimb, este creat folosind interfața de utilizator a pluginului de administrare sau CLI de administrare în prealabil. Această metodă se bazează pe următoarele avantaje:
- Producătorii și consumatorii pot fi complet decuplati. Producătorii cunosc doar schimbul, iar consumatorii cunosc doar coada.
- Acest lucru poate fi ușor scriptat și automatizat ca parte a pipeline-ului de implementare
- Orice modificări, cum ar fi cozi noi, pot fi adăugate fără a afecta niciun editor sau consumator existent și implementat
rezumat
În sistemele distribuite, mesajele asincrone sunt o modalitate utilă de decuplare, dar pentru a le menține decuplate este necesar să se mențină o strategie eficientă pentru menținerea structurii de mesagerie de bază (în RabbitMQ, acestea sunt cozi, switch-uri și binding-uri).
Deși serviciile pentru publisheri și consumatori pot fi responsabile pentru crearea propriilor nevoi, acestea pot fi costisitoare în ceea ce privește pierderea inițială a mesajului, cuplarea și mentenanța operațională (din punct de vedere al configurării și implementării).
Probabil cea mai bună metodă de a gestiona configurarea sistemului de mesagerie acolo unde îi este locul: scrie scripturi în afara aplicației. Acest lucru asigură că serviciile rămân decuplate și că sistemul de cozi se poate schimba dinamic după necesitate, fără a afecta un număr mare de servicii existente.
Original:Autentificarea cu hyperlink este vizibilă.
Engleză originală:Autentificarea cu hyperlink este vizibilă.
|
Postat pe 03.05.2023 22:31:59
|
|
|
|
