Перевод
Обмен сообщениями — фундаментальная часть любой распределённой системы. Это позволяет производителю отправить сообщение любому числу потребителей, и не обязательно знать какую-либо информацию о потребителе. Это отличная помощь для по-настоящему асинхронной и разъединяющей коммуникации.
Когда вы используете RabbitMQ, диаграмма выше показывает очень базовую, но типичную структуру. Продюсер отправляет сообщение на коммутатор. Согласно логике маршрутизации, коммутатор помещает сообщение в очередь, привязанную к коммутатору. Более конкретно, если это коммутатор широковещательного типа, копия этого сообщения будет многократно отправляться в каждую очередь. Затем потребитель может получить и обработать сообщение.
Важным предположением для успешной работы этой структуры для производителей и потребителей является то, что все компоненты RabbitMQ (то есть очереди, переключатели и связы) должны быть созданы заранее. Потребитель не может отправить сообщение коммутатору. Если коммутатор не существует, пользователь не может обрабатывать сообщения из очереди, которой не существует.
Поэтому несложно понять, что до того, как производитель/потребитель отправит/получит сообщение, пусть ценность производитель/потребитель создаёт связь очереди, переключателя и связывания. Давайте рассмотрим преимущества и недостатки каждого из этих способов.
1. Различайте обязанности
Перевод изображений (1. Продюсер создаёт коммутатор 2. Потребитель создает очередь и привязывает очередь к коммутатору)
Чтобы производители и потребители могли полностью отделиться, в идеале производители должны знать только информацию о коммутаторе (не о очереди), а потребители — только о очереди (не о коммутаторе). Связывание указывает на связь между коммутатором и очередью
Один из возможных способов — чтобы продюсер занимался созданием коммутатора, а потребитель создаёт очередь и связывает очередь с коммутатором. Преимущество такого метода разрыва в том, что если потребителю нужна очередь, достаточно создать её и привязать её в соответствии с спросом, и производительу не нужно знать никакой информации о очереди. Но этого недостаточно, потому что потребитель должен знать переключатель, чтобы его связать.
2. Продюсеры создают всё
Когда производитель работает, его можно настроить для создания всех необходимых компонентов (переключателей, очередей и связей). Преимущество такого подхода в том, что сообщения не теряются (потому что очередь уже создана и привязана к коммутатору, и ни один пользователь не обязан её запускать первым).
Однако это означает, что производитель должен знать все очереди, которые нужно привязать к коммутатору. Это очень связанный способ. Причина в том, что каждый раз, когда нужно добавить новую очередь, продюсер должен перенастраивать и развёртывать её для создания и привязки очередей
3. Потребители создают всё
Наоборот — позволить потребителю создавать необходимые переключатели, очереди и привязки во время работы. Как и в предыдущем подходе, этот метод создаёт сцепление, потому что потребитель должен знать информацию о коммутаторе, к которому он привязан к очереди. Любые изменения коммутатора (например, переименование) означают, что все потребители должны быть перенастроены и развернуты. Когда очереди и покупатели большие, эта сложность может быть слишком сложной.
4. Ни один из них ничего не создаёт
Совершенно другой подход — ни производитель, ни потребитель не должны создавать необходимые компоненты. Вместо этого он создаётся с использованием пользовательского интерфейса плагина администратора или администраторской команды (admin CLI) заранее. Этот метод основан на следующих преимуществах:
- Производители и потребители могут быть полностью отделены от связи. Производители знают только биржу, а потребители — только очередь.
- Это можно легко скриптировать и автоматизировать в рамках конвейера развертывания
- Любые изменения, такие как новые очереди, могут быть добавлены без контакта с существующими издателями и потребителями
сводка
В распределённых системах асинхронные сообщения являются полезным способом разъединения, но для их разделения необходимо поддерживать эффективную стратегию поддержания базовой структуры сообщений (в RabbitMQ это очереди, коммутаторы и привязки).
Хотя издатели и потребительские службы могут самостоятельно создавать всё необходимое, они могут быть дорогостоящими с точки зрения первоначальной потери сообщений, соединения и операционного обслуживания (с точки зрения конфигурации и развертывания).
Наверное, лучший способ конфигурировать систему сообщений там, где ей место: писать скрипты вне приложения. Это гарантирует, что сервисы остаются разъединёнными, а система очередей может изменяться динамически по мере необходимости, не затрагивая большое количество существующих сервисов.
Исходный текст:Вход по гиперссылке виден.
Оригинальный английский:Вход по гиперссылке виден.
|
Опубликовано 03.05.2023 22:31:59
|
|
|
|
