YandexMQ: простые очереди сообщений в облаке

Перфокарты и патчи

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

На ней 80 колонок, по 10 цифр в каждой. Чтобы запрограммировать на ней какую-то программу, напротив нужных цифр вы пробивали дырки. Эти карточки с дырками вы загружали в компьютер, программа выполнялась и выдавала вам результат.

Теперь представьте, что вы написали какую-то программу на этом кусочке картона и вдруг ошиблись. Что же вам делать?

Если для исправления ошибки нужно пробить дырку там, где ее нет, это было просто – вы ее пробивали. А что делать, если уже пробитую дырку нужно исправить? Конечно, можно было взять новую карточку и все заново на ней набить, но была вероятность допустить ошибку снова. Как быть?

Лейкопластырь! Чтобы быстро все исправить, там, где дырка была не нужна, ее просто заклеивали лейкопластырем.

Это фотография, на которой на реальной перфоленте дырки были заклеены лейкопластырем. Вот таким нехитрым образом в прошлом вносились быстрые исправления в программы.

На английском слово «заплатка» или «пластырь» называется patch (патч). Слова «патч», «патчить», «поставить заплатку» в значении «вносить исправление в программу» произошли как раз вот отсюда, от заклеенных дырок на перфокартах.

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

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

Что такое брокер сообщений?

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

На схеме – суперпростая схема обмена данными. Какая-то система отправляет в другую систему какие-то данные; общаются они напрямую, например, через веб-сервис.

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

У вас может появиться вполне справедливый вопрос: а зачем такую простую схему так усложнять? Кажется, что это лишний элемент.

Аналогия с мессенджерами и асинхронной коммуникацией

Мне понять брокера сообщений помогла аналогия из жизни. Современные технологии подарили нам совершенно замечательную вещь – мобильный телефон. У каждого из вас он точно есть. Кто из вас любит по нему как можно больше разговаривать? Таких, скорее всего, мало. А кто предпочел бы, чтобы ему написали в мессенджер или на почту? Таких будет больше.

Как вы думаете, почему многие люди сегодня действительно предпочитают вместо звонков сообщения? Если у них спросить, почему, обычно они отвечают, что звонки требуют достаточно много сил, времени и внимания. И требуют они его прямо сейчас.

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

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

Если мне будут звонить целый день, я все свои другие дела не смогу сделать – я буду просто трепаться целый день.

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

Чтобы решить эти задачи, мы поставим между нами мессенджер – посредника, брокера. Например, WhatsApp или Telegram. Вместо звонка вы будете мне просто туда писать. Мессенджер будет доступен всегда. Сообщение для меня не потеряется. Даже если я сейчас сплю, я прочитаю его тогда, когда проснусь. Вам не нужно меня ждать, а мне не нужно реагировать на ваше сообщение немедленно.

Когда сообщений много, я также не буду ими перегружен. Я смогу читать их с комфортной для себя скоростью – тогда, когда лично у меня есть на это время и силы.

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

Применение брокера сообщений в интеграции систем

Допустим, у нас есть какая-то база 1С и какой-то другой сервер, например, сайт с заказами. Сайт шлет заказы в 1С – все просто и понятно.

Но что, если 1С вдруг отключится – например, уйдет на обновление на пару часов? Очень типовой сценарий, так часто бывает. В этом случае сайт будет либо падать с ошибками, либо будет занят постоянными попытками отправить заказы в 1С. Он будет тратить свои ресурсы на эти попытки отправки, либо администраторы сайта будут недовольны тем, что сыплются ошибки, либо они просто отключат повторные отправки – и тогда заказы для 1С потеряются.

Поставим посредника между сайтом и 1С. Теперь сайт будет слать в некоторый «почтовый ящик» сообщения, а 1С будет вычитывать из этого почтового ящика. Если любая из этих двух систем перестанет работать, вторая продолжит работать: 1С продолжит вычитывать все, что есть из почтового ящика, а сайт будет слать в этого посредника.

