Превод
Съобщенията са основна част от всяка разпределена система. Тя позволява на производителя да изпрати съобщение до произволен брой потребители и не е необходимо да знае никаква информация за потребителя. Това е голяма помощ за наистина асинхронна и разкъсваща комуникация.
Когато използвате RabbitMQ, диаграмата по-горе показва много базова, но типична структура. Продуцентът изпраща съобщение към суича. Според логиката на маршрутизацията, комутаторът поставя съобщението в опашката, свързана с суича. По-конкретно, ако е превключвател от тип broadcast, копието на това съобщение ще се изпраща на всяка опашка многократно. Потребителят може да получи и обработи съобщението.
Важно предположение, за да работи горната структура успешно за производителите и потребителите, е, че всички компоненти на RabbitMQ (т.е. опашки, превключватели и връзки) трябва да бъдат създадени предварително. Потребителят не може да изпрати съобщение към суич. Ако суичът не съществува, потребителят не може да обработва съобщения от опашка, която не съществува.
Затова не е трудно да се разбере, че преди производителят/потребителят да изпрати/получи съобщението, нека стойност производител/потребител създаде връзка между опашка, превключвател и свързване. Нека разгледаме предимствата и недостатъците на всеки от тези варианти.
1. Разграничете отговорностите
Превод на изображения (1. Producer създава превключвател 2. Потребителят създава опашка и свързва опашката към суича)
За да могат производителите и потребителите да се разделят напълно, идеално би било производителите да знаят само информация за превключвателя (не за опашката), а потребителите само за опашката (не за самата превключвателка). Връзката на свързване показва връзката между превключвателя и опашката
Един възможен начин е производителят да управлява създаването на суича, а потребителят да създава опашката и да я свързва с суича. Предимството на този метод на разкъсване е, че ако потребителят има нужда от опашка, просто е необходимо да създаде опашка и да я обвърже според търсенето, а производителят не трябва да знае никаква информация за опашката. Но това не е достатъчно разкъсване: защото потребителят трябва да познава превключвателя, за да го свърже.
2. Продуцентите създават всичко
Когато производителят работи, той може да бъде конфигуриран да създава всички необходими компоненти (превключватели, опашки и връзки). Предимството на този подход е, че не се губят съобщения (защото опашката вече е създадена и свързана със суича и никой потребител не трябва да я стартира първи).
Въпреки това, това означава, че производителят трябва да знае всички опашки, които трябва да бъдат свързани с превключвателя. Това е силно свързан начин. Причината е, че всеки път, когато трябва да се добави нова опашка, производителят трябва да преконфигурира и разположи, за да създава и свързва опашки
3. Потребителите създават всичко
Обратното е да се позволи на потребителя да създава необходимите превключватели, опашки и връзки, докато работи. Както при предишния подход, този метод създава свързване, защото потребителят трябва да знае информацията за суича, с който е свързан с опашката. Всяка промяна в комутатора (като преименуване) означава, че всички потребители трябва да бъдат преконфигурирани и внедрени. Когато има големи опашки и потребители, тази сложност може да бъде непосилна.
4. Нито един от тях не създава нищо
Съвсем различен подход е нито производителят, нито потребителят да създават необходимите компоненти. Вместо това се създава чрез потребителския интерфейс на администраторския плъгин или администраторския CLI предварително. Този метод се основава на следните предимства:
- Производителите и потребителите могат да бъдат напълно отделени. Производителите знаят само борсата, а потребителите само опашката.
- Това може лесно да бъде скриптирано и автоматизирано като част от процеса на внедряване
- Всякакви промени, като нови опашки, могат да бъдат добавени без да се засягат съществуващите, внедрени издатели и потребители
резюме
В разпределените системи асинхронните съобщения са полезен начин за разкъсване, но за да се поддържат разделени, е необходимо да се поддържа ефективна стратегия за поддържане на основната структура на съобщенията (в RabbitMQ това са опашки, превключватели и връзки).
Въпреки че издателите и потребителските услуги могат сами да са отговорни за създаването на необходимото, те могат да бъдат скъпи по отношение на първоначалната загуба на съобщения, свързване и оперативна поддръжка (по отношение на конфигурация и внедряване).
Вероятно най-добрият начин да се управлява конфигурацията на системата за съобщения там, където ѝ е мястото: да пишеш скриптове извън приложението. Това гарантира, че услугите остават разделени и че системата от опашки може да се променя динамично при нужда, без да влияе на голям брой съществуващи услуги.
Оригинален:Входът към хиперлинк е видим.
Оригинален английски:Входът към хиперлинк е видим.
|
Публикувано в 3.05.2023 г. 22:31:59 ч.
|
|
|
|
