Распутывая узлы интеграции: Построение архитектуры слабосвязанных систем, или Кролики наступают

О чем будем говорить?

• О типичных проблемах интеграции в проектах 1С и о том, как их решать.
• Я постараюсь донести до вас концепцию событийной интеграции и рассказать о том, насколько это хорошо и правильно.
• Мы рассмотрим паттерны решений различных проблем с помощью очередей.
• Я расскажу о нашей подсистеме Yellow RabbitMQ («Желтый кролик») – что это и как это «дружит» с 1С.

Как выглядит типовой корпоративный ландшафт?

Типовой корпоративный ландшафт сегодня – это зоопарк систем, где есть:

• База для ведения бухгалтерии;
• База НСИ;
• База для склада;
• Свой сайт;
• Все, что угодно.

Пример из жизни (торговая организация):

• В системе продаж продажники заводят контрагентов;
• В складской системе регистрируется запуск фур по каким-то заявкам;
• На сайте принимаются заказы клиентов;
• Работает своя система для учета звонков call-центра;
• Типовая база для ведения бухгалтерии;
• И тут же еще рядом «Зарплата и управление персоналом», куда сотрудникам падают премии за продажи.

Множество различных систем, и все это между собой интегрировано.

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

Типичные проблемы при интеграции множества систем

Какие типичные проблемы возникают при интеграции множества систем?

• Это – сильная связанность смежных систем между собой, обусловленная взаимозависимостью их компонентов. Она влияет:
  • На работоспособность этих систем;
  • На их реализацию.

Такое состояние, когда изменения в одной системе «ломают» другую систему, из-за чего в нее также приходится вносить изменения, как раз и называется «сильной связанностью».

• Кроме того, несобытийная интеграция с использованием «вытягивающего» интерфейса – это медленно. Нам приходится ждать, когда случится обмен, поэтому актуальные данные неизбежно запаздывают.
• И еще одна проблема – это непрозрачность потоков данных. Сложно однозначно сказать кто, когда, кому и что посылает.

Привычные средства интеграции в мире 1С

В мире 1С приняты следующие классические средства интеграции:

• Обмен файлами, который все любят – в одной системе кнопочку нажали, документы выгрузили, в другой – загрузили. Перепутали, загрузили какой-то не тот файл, поудаляли документы – все как обычно.
• Более «продвинутые пацаны» используют удаленные вызовы процедур (некие вызовы из системы в систему). Сюда относятся:
  • Веб-сервисы;
  • HTTP-сервисы;
  • COM/OLE.
• Некоторые используют прямой доступ к базе данных 1С – способ не очень красивый, но также распространенный. Залезают на SQL-сервер и что-нибудь из базы 1С вычитывают, или даже, не дай бог, туда пишут, притворяясь сервером 1С – такое тоже бывает.

Два типа интерфейсов

Существует два типа взаимодействия, два типа интерфейсов.

• Первый тип – это pull-интерфейсы, вытягивающие или «сосущие» интерфейсы. Это когда мы обращаемся в некую систему с целью забрать оттуда какие-то данные. Или опросить ее, нет ли у нее для нас каких-либо новостей, каких-либо изменений.
• И второй тип – это уведомляющие интерфейсы. Здесь ситуация полностью обратная: когда в какой-нибудь системе происходит событие (некий акт ввода данных), эта система уведомляет всех заинтересованных о том, что в ней что-то произошло.

Использовать «сосущий» вариант интерфейса – это неправильно, поскольку:

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

Интегрирующая среда

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

• Конечно, если у вас две системы, которые обмениваются по механизму «точка-точка», вам интегрирующая среда, скорее всего, не нужна, потому что особых проблем у вас пока что нет.
• Но если систем становится пять и более, вы неизбежно придете к тому, что все начнут обмениваться со всеми, и вы никогда не разберетесь, кто, кому, когда и что посылает. Поэтому наличие интегрирующей среды (специального отдельного программного компонента, который управляет взаимодействиями) – это суровая необходимость. Те, у кого такого компонента нет – живут неправильно.

