Разработка требований к Rabbit MQ · Зоя Степчева

В этой главе мы обсудим требования, обычно включаемые в тему crabbit IQ. Эта тема приобрела популярность среди системных аналитиков, которые занимаются проектированием различных артефактов, включая требования.

Опыт преподавания и работы в других местах У меня большой опыт преподавания, в том числе в настоящее время я преподаю в Школе системного анализа. Я преподаю в Политехническом университете в Санкт-Петербурге, а иногда и в Московском политехе.

Текущая должность архитектора решений В настоящее время я работаю архитектором решений в нефтегазовой компании. У меня есть определенный опыт в этой области, поэтому не стесняйтесь задавать мне любые вопросы, которые могут оказаться полезными.

Цель вебинаров Цель сегодняшнего вебинара - предоставить разработчикам всесторонний практический опыт в отношении того, что важно учитывать в требованиях к брокерам обмена сообщениями. Мы обсудим, как сформулировать этот важный артефакт и его соответствие требованиям message broker.

Структура "Rebit": обмены, очереди и маршрутизация "Повторный обмен" состоит из обменов, очередей и маршрутизации. В этой главе мы сосредоточимся на этих ключевых компонентах, которые часто используются в примерах, связанных с обменом информацией.

Технические требования к "Крейбиту" Далее будут рассмотрены технические требования к "Крейбиту". В этом разделе освещается интересное объявление о мероприятиях, связанных с системным анализом в школе, а также некоторые конкретные подробности о "Собачке".

Заключительные замечания В заключительной главе мы рассмотрим все оставшиеся вопросы и постараемся внести дополнительную ясность в отношении нюансов, затронутых в презентации вебинара.

Введение в RabbitMQ RabbitMQ - это посредник сообщений, используемый в современных информационных системах. Это позволяет осуществлять асинхронный обмен сообщениями между службами, обеспечивая высокую производительность и доступность. Посредник сообщений действует как программное обеспечение, облегчающее обмен сообщениями между различными службами.

Компоненты RabbitMQ "Обмен", "Очередь" и "Сообщение" - это три основных компонента RabbitMQ. Приложение, действующее в качестве производителя, публикует сообщения брокеру, в то время как потребители получают и потребляют эти сообщения от брокера. Внутри брокера есть обмены для маршрутизации, очереди для хранения сообщений и фактические сообщения, которыми обмениваются.

Топология состоит из трех компонентов: точки обмена, очереди и сообщений. В этой топологии объекты могут быть соединены несколько раз. Входящие сообщения направляются брокером в различные очереди или пункты обмена для дальнейшей обработки. Потребители читают и обрабатывают эти сообщения из своих соответствующих очередей.

Очереди в RabbitMQ работают по принципу FIFO (первый ввод - первый выход). Каждая очередь имеет уникальное имя и может быть настроена с помощью необязательных параметров. Имена очередей должны быть уникальными и иметь ограничение по максимальной длине. Очереди не могут начинаться с зарезервированных слов.

"Точка обмена" - это термин, используемый для описания места обмена сообщениями в посреднике сообщений. Сообщения публикуются в точке обмена перед помещением в очередь. Затем брокер маршрутизирует сообщения на основе установленных соединений между ним и очередями, используя спецификацию протокола AMQP, с которой работает RabbitMQ. Существуют различные типы обменных пунктов, каждый со своей собственной семантикой маршрутизации и атрибутами.

Сообщение в брокере состоит из трех основных частей: блока заголовка, блока полезной нагрузки и блока дополнительных атрибутов. Ключевым атрибутом для маршрутизации является атрибут 'routing', который позволяет нам направлять сообщение внутри брокера. Блок заголовка содержит дополнительную информацию, которая может быть использована для более сложной маршрутизации на основе определенных условий.

Маршрутизация сообщений является важным аспектом коммуникации. Это включает в себя настройку соединений между очередями и соответствующих привязок в интерфейсе менеджера. Привязки обеспечивают взаимодействие или корреляцию между очередями и точками обмена. Каждая точка обмена не обязательно должна быть подключена только к одной очереди; она также может объединять несколько точек обмена между собой. Структура сообщения для последующей маршрутизации включает в себя специальное поле под названием "ключ маршрутизации", которое должно соответствовать ключу маршрутизации, указанному в настройках взаимодействий, привязок и очереди.

Прямой обмен сообщениями При прямом обмене сообщениями сообщения доставляются в определенную очередь на основе ключа маршрутизации. Этот тип обмена полезен для целевой маршрутизации сообщений, например, для распределения задач между несколькими рабочими узлами.

Обмен "темами" "Тематические" обмены анализируют сообщения на основе ключа маршрутизации и выполняют выборочную маршрутизацию с использованием сопоставления с образцом. Символ "*" представляет собой замену одного слова, в то время как символ "#" может быть заменен нулем или более словами. Это обеспечивает гибкую и точную фильтрацию сообщений.