Теперь представьте, что бизнес у нас вырос, и количество заказов увеличилось кратно. Сайт начинает «долбить» нашу 1С заказами. Заказов становится настолько много, что 1С просто перестает с ними справляться. Ее ресурсов и пропускной способности не хватает на такой объем. Скорее всего, она начнет тормозить, что затронет работу других пользователей в ней. В ней же работают еще финансисты, бухгалтеры, менеджеры, она осуществляет не только прием заказов. То есть большой объем обработки информации от сайта может начать тормозить остальные части системы.

Или похожая ситуация: когда вместо одного сайта с кучей заказов у вас много разных систем, которые идут в вашу 1С, она будет просто перегружена.

Снова поставим между 1С и информационной системой посредника. Описанные выше проблемы будут решены: все системы будут ходить в посредника, а 1С будет забирать оттуда данные в том темпе, в котором ей удобно.

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

О брокерах можно думать, как о некоем to do list – списке дел, который можно сделать потом. Лично мне больше нравится пример раковины с посудой. Вы можете в эту раковину положить грязную посуду, а помыть ее когда-нибудь попозже, а не сразу, и не всю.

Обзор существующих брокеров сообщений

Идея брокеров сообщений не нова, их достаточно много на рынке: Kafka, RabbitMQ, Redis, Amazon SQS, ActiveMQ и другие. Каждый из них хорош в чем-то своем, каждый делает какие-то вещи лучше, какие-то хуже.

Идея у всех примерно одинаковая, но разные брокеры реализуют ее по-разному. Какие-то брокеры простые – просто принимают сообщение как есть и передают его тоже как есть. Другие поумнее – умеют преобразовать сообщение в какой-то другой вид. Как при расшифровке голосовых в мессенджере – вам прислали голос, который посредник преобразовал в текст, чтобы вы приняли его в том виде, в котором вам удобнее. То же самое умеют делать некоторые брокеры.

Какие-то брокеры используют сложные форматы и протоколы обмена, стремясь оптимизировать скорость сетевых обменов; какие-то обмениваются по очень простым и понятным протоколам, например, по HTTP.

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

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

Yandex Message Queue (YMQ)

YandexMQ, на мой взгляд, это один из самых простых брокеров – с ним легко разобраться и начать работать. Хочу рассказать про особенности его работы и о том, как вы можете его попробовать с 1С.

На российском рынке есть такой провайдер облачных услуг – Яндекс.Облако или Yandex Cloud. В этом облаке есть свой брокер сообщений, он называется Yandex Message Queue, покороче – YandexMQ, или совсем коротко – YMQ.

Если дистрибутивы других брокеров, вроде RabbitMQ и Kafka, вы можете скачать и установить самостоятельно на свой компьютер, то с YandexMQ так не получится. YandexMQ работает только на серверах Яндекса.

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

В этом есть и плюс. Вам не нужно заниматься установкой и обслуживанием этого брокера. Достаточно зарегистрироваться в Яндекс.Облаке – и брокером уже можно пользоваться. Сразу после регистрации вы сможете управлять вашими очередями в веб-интерфейсе.

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

Графический интерфейс – это удобно. Обычно управлять всякими сложными консольными командами бывает не так приятно.

Важная и полезная возможность – это мониторинги. Чем больше у вас очередей и чем больше в них появляется сообщений, тем сильнее вам нужны инструменты, «приборы» для контроля их работы. На мониторингах в виде графиков можно будет видеть, сколько сообщений вам прилетает, какие из них обрабатываются, какие падают с ошибкой, насколько быстро все это происходит, и все это – в веб-интерфейсе.

Особенности Yandex MQ

Во-первых, сообщение может быть любой строкой. Только вам, как разработчику, решать – будет это JSON, XML, YAML или обычный текст. Это зависит только от вас.

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

