Переклад
Обмін повідомленнями є фундаментальною частиною будь-якої розподіленої системи. Він дозволяє виробнику надіслати повідомлення будь-якій кількості споживачів, і не потрібно знати жодної інформації про споживача. Це чудова допомога для справді асинхронної та роз'єднуючої комунікації.
Коли ви використовуєте RabbitMQ, діаграма вище показує дуже базову, але типову структуру. Продюсер надсилає повідомлення комутатору. Згідно з логікою маршрутизації, комутатор поміщає повідомлення в чергу, прив'язану до комутатора. Більш конкретно, якщо це комутатор широкомовного типу, копія цього повідомлення надсилатиметься кожній черзі неодноразово. Потім споживач може отримати та опрацювати повідомлення.
Важливим припущенням для успішної роботи вищезазначеної структури для виробників і споживачів є те, що всі компоненти RabbitMQ (тобто черги, комутатори та зв'язки) мають бути створені заздалегідь. Споживач не може надіслати повідомлення комутатору. Якщо комутатор не існує, споживач не може обробляти повідомлення з черги, якої не існує.
Тому неважко зрозуміти, що перед тим, як виробник/споживач надсилає/отримує повідомлення, нехай цінність виробник/споживач створить зв'язок між чергою, перемикачем і зв'язуванням. Давайте розглянемо переваги та недоліки кожного способу.
1. Розмежуйте обов'язки
Переклад зображень (1. Виробник створює комутатор; 2. Споживач створює чергу і прив'язує чергу до комутатора)
Щоб виробники та споживачі повністю відокремилися, ідеально було б, щоб виробники знали лише інформацію про комутатор (не про чергу), а споживачі — лише про чергу (не про перемикач). Зв'язування вказує на зв'язок між комутатором і чергою
Один із можливих способів — щоб виробник займався створенням комутатора, а споживач створив чергу і прив'язав її до комутатора. Перевага цього методу розділення полягає в тому, що якщо споживачеві потрібна черга, достатньо створити чергу і зв'язати її відповідно до попиту, і виробнику не потрібно знати жодної інформації про чергу. Але цього не є достатнім роз'єднанням: адже споживач повинен знати перемикач, щоб його прив'язати.
2. Продюсери створюють усе
Під час роботи виробника його можна налаштувати на створення всіх необхідних компонентів (перемикачі, черги та зв'язки). Перевага цього підходу в тому, що жоден повідомлення не втрачається (оскільки черга вже створена і прив'язана до комутатора, і жоден споживач не повинен запускати її першим).
Однак це означає, що виробник повинен знати всі черги, які потрібно прив'язати до комутатора. Це дуже пов'язаний спосіб. Причина в тому, що кожного разу, коли потрібно додати нову чергу, виробник повинен переналаштовувати та розгортати черги для створення та зв'язку черг
3. Споживачі створюють усе
Навпаки — дозволити споживачу створювати необхідні комутатори, черги та зв'язки під час роботи. Як і в попередньому підході, цей метод створює зв'язування, оскільки споживач повинен знати інформацію про комутатор, до якого він прив'язаний до черги. Будь-які зміни комутатора (наприклад, перейменування) означають, що всіх споживачів потрібно переналаштовувати та розгортати. Коли є великі черги та споживачі, ця складність може бути надмірною.
4. Жоден з них нічого не створює
Зовсім інший підхід — ні виробник, ні споживач не створюють потрібні компоненти. Натомість він створюється за допомогою інтерфейсу користувача плагіна адміністратора або адміністративного CLI заздалегідь. Цей метод базується на таких перевагах:
- Виробники та споживачі можуть бути повністю відокремлені. Виробники знають лише біржу, а споживачі — лише чергу.
- Це легко скриптувати та автоматизувати в рамках конвеєра розгортання
- Будь-які зміни, такі як нові черги, можна додати без контакту з існуючими видавцями та споживачами
зведення
У розподілених системах асинхронні повідомлення є корисним способом роз'єднання, але для їх роз'єднання необхідно підтримувати ефективну стратегію підтримки базової структури повідомлень (у RabbitMQ це черги, комутатори та зв'язки).
Хоча видавці та споживчі сервіси можуть самостійно створювати необхідне, вони можуть бути дорогими через початкову втрату повідомлень, з'єднання та операційне обслуговування (у плані конфігурації та розгортання).
Ймовірно, найкращий спосіб налаштувати систему обміну повідомленнями там, де їй і місце: писати скрипти поза межами додатку. Це гарантує, що сервіси залишаються роз'єднаними, а система черги може динамічно змінюватися за потреби без впливу великої кількості існуючих сервісів.
Оригінальний:Вхід за гіперпосиланням видно.
Оригінальна англійська:Вхід за гіперпосиланням видно.
|
Опубліковано 03.05.2023 22:31:59
|
|
|
|