Наличие интегрирующей среды обеспечивает:

• Слабую связанность систем. Мы можем вообще заменить одну систему на другую (например, убрать SAP и поставить 1С), а остальные клиенты этого даже не заметят.
• А также прозрачность. Например, когда вам нужно «распутать клубок», вы, глядя на административный интерфейс интегрирующего ядра, сможете понять:
  • Кто;
  • С кем интегрируется;
  • В каком формате;
  • Как часто;
  • А также измерить нагрузку на системы, возникающую в процессе обмена.

Без имени – нет предмета

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

Казалось бы, причем здесь интеграция?

Выделение потоков данных

А интеграция здесь вот причем. Перед ее реализацией нам обязательно нужно:

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

Распутываем клубок

После выделения потоков данных переходим к «распутыванию клубка»:

• Пытаемся отсортировать потоки данных – их все, как правило, можно отнести к трем категориям.
  • Нормативно-справочная информация.
  • Оперативные данные, «первичка» (то, что приходит из реального мира).
  • И порождаемые данные – это то, что выходит из бизнес-процесса.
• Итак, мы выделили все эти бизнес-потоки, дали им отдельные имена, написали их на бумажках и прикололи на доску. Дальше начинаем растаскивать эти бумажки по категориям – здесь у нас НСИ, здесь «первичка», здесь порождаемые данные. И следующим шагом определяем взаимосвязи между потоками. Чтобы это было легче делать, лучше рисовать диаграммы.
  • Data-Flow-диаграммы;
  • Или диаграммы сущность-связь, которые все знают.

Это – очень полезно, особенно с учетом того, что есть много бесплатных инструментов, которые позволяют удобно делать все эти диаграммы. Их можно хранить в том же GIT, как и другую документацию по проекту.

Уникальность НСИ

Отдельно хотелось бы остановиться на НСИ, потому что это – самая большая часть задачи, которая требует наведения порядка.

Существует масса подходов к наведению порядка в нормативно-справочной информации.

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

