Vertaling
Berichten zijn een fundamenteel onderdeel van elk gedistribueerd systeem. Het stelt een producent in staat een boodschap te sturen naar een willekeurig aantal consumenten, en het is niet nodig om informatie over de consument te kennen. Dit is een grote hulp voor echt asynchrone en ontkoppelende communicatie.
Wanneer je RabbitMQ gebruikt, toont het bovenstaande diagram een heel eenvoudige maar typische structuur. Een producer stuurt een bericht naar de switch. Volgens de routinglogica plaatst de switch het bericht in de wachtrij die aan de switch is gekoppeld. Meer specifiek, als het een broadcast-type switch is, wordt de kopie van dit bericht herhaaldelijk naar elke wachtrij gestuurd. Een consument kan vervolgens het bericht ontvangen en verwerken.
Een belangrijke aanname voor het succesvol werken van bovenstaande structuur voor producenten en consumenten is dat alle RabbitMQ-componenten (d.w.z. wachtrijen, switches en bindings) vooraf moeten worden aangemaakt. Een consument kan geen bericht naar een switch sturen Als de switch niet bestaat, kan een consument geen berichten verwerken van een wachtrij die niet bestaat.
Daarom is het niet moeilijk te begrijpen dat voordat producent/consument het bericht verzendt/ontvangt, een producent/consumentwaarde een wachtrij-, switch- en bindingsrelatie kan creëren. Laten we eens kijken naar de voor- en nadelen van elke manier.
1. Onderscheid van verantwoordelijkheden
Beeldvertaling (1. Producent maakt een switch aan 2. Consument maakt een wachtrij aan en bindt deze aan de schakelaar)
Om producenten en consumenten volledig te ontkoppelen, weten producenten idealiter alleen informatie over de switch (niet de queue), en consumenten alleen van de queue (niet de switch). De bindingsrelatie geeft de relatie aan tussen de switch en de wachtrij
Een mogelijke manier is dat de producent de creatie van de switch afhandelt, en de consument de wachtrij aanmaakt en deze aan de schakelaar bindt. Het voordeel van deze ontkoppelingsmethode is dat als de consument een wachtrij nodig heeft, het simpelweg nodig is een wachtrij aan te maken en deze te binden volgens de vraag, en de producent hoeft geen informatie over de wachtrij te weten. Maar dit is geen voldoende ontkoppeling: omdat de consument de schakelaar moet kennen om deze te kunnen binden.
2. Producenten creëren alles
Wanneer de producer draait, kan deze worden geconfigureerd om alle benodigde componenten (switches, wachtrijen en bindings) te maken. Het voordeel van deze aanpak is dat er geen berichten verloren gaan (omdat de wachtrij al is aangemaakt en aan de switch gekoppeld, en geen enkele consument deze eerst hoeft te starten).
Dit betekent echter dat de producent alle wachtrijen moet kennen die aan de switch gekoppeld moeten worden. Dit is een sterk gekoppelde manier. De reden is dat elke keer dat er een nieuwe wachtrij moet worden toegevoegd, de producent moet herconfigureren en uitrollen om wachtrijen aan te maken en te binden
3. Consumenten creëren alles
Het tegenovergestelde is om de consument de switches, wachtrijen en bindings te laten maken die hij nodig heeft tijdens het draaien. Net als bij de vorige aanpak produceert deze methode koppeling omdat de consument de informatie over de schakelaar moet kennen waaraan hij of zij in de wachtrij is gebonden. Elke wijziging aan de switch (zoals een naamswijziging) betekent dat alle gebruikers opnieuw moeten worden geconfigureerd en geïrild. Wanneer er grote wachtrijen en consumenten zijn, kan deze complexiteit onbetaalbaar zijn.
4. Geen van beide creëert iets
Een totaal andere aanpak is dat noch de producent, noch de consument de benodigde componenten maken. In plaats daarvan wordt het aangemaakt via de gebruikersinterface van de admin-plugin of de admin-CLI van tevoren. Deze methode is gebaseerd op de volgende voordelen:
- Producenten en consumenten kunnen volledig losgekoppeld raken. Producenten kennen alleen de uitwisseling, en consumenten kennen alleen de wachtrij.
- Dit kan eenvoudig worden gescript en geautomatiseerd als onderdeel van de deployment-pijplijn
- Wijzigingen zoals nieuwe wachtrijen kunnen worden toegevoegd zonder dat er bestaande, uitgerolde uitgevers en consumenten worden aangeraakt
samenvatting
In gedistribueerde systemen zijn asynchrone berichten een nuttige manier om te ontkoppelen, maar om ze ontkoppeld te houden, is het noodzakelijk een effectieve strategie te onderhouden voor het onderhouden van de onderliggende berichtenstructuur (in RabbitMQ zijn dit wachtrijen, switches en bindings).
Hoewel uitgevers- en consumentendiensten zelf verantwoordelijk kunnen zijn voor het creëren van wat ze nodig hebben, kunnen ze kostbaar zijn qua initiële berichtverlies, koppeling en operationeel onderhoud (qua configuratie en implementatie).
Waarschijnlijk de beste manier om de configuratie van het berichtensysteem te regelen waar het hoort: schrijf scripts buiten de applicatie. Dit zorgt ervoor dat services ontkoppeld blijven en dat het wachtrijsysteem dynamisch kan veranderen wanneer nodig zonder dat een groot aantal bestaande services wordt beïnvloed.
Origineel:De hyperlink-login is zichtbaar.
Origineel Engels:De hyperlink-login is zichtbaar.
|
Geplaatst op 03-05-2023 22:31:59
|
|
|
|
