По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
На самом деле, чего только не происходит в компьютерных сетях. Разобраться сложно, а особенно сложно, когда речь заходит об адресации и приеме/передаче данных. Вопрос усложняется тем, что каждый из адресов функционирует на своем уровне модели OSI (Open Systems Interconnection).
Но, не нужно переживать. В этой статье, мы самым простым, но профессиональным языком объясним, что такое Media Access Control, или как сокращенно его называют MAC - адрес.
Этот тип адреса живет на втором (канальном, или Data Link) уровне модели OSI и является главным адресом на этом уровне.Устраивайтесь поудобнее, наливайте "чайковского" - будем разбираться.
Если вы не слышали про модель OSI ранее, то мы очень рекомендуем прочитать сначала статью про OSI, а потом уже приступать к изучению MAC - адреса.
Media Access Control (MAC) Address - я выбираю тебя!
MAC - адрес представляет собой уникальную комбинацию цифр и букв длиной 48 символов. Фактически, это аппаратный номер оборудования (компьютера, сервера, роутера, порта коммутатора, да чего угодно), который, внимание, присваивается сетевой карте устройства еще на фабрике, то есть в момент производства.
Да - да, MAC - адрес устройства это вам не IP - адрес устройства, который можно легко поменять. Этот адрес вшит аппаратно. Хотя, конечно, надо быть честными - как специалисты из Мытищ в гаражных условиях "перебьют" VIN номер автомобиля, так и MAC - адрес можно "перебить".
MAC - адрес еще называют уникальным физическим адресом устройства, помогающим идентифицировать устройство среди миллионов других устройств. В стандарте IEEE 802, канальный (второй, Data Link) уровень модели OSI разделен на два подуровня:
Logical Link Control (LLC) или подуровень управления логической связью
Media Access Control (MAC) или подуровень управления доступом к среде
И как раз, как можно догадаться, MAC - адрес используется на втором подуровне, Media Access Control, который является частью канального уровня модели OSI. А теперь поговорим про то, как выглядит MAC - адрес из из чего он состоит. Берем лист А4 и маркер - начинаем рисовать.
Форма MAC - адреса
"Я нарисоваль!" Вот картинка. Мы правда старались:
Стандартный MAC выглядит примерно вот так: 00-50-B6-5B-CA-6A.
Смотрите: мак - адрес это 12 - значное шестнадцатеричное число, или 6 - байтовое двоичное число. Чаще всего MAC - адрес представляют именно в шестнадцатеричной системе.
На картинки мы изобразили 6 октетов (неких групп), из которых состоит MAC. Каждый из октетов состоит из 2 знаков, итого получается 12 - значное число. Первые 6 цифр (к примеру 00-50-B6) обозначают производителя сетевой карты. Его также называют OUI (Organizational Unique Identifier) - мы отобразили эту часть на картинке выше.
Вот, например, известные MAC OUI популярных вендоров:
CC:46:D6 - Cisco
3C:5A:B4 - Google, Inc.
3C:D9:2B - Hewlett liackard
00:9A:CD - HUAWEI TECHNOLOGIES CO.,LTD
И, собственно, вторые 6 цифр (6 цифр справа) уникальны и идентифицируют NIC (Network Interface Controller). Часто, MAC адреса записывают по-разному: через тире, двоеточие, или точки. Например:
00-50-B6-5B-CA-6A - самая распространенная и привычная для всех форма записи;
00:50:B6:5B:CA:6A - форма записи используется части всего в Linux системах;
005.0b6.5bc.a6a - такой формат записи MAC - адреса используется компанией Cisco.
Как узнать MAC - адрес?
Итак, чтобы узнать MAC - адрес в UNIX/Linux системах, подключитесь по SSH к вашему серверу и дайте команды:
ifconfig -a
ip link list
ip address show
Чтобы узнать MAC - адрес в Windows системах, откройте командную строку машины/сервера. Сделать это можно нажав комбинацию клавиш Win + R, ввести cmd и нажать Enter. Как только откроется консоль, дайте следующие команду:
ipconfig /all
А если вы обладатель Macbook да и вообще OS X устройства (любите посидеть в Starbucks и здорово провести время на заводе "Флакон"), то сделать нужно следующее:
Откройте в Launchliad "Терминал".
Введите команду ifconfig.
В строке ether будет указан MAC-адрес
Если вас удивляет то, каким образом веб-приложения могут взаимодействовать друг с другом и передавать информацию для оптимизации операций, то вам следует познакомиться с
Webhook
, веб-перехватчиком.
Webhook (он же веб-перехватчик) – это больше, чем просто средство информационного взаимодействия для онлайн-сервисов. Webhook – это достаточно любопытная технология, используемая для запуска приложений. Эта статья позволит получить четкое понимание того, что же такое Webhook и какие методы его работы существуют.
Видео: что такое Webhook и чем отличается от API?
Что такое Webhook: быстрый экскурс
Webhook – это автоматически сгенерированный HTTP-запрос, созданный на основе каких-то данных. Он запускается предопределенным событием или действием в исходной системе и передается системе, с которой исходная система пытается установить связь.
Webhook работает быстрее, чем опрос или API. Вместе с этим для разработчиков он является менее трудоемким с точки зрения работы. Применительно к приложениям, Webhook – это не что иное, как SMS-уведомления, которые мы получаем во время использования приложения. Например, при покупке некого товара в Интернете продавец присылает вам уведомление по SMS.
Аналогично, каждый раз, когда в исходной системе происходит некоторое событие/действие, система принимающей стороны уведомляется через Webhook.
Для чего нужен Webhook?
Webhook используется для связи приложений и быстрого обмена данными между системой-источником и системой-получателем. Это приводит к двусторонней связи между двумя различными сетевыми системами.
Ниже приведен список нескольких сценариев, при который Webhook справится лучше, чем любое другое средство связи приложений:
Использование Webhook для передачи информации о событиях в различные базы данных.
Требуется мгновенный ответ приложения при выполнении определенного действия.
Использование Webhook для беспрепятственной синхронизации данных клиентов в приложении.
Необходимость иметь модель push-уведомлений для получения своевременных обновлений.
Связь должна быть взаимно-однозначной.
Webhook может помочь установить соединение между средством массовой email-рассылки/управления проводимыми акциями и платежными системами.
Разработчики требуют приравнять 2 системы к временной системе связи.
Принимая во внимание все эти утилиты, Webhook можно назвать ключевым инструментом для разработки SaaS-приложений. Одним из реально существующих примеров использования Webhook является
Shopify
, который использует веб-перехватчик, например, для операций автоматического обновления корзины или объявления о продаже.
Еще одной известной платформой является
Stripe
. Она использует Webhook для передачи сведений, связанных с обновлениями учетных записей, уведомлений об оплате и др.
Webhook vs API
Человеку, не являющемуся специалистом в данной области, может показаться, что Webhook и
API
это одно и то же, поскольку они оба используются для установки связи между приложениями. Ситуация усугубляется, когда некоторые разработчики называют Webhook
обратным API
. В данном случае только опытный разработчик сможет понять разницу между этими двумя технологиями и использовать их. Мы подготовили краткий обзор основных различий между Webhook и API.
Обе эти технологии, как принято считать, используются приложениями для передачи информации другому приложению. В общих чертах они работают одинаково. Ключевое различие заключается в процессе получения данных.
API использует процесс «опроса» для получения необходимых данных. Опрос (
polling
) – это выполнение запросов на сервер с целью проверки появления новых данных.
Webhook работает по принципу «принудительной отправки данных», то есть как только происходит инициирующее событие, из источника отправляются необходимые данные.
API ожидает появления новых данных и требует периодической активности, в то время как Webhook активируется автоматически при возникновении события.
Если говорить об их практической реализации, то они принципиально разные. Например, API связывается с продавцом, чтобы удостовериться, что нужный вам товар есть в наличии, а Webhook попросит продавца самому связаться с вами, как только нужный товар будет доступен. При таком подходе обе стороны экономят время и усилия.
Безопасность Web API – сложная задача, поскольку запросы выполняются снова и снова, и каждый раз необходимо внедрять методы обеспечения безопасности API. Обеспечить безопасность Webhook относительно просто, поскольку запросы производятся не так часто.
Webhook лучше использовать, когда требуются обновления приложения в режиме реального времени, а API – когда часто обновляется серверное приложение.
Webhook – это простейшая модель API. API – это полноценный язык приложений, способный выполнять добавление, удаление и извлечение данных. Webhook работает автоматически, в то время как API требует некоторых усилий разработчика.
Webhook не является широко поддерживаемым, в то время как большинство сторонних интеграций принимают API.
Как работает Webhook?
На первый взгляд все кажется похожим, но Webhook включает в себя определённый сложный процесс. Вот как это работает:
Шаг 1: Генерация запроса
Для использования Webhook система должна быть достаточно оборудована для поддержки всего процесса. Можно разработать дружественную к Webhook систему, осуществляя несколько HTTP-запросов для различных событий. Основанный на этом принципе Webhook имеет хорошую совместимость с платформой SaaS, поскольку присутствует поддержка нескольких событий. Также с Webhook совместимы такие платформы, как GitHub, Shopify, Twilio, Stripe и Slack.
Для начала нужно зарегистрироваться, чтобы принять Webhook'и. Регистрация должна быть проведена для более чем одного события. После регистрации на целевой URL будет автоматически сгенерирован запрос Webhook. Этот запрос обработается автоматически, когда произойдет определенное событие.
Шаг 2: Применение Webhook
Когда процесс подготовки завершен, можно использовать Webhook'и. Процесс можно упростить, если вы создадите свои Webhook и протестируете их на пригодность. Если вам покажется это слишком тяжелым, то вы можете просто добавить нужный URL-адрес веб-перехватчика в приложение и начать делиться данными.
Для использования Webhook вы можете использовать средства, указанные ниже:
1. RequestBin и Postman для тестирования Webhook
Как уже отмечалось, тестирование Webhook – это наиболее эффективный способ понять его метод работы.
RequestBin
и
Postman
– два самых популярный инструмента для тестирования.
Используя RequestBin, разработчики могут создавать нужные URL-адреса веб-перехватчиков и обмениваться данными, чтобы проверить, как он их идентифицирует. Postman аналогично может обрабатывать процесс отправки запроса для терминала и выделенный код приложения. Разработчик может свободно работать с кодировкой JSON и XML.
2. Общение приложений
Тестирование Webhook было исчерпывающим. И теперь можно приступить к делу и позволить приложениям общаться между собой. Для начала разработчикам необходимо активировать Webhook триггерных приложений.
Как правило, каждое приложение имеет большое количество настроек веб-перехватчиков. Чтобы получить данные из используемого триггерного приложения, необходимо открыть настройку Webhook в заданной форме. Будет сгенерировано поле URL и варианты для спецификации HTTP-запроса веб-перехватчика.
На следующем шаге уже необходимо использовать URL-адреса приложения, получающего данные. В этом приложении каждый документ имеет свой конкретный URL-адрес слияния. Скопируйте URL-адрес слияния или любой другой предполагаемый URL-адрес приложения. Затем снова перейдите в приложение-триггер и вставьте скопированный URL-адрес веб-перехватчика из приложения, получающего данные, в поле URL-адреса приложения-триггера. Сохраните изменения. Теперь приложение готово к работе.
Вы можете использовать любой из вышеупомянутых средств включения Webhook. Чтобы концепция работы была более понятна, ниже мы привели пример работы Webhook Shopify:
Пример Webhook
Давайте продолжим приведенный выше пример Shopify. Предположим, что новый пользователь только что разместил 2 заказа в интернет-магазине после подтверждения адреса электронной почты. Получение информации с помощью события
customer/update
будет выглядеть примерно так:
HTTP/1.1 200 OK
{
"webhook": {
"id": 744408886555322224,
"email": "ss@testmail.com",
"accepts_marketing": false,
"created_at": null,
"updated_at": null,
"first_name": "Jane",
"last_name": "Doe",
"orders_count": 2,
"state": "disabled",
"total_spent": "0.00",
"last_order_id": 54254, 54258
"note": "The user registered from India and uses store for sending gifts",
"verified_email": true,
"multipass_identifier": null,
"tax_exempt": false,
"phone": 8585858585,
"tags": "retailer",
"last_order_name": null,
"currency": "INR",
"addresses": [
],
"accepts_marketing_updated_at": null,
"marketing_opt_in_level": null,
"admin_graphql_api_id": "gid://shopify/Customer/744408886555322224" }
}
Заключение
Процесс передачи данных является ключевым во взаимодействии человека и веб-приложений. Webhook делает взаимодействие между приложениями быстрым, беспрепятственным и не таким сложным. Webhook является альтернативой API и автоматизирует коммуникационное соединение.
Обмен сообщениями Publish/Subscribe, также известный как Pub/Sub, - это асинхронный метод связи между службами, который используется в бессерверных архитектурах и архитектурах микрослужб. В целом, модель Pub/Sub включает в себя:
Издателя (publisher), который отправляет сообщение
Подписчика (subscriber), который получает сообщение через брокера сообщений
В общих чертах, что такое обмен сообщениями Pub/Sub
С учетом того, что популярность несвязных приложений и приложений на основе микрослужб только растет, критически важное значение для общей функциональности приложения имеет надлежащая коммуникация между компонентами и службами. Обмен сообщениями Pub/Sub помогает здесь в двух аспектах:
предоставляет разработчикам возможность легко и просто создавать несвязные приложения, используя надежный метод;
предоставляет пользователям возможность легко и просто создавать событийно-управляемые архитектуры.
Модель Pub/Sub позволяет асинхронно передавать сообщения в несколько разделов приложений.
Основной компонент, который обеспечивает всю эту функциональность, называется Тема (Topic). Издатель отправляет сообщение в тему, а тема сразу же отправляет это сообщение всем подписчикам. Именно этот подход отличает модель Pub/Sub от обычных брокеров сообщений, где очередь сообщений группируется до тех пор, пока пользователь или служба не запросит и не извлечет их.
Что бы ни представляло из себя сообщение в модели Pub/Sub, оно в любом случае будет отправлено всем подписчикам. Единственное исключение – это политики для подписчиков, которые создаются пользователями и которые фильтруют сообщения.
Такой поход позволяет создавать событийно-управляемые сервисы, которые не будут требовать от подписчиков запрашивать сообщения из очереди. Также модель Pub/Sub позволяет разработчикам создавать различные отдельные функции, которые используют одно и то же сообщение (одни и те же данные) и которые могут выполняться параллельно, что дает возможность обслуживать сразу несколько подписчиков.
Шаблон Pub/Sub обособляет издателей от подписчиков для того, чтобы издатели не знали, где используется сообщение, а подписчики не знали ничего об издателе. Это способствует улучшению общей безопасности приложения.
Преимущества шаблона Pub/Sub
Распределенное приложение на основе микрослужб, которое к тому же было разработано с помощью шаблона Pub/Sub, приносит выгоду всей организации, от разработчиков программного обеспечения до инженеров, которые отвечают за контроль качества.
Ниже приведен список преимуществ шаблона Pub/Sub:
Несвязные/слабосвязные компоненты
Модель Pub/Sub позволяет легко разделить коммуникацию и логику приложения, это в свою очередь позволяет создать изолированные компоненты. Это обеспечивает:
создание модульных, более надежных и безопасных программных компонентов или модулей;
улучшение качества кода и удобство сопровождения.
Улучшенная наглядность в масштабе системы
Простота шаблона Pub/Sub позволяет пользователям легко понимать принцип работы приложения.
С помощью этого шаблона также можно создавать несвязные компоненты, которые позволяют наблюдать за информационным потоком. Мы можем точно знать, откуда идет информация и куда, без явного определения источников или адресатов в исходном коде.
Коммуникации в режиме реального времени
Pub/Sub мгновенно доставляет сообщения подписчикам с помощью push-доставки. Это делает данный подход идеальным для коммуникации в режиме, близком к режиму реального времени. Такой подход избавляет от необходимости отправки запроса для проверки наличия сообщений в очередях, в следствие чего снижается задержка доставки сообщений в приложении.
Простота разработки
Так как Pub/Sub не зависит от языка программирования, протокола или какой-то конкретной технологии, то в этот шаблон может быть интегрирован абсолютно любой поддерживаемый брокер сообщений с помощью любого языка программирования. Ко всему прочему, Pub/Sub может быть использован в качестве моста для обеспечения коммуникации между компонентами, которые были реализованы с помощью различных языков программирования, путем управления межкомпонентной связью.
Это приводит к тому, что такое приложение будет просто интегрировать с внешними системами и не нужно будет создавать дополнительные функции для упрощения процесса коммуникации или беспокоиться о последствиях нарушения безопасности. Мы можем просто опубликовать сообщение в теме и позволить внешнему приложению подписаться на эту тему, тем самым пропадает необходимость прямого взаимодействия с основным приложением.
Повышенная масштабируемость и надежность
Этот шаблон обмена сообщениями считается эластичным – не нужно заранее определять количество издателей или подписчиков. Их можно просто по необходимости добавить в нужную тему.
Тот факт, что коммуникация и логика приложения разделены, упрощает процесс устранения неисправностей, так как разработчики могут сосредоточиться на каком-то конкретном компоненте и не беспокоиться о том, что это может как-то повлиять на остальную часть приложения.
Шаблон Pub/Sub также улучшает масштабируемость приложения, так как позволяет менять архитектуру брокеров сообщений, фильтры и пользователей и не затрагивать при этом базовые компоненты. В модели Pub/Sub новая реализация обмена сообщениями в случае, если форматы сообщений совместимы даже со сложными изменениями в архитектуре, – это просто вопрос изменение темы.
Улучшенная способность к тестированию
В связи с тем, что приложение является модульным, тесты могут быть направлены на каждый модуль в отдельности, обеспечивая тем самым более оптимизированный процесс тестирования. Сосредоточенность на каждом отдельном компоненте приложения значительно снижает сложность тестовых сценариев.
Также шаблон Pub/Sub позволяет легко определить источник и адресат данных и информационный поток. Это особенно полезно, когда вы тестируете вопросы, связанные с:
повреждением данных;
форматированием;
безопасностью.
Недостатки шаблона Pub/Sub
Pub/Sub – это надежная служба обмена сообщениями, но она не всегда соответствует всем требованиям. Давайте кратко рассмотрим некоторые недостатки этого шаблона.
Излишняя сложность в небольших системах
Pub/Sub требует правильной настройки и сопровождения. Если масштабируемость и несвязность компонентов не являются жизненно важными аспектами для вашего приложения, то внедрение такого шаблона, как Pub/Sub, будет пустой тратой ресурсов и добавит небольшой системе излишнюю сложность.
Потоковая передача мультимедиа
Pub/Sub не подходит для работы с медиафайлами, такими как аудио или видео, так как они требуют плавной синхронной потоковой передачи между хостом и получателем. Так как этот шаблон не поддерживает синхронную сквозную передачу данных, то обмен сообщениями Pub/Sub не стоит рассматривать для:
видео-конференций;
голосовой связи по IP-протоколу;
обычных приложений для потоковой передачи мультимедиа.
Обмен сообщениями Pub/Sub: варианты использования
Итак, когда же лучше всего использовать шаблон Pub/Sub?
Шаблон Pub/Sub можно использовать в самых различных областях для того, чтобы облегчить обмен данными в режиме реального времени и при распределенных коммуникациях. Например, ключевая сфера, которой такой шаблон только на руку, - это автоматизация.
В следующих разделах вы найдете описание самых распространенных вариантов использования шаблона Pub/Sub.
Интернет вещей
В эпоху интеллектуальных устройств нам требуется надежный и эффективный способ сбора и распространения информации. Узел управления или сервер может публиковать обновления, которые будут автоматически доставляться на все подписанные устройства Интернета вещей.
Пользовательские устройства Интернета вещей также могут выступать в роли издателей и публиковать уведомления, информацию от датчиков и т.д. в облаке, которые затем будут переданы пользователю.
Контроль системы и уведомления о событиях
Pub/Sub позволяет пользователям создавать темы для сбора сведений о системе и отправки их в интерфейсы визуализации и уведомлений.
Такой подход будет крайне полезен при работе с крупномасштабными внедрениями:
Сообщения можно группировать по категориям.
Все серверы и службы могут публиковать данные в этих общих темах; при этом не нужно создавать отдельные конвейеры уведомлений.
Можно выйти за пределы этой функциональной возможности, подписавшись на функции сопровождения или управления темой. Например, если сервер сообщает об ошибке, то он запускает функцию, которая автоматически заменит этот сервер.
Резервное копирование и репликация базы данных
Крайне важно делать резервные копии баз данных, которые распределены по разным технологиям и поставщикам. Можно настроить периодическое резервное копирование или снимки состояний с помощью планировщика задач.
А теперь давайте представим, что нам необходимо переместить эти резервные копии в другие области или облачное хранилище. В таком случае нам нужно воспользоваться шаблоном обмена сообщениями Pub/Sub, чтобы создать конвейер, который будет отправлять сообщение о завершении резервного копирования. Затем подписанная функция будет использовать это сообщение в качестве триггера, чтобы запустить процесс переноса или копирования.
Управление журналами
Шаблон Pub/Sub может выступать в роли посредник для агрегации и распространения журналов. Журналы можно собирать из нескольких мест и отправлять в подписанные службы, такие как масштабируемый поиск, или хранить их в разных местах.
Журналы можно фильтровать по вопросам, журналам аудита, уведомлениям, фоновым задачами и т.д. и направлять их подписчикам. Таким образом, можно обеспечить надлежащее управление журналами.
Службы обмена сообщениями Pub/Sub
Существует большое количество различных служб обмена сообщениями по шаблону Pub/Sub, от специализированных брокеров сообщений до облачных решений. Далее представлен список некоторых популярных служб Pub/Sub.
Apache Kafka. Kafka разработан Apache и имеет надежные функции обмена сообщениями Pub/Sub с помощью журналов регистрации сообщений.
Faye. Это простая служба Pub/Sub, которая предназначена для обеспечения работы веб-приложений с помощью серверов, разработанных для NodeJS и Ruby.
Redis. Это один из самых популярных брокеров сообщений, который поддерживает как традиционную очередь сообщений, так и реализацию шаблона Pub/Sub.
Amazon SNS. Amazon Simple Notification Service – это полностью управляемая служба, которая использует реализацию обмена сообщениями Pub/Sub.
Google Pub/Sub. GPS подходит для реализации службы обмена сообщениями Pub/Sub.
Azure Service Bus. Надежная служба обмена сообщениями (MaaS) с возможностью использования шаблона Pub/Sub.
Простой пример: обмен сообщениями Pub/Sub
Теперь, когда мы разобрались в концепции Pub/Sub, давайте рассмотрим простой пример, который иллюстрирует рабочий процесс, с помощью Google Pub/Sub. Он опубликует сообщение в теме и вызовет подписанную функцию Google для того, чтобы напечатать отправленное сообщение.
Шаг 1. Создание темы
Первый шаг – создать тему в Google Pub/Sub для того, чтобы у нас была возможность публиковать сообщения в этой теме.
Шаг 2. Настройка триггера
Необходимо перейти в созданную тему (Test_Topic) и нажать «Trigger Google Function». Таким образом вы сможете создать функцию Google, где в качестве триггера будет выступать созданная тема.
Шаг 3. Создание функции Google (print_message_pubsub_test)
На первом экране вы можете дать функции название и настроить тему в качестве триггера. Для создания функции, которая будет просто собирать передаваемые данные и отправлять их на сайт Webhook, мы будем использовать Python.
Помимо этого, для создания запроса POST для отправки данных мы будем использовать библиотеку запросов.
Фрагмент кода облачной функции:
import base64
import requests
def get_quote(event, context):
# Decode the Message Data
message = base64.b64decode(event['data']).decode('utf-8')
# Create Request
url = "https://webhook.site/xxxxxxx-xxxx-xxxx-xxxx-739c28ebd7ad"
request_headers = {"Content-type": "application/json"}
request_data = {"quote": message}
response = requests.post(url, data=request_data, headers=request_headers)
# Print Response
print(response.status_code)
print(response.text)
После того, как функция будет успешно развернута, вы увидите, что в качестве триггера функции будет указана тема Test_Topic.
Шаг 4. Настройка издателя
На этом шаге нам нужно создать простую программу на Python, которая будет выступать в роли издателя.
Воспользуемся библиотекой Google Cloud pubsub_v1 для того, чтобы создать клиента Publisher и выбрать случайную вдохновляющую цитату с сайта quotable.io. После чего мы опубликуем объединенную строку (автор и цитата) в тему (Test_Topic).
message_publish.py
from google.oauth2 import service_account
from google.cloud import pubsub_v1
import requests
# Create Authentication Credentials
project_id = "test-applications-xxxxx"
topic_id = "Test_Topic"
gcp_credentials = service_account.Credentials.from_service_account_file('test-applications-xxxx-xxxxxxxxxx.json')
# Create Publisher Client
publisher = pubsub_v1.PublisherClient(credentials=gcp_credentials)
topic_path = publisher.topic_path(project_id, topic_id)
# Get a Random Quote
response = requests.get("https://api.quotable.io/random")
json_response = response.json()
message = f"{json_response['author']} - {json_response['content']}"
# Publish the Message
data = message.encode("utf-8")
future = publisher.publish(topic_path, data)
# Print Result
print(f"Published messages to {topic_path} - {future.result()}.")
Ну вот и все! Мы успешно настроили конвейер обмена сообщениями. Когда вы запустите скрипт «message_publish», данные опубликуются в Test_Topic, запустится облачная функция Google (print_message_pubsub_test), которая отправит данные на сайт Webhook.
Здесь мы можем видеть сообщения, которые были опубликованы в теме.
В журналах облачной функции Google будет зафиксировано, что функция была запущена.
И наконец, ниже мы можем видеть все сообщения, которые получил сайт Webhook.
Выше мы рассмотрели базовую структуру любого рабочего процесса обмена сообщениями по шаблону Pub/Sub. Можно использовать его как обычный шаблон или расширить его для того, чтобы улучшить какие-то функциональные возможности.
Простые коммуникации с широкими возможностями
Шаблон обмена сообщениями Pub/Sub – это мощный, но при этом простой метод передачи информации. Он выступает в роли краеугольного камня для обеспечения работы распределенных приложений на основе микрослужб в режиме реального времени. Он управляет всем процессом обмена данными между внутренними и внешними компонентами.
Шаблон Pub/Sub можно использовать для создания асинхронных масштабируемых потоков обработки сообщений с минимальными задержками при доставке. Все это возможно благодаря всем тем преимуществам, в которых он превосходит брокеров сообщений.