Получение сообщений происходит по PULL-модели. Есть две модели поведения брокеров – PULL и PUSH. PULL – это когда вы приходите к брокеру и говорите: «Дайте мне, пожалуйста, то, что у вас есть». PUSH – когда сам брокер активно толкает, отправляет запрос вам.

Важная особенность, на мой взгляд, – это работа по протоколу HTTP. Если, допустим, для работы с RabbitMQ вам необходимы внешние компоненты для 1С, то Yandex MQ будет работать по знакомому всем разработчикам простому и понятному протоколу HTTP.

Yandex MQ не изобретал собственный протокол – он использует стандарт веб-сервисов компании Amazon: Amazon SQS (Simple Queue Service). Это означает, что если у вас есть инструменты для работы с Amazon SQS, вы можете использовать их и для Yandex MQ.

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

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

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

У очередей есть три базовые операции, на них приходится 80% работы:

• отправка сообщения в брокер. Здесь все просто и понятно – как если бы вы написали кому-то в мессенджер. Мессенджер просто сохраняет это сообщение.

• получение сообщения, когда мы берем сообщение из брокера для его обработки. Здесь важно то, что брокер при получении сообщения блокирует его на определенное время и ждет от нас команды: обработали мы его или нет. Программистам 1С должна быть знакома аналогия с блокировкой во время транзакции, здесь происходит примерно то же самое.

• удаление сообщения. Мы говорим брокеру: «Мы обработали это сообщение, оно больше не нужно – пожалуйста, удали его и никому больше не отдавай».

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

Преимущества и недостатки облачного решения

Как и у всего в этой жизни, в облачных решениях есть и достоинства, и недостатки.

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

Второй недостаток – вам обязательно будет нужен интернет. С облаком вы взаимодействуете через интернет, и если серверам ваших компаний по каким-то причинам (а они бывают) нельзя ходить во внешний мир, облачное решение вам тоже не подойдет.

Третий недостаток – я бы отметил относительно медленную передачу данных. Data-центры облачных провайдеров обычно находятся далеко от ваших серверов. И сетевой обмен, да еще и по протоколу HTTP, может быть медленнее, чем если бы брокер стоял в контуре вашей компании. Если скорость сетевых обменов и передача сообщений для вас критически важна, облачное решение с этим брокером вам, скорее всего, не подойдет.

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

Когда мы рассматривали схему обмена, мог возникнуть вполне закономерный вопрос: «А если сам брокер упадет? Что делать?» Естественно, в этом случае у нас вся система обмена ломалась напрочь.

Именно поэтому очень важно сделать так, чтобы брокер работал всегда без сбоев и мог выдерживать огромную нагрузку. В том числе – работал тогда, когда случилось что-то плохое: залило сервер, отключили электричество в здании, сгорел сервер при пожаре (такое тоже бывает). В случае с облаком вам не нужно беспокоиться о том, что брокер когда-либо упадет.

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

Третье преимущество – этот брокер интегрируется с другими сервисами Yandex Cloud.

Платформа 1С, как вы знаете, называется «платформой», потому что это набор строительных элементов, кубиков, по-разному складывая которые, мы можем делать решения для наших задач. Yandex Cloud – это такая же платформа, в ней тоже есть набор разных сервисов. YandexMQ только один из них. И все они умеют дружить друг с другом. Один из примеров – мониторинги, про которые я упоминал выше. Есть еще подписки на события, сервис уведомлений, который можно настроить на работу с очередями и так далее.

Практические примеры использования Yandex MQ

Мы в работе очень активно используем этот брокер. Например, у нас есть внешняя система согласования документов, которая раньше ходила в 1С напрямую. Когда 1С отключалась для обновления, мы теряли обновления статусов. Эта система не умела досылать сообщения, и в итоге у нас расходились данные. Мы перенастроили все так, чтобы система согласования помещала данные в брокер, а 1С вычитывала их оттуда, когда поднимется после обновления.

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

Еще у нас есть множество микросервисов, написанных на C++ и Python. Они очень активно общаются между собой именно с помощью очередей.

Как начать использовать YandexMQ