То есть, система должна обеспечивать однозначную идентификацию объектов. По этому поводу есть замечательная статья Александра Масляева на Инфостарте Mom and Dad`s Misery. Если у вас проблемы с интеграцией по справочникам – обязательно ее прочитайте. Это прямо must read.

Инвертировать хранение

Следующее, на что нужно осмелиться – это реализовать инвертирование хранения. Это значит, что:

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

Все есть событие

И последний момент из теории – «Все есть событие»:

• Ось времени реального мира – это ваш ориентир. Разбираясь с бизнес-процессом, разбираясь с интеграцией, которая потребуется для этого бизнес-процесса, всегда рисуйте себе таймлайн реального времени и отмечайте на нем:
  • Что;
  • В какой момент;
  • И в какой из систем происходит (или в каком-то отделе или корпорации).
• Задним числом ничего не бывает – машины времени не существует.
  • Попытки строить интеграцию, которая разрешает проведение задним числом – это выкапывание ямы самому себе. Даже перепроведение документов задним числом происходит сейчас – в прошлое бухгалтер не улетал.
  • Поэтому намного дешевле организационно запретить любые операции «задним числом», чем потом пытаться построить такую интеграцию, которая бы при изменении в прошлых периодах автоматически деактуализировала данные во всех смежных системах.
  • Лучше просто это запретить и сказать «Сторнируйте и все». Это будет реально дешевле, хотя и неизбежно встретит сопротивление.
• После того как мы выделили эти бизнес-события, происходящие в системе, мы должны разослать их всем заинтересованным.
• И по большому счету, нам больше ничего делать не нужно – задача интеграции на этом заканчивается.

Если бы все было так просто… на самом деле, здесь все только начинается.

Captain Rabbit to the Rescue!

Как же все-таки рассылать все эти события и как обеспечивать слабую связанность и быструю интеграцию между системами?

Существует высокопроизводительный промышленный сервер очередей, который называется RabbitMQ. В переводе, если кто не знает, это значит «кролик».

Этот сервер очередей позволяет организовать самые разные схемы взаимодействия систем между собой. Он:

• Высокопроизводительный;
• Отказоустойчивый;
• Масштабируемый;
• Много лет уже используется на мировом рынке;
• Доказал свою надежность делом во множестве тысяч организаций в мире.

Терминология

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

• Первое – это Exchange, точка обмена, то, куда мы публикуем сообщения.
• Второй важный термин – это очередь – Queue. В ней мы храним сообщения, пока они не доехали до клиента.
• И третий важный термин – это Consumer, потребитель, тот, кто эти сообщения из очереди вычитывает.

Остальные термины, так или иначе, связаны с первыми тремя.

Основные схемы взаимодействия, которые можно построить с помощью RabbitMQ.

Прямой обмен

Самая простая схема – это прямой обмен.

• Издатель публикует события;
• Потребитель эти события забирает;
• Если потребитель по каким-то причинам недоступен, посередине находится буфер, в котором эти сообщения хранятся до тех пор, пока он их не начнет оттуда «вычитывать».

До меня выступал Сергей Сорокин, который рассказывал про интеграцию с сайтом. Там говорилось, что когда на сайт что-то выгружается, посылается GET-запрос, чтобы получить ответ об успешной загрузке. Это тот самый «сосущий» интерфейс, так делать не надо. Мы предлагаем другой способ:

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

Сбалансированная обработка

Второй паттерн – это сбалансированная обработка.

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

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

Издатель-подписчик

Еще один, наиболее распространенный паттерн – это «Издатель-подписчик». Он очень простой:

• Система, публикующая сообщения, не знает, кому она их отправляет. Она просто «кидает» эти события «во вселенную». Сообщает: «Я провел документ» или «Товар оприходован».
• А те системы, которым интересны события прихода товаров или изменения номенклатуры, на них подписываются.

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

Маршрутизация

Очень важный момент в сервере RabbitMQ – это то, что он поддерживает маршрутизацию сообщений.

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

На рисунке можно рассмотреть пример, когда у нас есть:

• Система 1С, которая просто пишет сообщения в журнал регистрации – среди этих сообщений есть ошибки, предупреждения, информационные сообщения.
• И есть у нас две смежные системы.
  • Первая – это мониторинг, который в случае ошибок зажигает красную лампочку. Мониторингу интересны только ошибки;
  • И вторая – это система хранения логов (чтобы через Elastic Search в них быстро искать). Система хранения логов подписана на все и просто складывает логи себе.

В первую очередь пойдут только ошибки, а во вторую – вообще все. Это можно организовать с помощью маршрутизации на «ключах».

RPC (вызовы процедур)

И последний паттерн – это тот самый RPC.

• С помощью RabbitMQ, как правило, организуется асинхронный RPC, позволяющий «развязать» системы между собой.
• Вызвали систему и не ждем, пока она ответит, потому что она в этот момент может не работать. Если мы будем ждать ответ, то мы тоже не будем работать. Вдруг она «сломалась», или у нее там регламентное обновление.
• Меняем модель программирования: асинхронные вызовы позволяют не ждать ответа от системы, потому что система в этот момент может не работать.
  • Отправляем вызов в систему: «Система, сделай нечто». Например: «Сайт, загрузи товары». И сайт их событийно забирает из очереди.
  • Или системе посылается вызов: «Выполни такой-то код». Отправляем вызов, и он падает в очередь.
  • Или еще пример – резервирование товаров – бросили вызов о необходимости резервирования. Система-приемник подхватывает этот вызов, выполняет его, а мы уже пошли заниматься своими делами.
• Ответ об успешном выполнении вызова система нам точно так же запускает по очереди, а мы его у себя забираем. Если вдруг у нас в этот момент что-то «сломалось», мы этот ответ забираем потом, когда свою систему починим. Делается это довольно просто:
  • В каждом вызове есть некий «ключ вызова» (номер этого вызова).
  • И когда вам приходит ответ, вы по номеру вызова можете определить, какой на него был ответ.

Интеграция на очередях

Есть замечательный сайт http://tryrabbitmq.com/.

На нем можно строить вот такие схемы (диаграммы взаимодействий) и «играться» с RabbitMQ, даже не устанавливая его себе.

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

• Всегда представляйте себе ось времени реального мира.
• Событие происходит в системе и сообщение о нем может попасть в несколько мест.
  • Типичный пример – изменение НСИ, информация о нем нужна многим системам. Система, в которой хранится НСИ, выкидывает событие об изменении в мир, а те, кто на это событие подписаны, его забирают.
• И наоборот. Одинаковые сообщения могут приходить в систему из разных мест. Система, которая принимает сообщения, не знает, откуда они пришли, ей это неинтересно.
  •  Например, ЗУП. В него падают данные о продажах, чтобы начислять премию сотрудникам за хорошие показатели работы. Данные о продажах могут приходить с сайта или из «Розницы». ЗУП-у все равно, откуда пришли продажи, главное, чтобы они были зарегистрированы.

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

А где же у него кнопка?

Так «где же у него кнопка»?

• Yellow RabbitMQ – это пакет программ, пакет инструментов. Почему он называется «Желтый кролик»? Все просто. Потому что он позволяет связывать «желтые» программы с «кроличьими» очередями.
• Этот набор инструментов работает на Windows и на Linux.
• Он обеспечивает нативную, родную интеграцию 1С с сервером очередей по протоколу AMQP. Никаких HTTP-вызовов, никаких посредников, все на голом TCP, честные байты «гоняются» очень быстро. Записали справочник, через секунду он у вас уже на сайте. Никаких накладных расходов на HTTP-вызовы нет.
• Этот набор инструментов содержит упрощенный API для быстрого старта, чтобы «поставить и запустить».
• Производит все это компания SilverBulleters.

Состав пакета

• Основой пакета является внешняя компонента 1С, которая реализует различные низкоуровневые операции с байтами. Эта компонента встроена в подсистему 1С (по типу БСП), которую вы можете внедрить в свою конфигурацию.
• Подсистема Yellow RabbitMQ содержит в себе высокоуровневые абстракции для наиболее распространенных схем, о которых я говорил:
  • Подписчик-издатель;
  • Асинхронный сервис;
  • Прямой обмен и т.д.;
  • Реализованы даже более высокоуровневые абстракции, которые позволяют не сильно заботиться о детализации протокола AMQP.
• При этом низкоуровневый доступ к протоколу AMQP остается открытым и если очень хочется, то можно еще и вживую AMQP «подергать» за методы.
• Кроме того, в состав пакета входят скрипты для поднятия тестовой виртуальной среды. Если хочется попробовать, там есть Vagrantfile. Вы просто пишете vagrant up и получаете себе сразу сервер RabbitMQ, с которым сразу же можно «поиграться».
• Также в состав пакета входят демо-конфигурации, которые позволяют посмотреть, как обеспечивается интеграция с базами 1С.

1 год – полет нормальный

Самому инструменту всего год. Разрабатывать мы его начали не так давно. Но за этот год он себя очень хорошо показал. Yellow RabbitMQ активно используется:

• В общероссийском проекте, в одном из министерств.
• В крупной федеральной оптовой сети автозапчастей.
• В реализации тиражного решения БИТ:MDM.
• И еще более 20 компаний, где это уже более года работает практически как часы, без нареканий.

Отправка сообщений

Давайте посмотрим внутрь этой подсистемы.

• Основную нагрузку выполняют классы абстракций, сделанные в виде обработок. На слайде показаны фрагменты кода, как этими обработками пользоваться.
• Например, если мы хотим просто отправить событие в мир, то наверху написаны три строки, как это сделать:
  • Мы создаем объект Публикатор;
  • Говорим ему: Публикатор.ОтправитьСообщение(ТелоСообщения);
  • И кладем тело сообщения в какую-то очередь.
• Или наоборот, если вы хотите использовать отправку, основанную на механизме транзакций (если вдруг документ не провелся, то событие в очередь не класть), то для этого в подсистеме предусмотрен механизм отложенной транзакционной отправки (когда вы событие записываете не сразу в очередь, а сначала в справочник). В этом случае события из справочника будут отправлены «в мир» только если транзакция уже зафиксировалась.

Все эти механизмы в подсистеме уже из коробки есть.

Подписка на событие

Как делается подписка на событие?

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

Таким образом, вы у себя в конфигурации организуете подписку на приходящие к вам события.

Асинхронный RPC

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

• Поначалу довольно страшно оставаться без ответа от системы. Когда вы вызываете удаленную систему и не получаете ответ сразу, непонятно, получился вызов или нет. Поначалу действительно очень страшно, как же так программировать – я вызов-то отправил, а вдруг она не работает?
• Системы часто ломаются, такое бывает, поэтому это нормально, что она не работает, не надо этого бояться. Да, не работает – когда включится, тогда и обработает, ничего страшного. Это такой небольшой психологический момент по пересмотру модели программирования.
• По большому счету, если очень страшно, всегда можно сымитировать синхронный вызов и ждать, когда же система ответит. Но так делать все-таки не нужно, это – антипаттерн.

Как работает RPC на стороне сервиса?

Давайте рассмотрим гипотетический сервис, который отправляет SMS, получая на вход номер телефона абонента и текст сообщения. Как наладить работу такого сервиса в рамках подсистемы YRMQ?

• Во-первых, на стороне сервиса вы точно так же пишете прикладной обработчик, который как-то отправляет SMS. Это ваш прикладной код, который пишет ваш программист.
• А в переопределяемом модуле подсистемы YRMQ добавляете обработчик вызова (ДобавитьОбработчикВызова()), где указываете, что:
  • при вызове вот этого асинхронного сервиса должен быть запущен вот этот код.
• И подсистема будет это делать.

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

RPC на стороне клиента

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

• Мы точно так же мы подготавливаем параметры вызова – номер телефона абонента и текст сообщения.
• Создаем объект асинхронного сервиса через подсистему – Сервис.Вызвать().
• Больше делать ничего не надо. Дальше мы идем заниматься своими делами.
• И потом у вас стартует фоновое задание, в котором вы ждете ответ от сервиса SMS, если он вам нужен.

Предположим, вы хотите отправлять SMS в момент проведения заказа.

• Если вы используете синхронный сервис SMS и он не работает, то заказы вы принимать не сможете, и у вас случится простой.
• А при использовании асинхронного сервиса отправки SMS все будет работать.

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

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

В этом весь смысл – развязать системы между собой.

Низкоуровневые методы

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

Дайте две!

Где взять этот замечательный продукт?

• Взять его можно на infostart.ru.
• Под каждого клиента формируется отдельная персональная именная сборка.
• Сюда же входят консультации и техническая поддержка по определенным условиям, которые можно уточнить уже у производителя/
• И понятное дело, что мы не одобряем утечки этого инструмента.

Памятка интегратора

Итак, чтобы распутать свою интеграцию, нужно сделать чек-лист.

• Обязательно нужно назвать свои потоки данных четкими, понятными именами, чтобы в разговоре с коллегами все понимали, что говорят об одном и том же.
• Каждый поток данных атрибутировать и задокументировать эти атрибуты.
• Зафиксировать интерфейсы, построить диаграммы обмена.
• Внедрить в 1С подсистему Yellow RMQ.
• И… наслаждаться жизнью!

Планы по развитию

• В первую очередь мы планируем развивать 1С-ную часть.
• Планируем поддержать сервер очередей Apache Kafka, который немного другой, чем RabbitMQ, но тоже хороший.
• Хотим поддержать современный протокол AMQP 1.0, который пока еще находится в черновиках, но скоро будет опубликован. Там много разных «плюшек», которые мы тоже хотим поддерживать.
• И потом хотим поддержать deepstream.io – это немного не про очереди, это про быструю интеграцию.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.