- Изучение использования обменных пунктов в очередях и обмене сообщениями. - Примеры того, как rabbiting используется в реальных сценариях.

Существует два типа маршрутизации на основе сообщений: на основе заголовков и на основе полезной нагрузки. Маршрутизация на основе заголовков использует заголовки сообщения для определения маршрута, в то время как маршрутизация на основе полезной нагрузки использует содержимое сообщения. В сценарии, когда несколько служб публикуют свои сообщения в одной точке обмена, все сообщения попадают в общую очередь для обработки. Работник получает эти сообщения, обрабатывает их, генерирует ключ для дальнейшей маршрутизации и отправляет их обратно либо в другую точку обмена, либо в очереди процесса доставки на основе этого ключа.

Порядок следования сообщений Чтобы решить проблему порядка сообщений в брокере, мы можем добавить рабочие реплики для обработки сообщений из очереди. Однако это приводит к дублированию обработки и может привести к тому, что сообщения будут считываться не по порядку при горизонтальном масштабировании. Чтобы гарантировать доставку сообщений, RabbitMQ гарантирует, что опубликованные сообщения проходят через одну точку обмена и одну очередь, прежде чем попасть в исходящий канал.

Обеспечение строгого порядка сообщений "Согласованное хэширование" - это механизм, используемый для поддержания строгого порядка сообщений в информационных системах, основанных на управляемой событиями архитектуре. Это включает в себя генерацию событий для объектов, где важна последовательность событий (например, создание заказа). Затем эти события маршрутизируются с использованием согласованной маршрутизации хэширования на основе их хэш-значений. Гарантируя, что хэш-значение каждого объекта остается постоянным на протяжении всего его жизненного цикла, мы можем гарантировать, что связанные события будут обрабатываться последовательно и сохранят свой первоначальный порядок.

Если сообщение отклоняется, это может быть вызвано различными причинами. При использовании Rabbit IQ для общения и использовании различных библиотек важно проверить настройки этих библиотек по умолчанию. По умолчанию, если сообщение из головы очереди используется потребителями без какой-либо промежуточной обработки, обратно в очередь будет отправлено отрицательное подтверждение (negative ack), указывающее на то, что сообщение было отклонено. Затем отклоненное сообщение будет помещено обратно в ту же очередь, но в исходное положение.

В этой главе мы обсудим спецификацию требований к брокерам. Спецификация основана на объектах, составляющих посредник сообщений, и их подключениях к точкам обмена. Мы можем указать требования, перечислив все используемые точки обмена, включая их тип и название, а также связанный с ними объект, такой как "Обмен" или прямая очередь сообщений. Если используются ключи или соответствующие маски ключей, они должны быть указаны в отдельной колонке. Кроме того, вместо использования таблицы с конфигурацией топологии изображений для настройки вашего брокера вы можете предоставить основную информацию о названии каждой точки обмена, типе имеющегося у нее соединения и ключе маршрутизации.

Очередь должна иметь имя и конфигурационный ключ или код. Параметры конфигурации, которые должны быть включены, - это стабильность, срок действия сообщения, повторная публикация сообщения и ключ маршрутизации. Два параметра характеризуют время жизни сообщения в очереди: время ожидания сообщений и время ожидания самой очереди. Когда сообщение заполняет всю очередь, возможны три действия: удалить самые старые сообщения из заголовка (по умолчанию), отклонить опубликованные сообщения по достижении максимальной длины при включенной повторной доставке или удалить ближе к истечению срока действия.

Важен объем информации в байтах для каждого сообщения. Нам нужно указать кодировку сообщений, будь то обычный текст или другой формат. Для обычного текста мы должны использовать строку, а для сжатых сообщений мы должны указывать кодировку Base64. Другим важным параметром является режим доставки, который обеспечивает гарантированную доставку сообщений даже в случае сбоев брокера.

Роли приложений Приложения могут выступать либо в качестве издателей, либо в качестве потребителей. Иногда приложение может играть обе роли одновременно. Нам нужно определить общие свойства для приложения, такие как ограничение действий в зависимости от его роли (например, только для чтения, если это потребитель, и только для чтения-записи, если это издатель). Кроме того, нам требуется базовая авторизация с использованием имени пользователя и пароля.

Сведения о подключении - Приложения подключаются либо к очереди, либо к обмену данными. - Должно быть указано количество попыток, предпринятых пользователем для получения сообщений. - Подтверждение получения сообщения может быть автоматическим или ручным в зависимости от того, выступает ли клиент также в качестве издателя. - Укажите, где будет опубликовано сообщение в случае, если вы являетесь клиентом публикации (обычно именуемым "exchange"). - Рекомендуется устанавливать время ожидания (TTL) для каждого сообщения.