Чтобы попробовать этот брокер, достаточно зарегистрироваться в Яндекс.Облаке. Сразу после регистрации у вас уже будет готовая админка – там вы можете создавать очереди, менять их настройки, смотреть графики и так далее.

YandexMQ – это программа, которую вы можете взять в аренду у Яндекс.Облака. Аренда обычно платная, но здесь есть приятные новости. У Яндекс.Облака есть так называемый Free Tier. Каждый месяц первые 100 000 запросов в очереди и первые 100 гигабайт исходящего трафика будут бесплатными. Это означает, что можно использовать этот брокер для небольших проектов или для каких-то экспериментов совершенно бесплатно.

Как из 1С можно работать с этим брокером? Это пример использования библиотеки:

// для работы с ЯндексMQ обязательно требуются AccessKey и SecretKey.
// Это своеобразные логин и пароль для доступа к сервису.
// как их получить описано на https://yandex.cloud/ru/docs/iam/operations/sa/create-access-key

// создаем клиент для обращения к сервису
ПараметрыКлиента = Новый Структура;
ПараметрыКлиента.Вставить( "AccessKey", "YC2Gyh6..." );
ПараметрыКлиента.Вставить( "SecretKey", "YC2Jnb2..." );
ЯндексMQ  = Обработки.ЯндексMQ2.НовыйКлиент( ПараметрыКлиента );

// создадим новую очередь
Запрос = Новый Структура;
Запрос.Вставить( "QueueName", "my-tasks" );
UrlОчереди = ЯндексMQ.СоздатьОчередь( Запрос );

// отправим сообщение в очередь
Запрос = Новый Структура;
Запрос.Вставить( "QueueUrl", UrlОчереди );
Запрос.Вставить( "MessageBody", "Hello, world!" );
ЯндексMQ.ОтправитьСообщение( Запрос );

// получим сообщения из очереди
Запрос = Новый Структура;
Запрос.Вставить( "QueueUrl", UrlОчереди );
Сообщения = ЯндексMQ.ПолучитьСообщение( Запрос );

// обработаем все полученные сообщения
Для Каждого ДанныеСообщения Из Сообщения Цикл
    // КакТоОбработать( ДанныеСообщения.Body );
    // успешно обработанные - удалим из очереди
    Запрос = Новый Структура;
    Запрос.Вставить( "QueueUrl", UrlОчереди );
    Запрос.Вставить( "ReceiptHandle", ДанныеСообщения.ReceiptHandle );
    ЯндексMQ.УдалитьСообщение( Запрос );
КонецЦикла;

Библиотека доступна на GitHub, она бесплатная, с открытым кодом – вы можете брать ее и пользоваться. Ее задача – упростить вам работу с брокером, чтобы вы сами не писали интеграцию, а сразу начали решать прикладные задачи.

Заключение

Надеюсь, вы узнали для себя что-то полезное про работу брокеров сообщений. Обычно их начинают использовать тогда, когда нагрузка на системы кратно вырастает. Если вам интересно попробовать, оставляю ссылку на библиотеку для работы с YandexMQ из 1С:

https://github.com/leemuar/yandexmq-sdk-1c

Компания Amazon, когда делала свой брокер сообщений SQS, назвала его Simple Queue Service – «простой сервис очередей». И слово «простой» здесь ключевое. Идея простоты лежит и в основе брокера YandexMQ. Вам не нужно тратить время на установку и обслуживание этого брокера, не нужно разбираться в сложных сервисах, трансформации, модификации сообщений. Протокол HTTP нам, разработчикам 1С, знаком и понятен.

Я рекомендую попробовать и другие брокеры – и Redis, и RabbitMQ, и Kafka, и все остальные. Каждый из них хорош в чем-то своем. Но если меня спросят, с какого проще всего начать тому, кто не понимает, что такое брокеры, на каком можно быстрее увидеть результат, то по совокупности факторов я бы рекомендовал попробовать YandexMQ.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.