Объявлено о проведении нового семинара по Kafka и работе с посредниками сообщений. Он фокусируется на построении сложных топологий, в которых могут участвовать не только производители, но и посредники сообщений Kafka. На семинаре будут рассмотрены различия между этими двумя типами брокеров, а также требования к построению топологии. Участники узнают, как производители и потребители взаимодействуют с различными компонентами топологии, такими как очереди и обмены.

В некоторых случаях нам может понадобиться временный обменник и очередь. Я не сталкивался с таким типом обмена в своей работе, потому что в первую очередь было важно обеспечить надежность посредников сообщений. Настройка брокера также имеет решающее значение для стабильной связи.

Для обеспечения долговечности необходимы дополнительные ресурсы для хранения сообщений во время перезагрузки или сбоя. Это достигается путем сохранения сообщений на диске. Чем больше у нас сообщений и очередей, тем более устойчивой должна быть наша система, что требует выделения большего объема ресурсов. К сожалению, это приводит к снижению производительности. Чтобы оптимизировать этот баланс между скоростью и устойчивостью, мы можем рассмотреть различные топологии и сжать изображения сообщений.

- Возможно ли использовать два типа бирж одновременно? - Да, нет никаких ограничений на использование нескольких типов бирж одновременно.

Существуют различные типы обменов данными и топологии соединений. При отправке сообщения мы можем либо отправить его как base64, либо предоставить ссылку на ресурс. В случаях, когда нам нужно отправлять большие сообщения и скорость доставки не критична, мы можем вместо этого предоставить ссылку на ресурс. Таким образом, отправитель экономит время на передаче больших файлов, потребляя при этом ресурсы для их хранения.

RabbitMQ можно использовать для взаимодействия между интерфейсным и серверным уровнями. Он также обычно используется для обмена данными между службами на уровне серверной части. RabbitMQ имеет свою собственную топологию с обменами, позволяющую как интерфейсным, так и серверным приложениям подключаться в качестве потребителей.

Пропускная способность канала относится к максимальному количеству сообщений, которые могут быть переданы по каналу. Если пропускная способность канала меньше десятков тысяч, не рекомендуется использовать rabbits для передачи сообщений. Передача сообщений зависит от наших ресурсов и возможностей. Для больших сообщений, таких как 30 гигабайт, следует использовать альтернативные механизмы.

Терминология, используемая в задачах разработки, может существенно варьироваться в зависимости от брокера и его поставщика. Например, у таких брокеров, как Rabbit или Nakavka, могут быть разные подходы и формулировки требований к задачам. Каждый поставщик использует различные средства для обеспечения отказоустойчивости и высокой производительности, которые регулируются различными параметрами. Например, Kafka использует постоянное хранилище, подключенное к дисковому пространству, где сообщения не исчезают, если не настроена определенная политика удаления.

Компании выбирают Kafka, а не RabbitMQ, потому что они могут использовать обе системы обмена сообщениями для отправки сообщений. Однако сейчас наблюдается тенденция выбирать Kafka, поскольку компании пытаются отойти от RabbitMQ. Обычно системные аналитики получают готовые решения от архитекторов в пользу того или иного брокера.

Когда дело доходит до использования протоколов обмена сообщениями, таких как RabbitMQ и MQTT для встроенных устройств, какой из них больше подходит? Если первоначальное взаимодействие было реализовано с использованием протокола AMQP в версии 3.8 RabbitMQ, то была добавлена поддержка специального плагина, который включает протокол MQTT. Это означает, что оба протокола могут эффективно использоваться для связи со встроенными устройствами.

Принципы организации очереди - Принципы организации очередей важны для повышения надежности и производительности. - Для повышения надежности и производительности можно использовать различные архитектурные решения.

Архитектурные шаблоны для обеспечения надежности - Архитектурные решения играют решающую роль в повышении надежности. - Эти шаблоны обеспечивают подходы, которые помогают обеспечить правильное функционирование системы даже в сложных условиях.

Архитектурные шаблоны для повышения производительности - Архитектурные узоры также способствуют повышению производительности. - Следуя этим шаблонам, разработчики могут проектировать системы, которые являются эффективными, масштабируемыми и простыми в обслуживании.

При разработке тестов для служб посредника сообщений важно сосредоточиться на асинхронной интеграции. Это может оказаться непростой задачей, поскольку основная проблема заключается в обеспечении того, чтобы потребители и производители правильно обрабатывали сообщения. Разработка этих тестов требует тщательного рассмотрения того, как обрабатываются и маршрутизируются сообщения.

На этом вебинаре мы обсудим факторы, которые следует учитывать при выборе между RabbitMQ и Kafka. Основное различие заключается в требованиях к разработке для этих двух брокеров. Если у вас есть еще какие-либо вопросы, не стесняйтесь задавать.