[Перевод] Шаблоны взаимодействия для интернета вещей
Прежде чем начать новый IoT-проект, стоит поразмыслить о том, какие шаблоны обмена информацией наилучшим образом для него подойдут. На самом деле, принять это решение следует как можно раньше, ещё до того, как выбраны протоколы, способы связи и вспомогательная инфраструктура разрабатываемой системы. В основе этой рекомендации лежит одна простая причина: не приняв подобное решение в самом начале, разработчик, по мере развития проекта, рискует сам себя загнать в угол, выбраться из которого можно будет лишь серьёзно переработав код, архитектуру, модель безопасности решения, и то, как оно взаимодействует с внешним миром.
Сегодня мы рассмотрим одиннадцать шаблонов взаимодействия в IoT-системах.
Шаблон «запрос — ответ»
Шаблон «запрос — ответ» (request — response), это, вероятно, самый широко известный шаблон обмена информацией. Его реализация предусматривает наличие клиента, или вызывающей стороны, который выполняет запросы к некоей службе, расположенной на сервере, предоставляющем услуги. Сервер ещё называют респондентом или ответчиком.
Шаблон «запрос — ответ»
Именно этот шаблон использует протокол HTTP. Он же является основой сервисно-ориентированных архитектур, веб-служб и REST-решений. Это практичный шаблон, в особенности, если архитектура проекта предусматривает наличие клиентских и серверных частей или ведущих и ведомых сущностей.
Помимо HTTP, шаблон «запрос — ответ» поддерживают такие протоколы, как Constrained Application Protocol (CoAP) и Extensible Messaging and Presence Protocol (XMPP).
Основной недостаток данного шаблона заключается в неравенстве участников обмена данными, что вполне очевидно проявляется в топологии интернета. Двунаправленный обмен данными, когда оба участника запрашивают данные друг у друга, может быть сложен в реализации, особенно если на пути данных имеются сетевые экраны.
Планируя использовать шаблон «запрос — ответ» в проекте, нужно решить, какие части системы будут клиентами, а какие — серверами. Если, например, некий датчик будет клиентом, а IoT-шлюз — сервером, датчик сам будет решать, когда ему передавать на сервер собственные показания. Сервер же, если ему понадобятся сведения с датчика, самостоятельно их запросить не сможет. Если же датчик сделать сервером, а шлюз — клиентом, датчик можно будет опрашивать когда угодно. Однако, тут есть одна проблема: если датчик недостаточно защищён, кто угодно сможет к нему подключиться. Если же в подобном решении задействована надёжная система безопасности, то, как следствие, усложнится способ взаимодействия клиента и сервера, да и сама система в целом. Возможно, в проект нужно будет добавить дополнительные службы, датчики придётся оснащать более мощным аппаратным обеспечением. Кроме того, всем этим будет сложнее управлять.
Шаблон «подписка на события»
Этот шаблон (event subscription) позволяет клиенту подписываться на события заданного типа на сервере. Сервер оповещает клиента всякий раз, когда происходит интересующее его событие. Как результат, отпадает необходимость в постоянном опросе сервера.
Шаблон «подписка на события»
Продвинутый механизм подписки на события может включать в себя требования, зависящие от клиента, касающиеся того, какие именно события и при каких условиях его интересуют. Преимущества использования подписки на события перед ранее рассмотренным шаблоном «запрос — ответ», заключаются в том, что для обмена данными между клиентом и сервером нужно примерно в два раза меньше сообщений. Кроме того, данные передаются клиенту при возникновении некоего события, а не по запросу, что снижает до минимума время между возникновением некоей ситуации, интересующей клиента, и моментом, когда он об этом узнает.
Протоколы, которые поддерживают этот шаблон, включают в себя CoAP, XMPP и General Event Notification Architecture, который является частью архитектуры Universal Plug and Play, базирующейся на HTTP.
Шаблон «асинхронный обмен сообщениями»
Асинхронный обмен сообщениями (asynchronous messaging) предусматривает возможность отправки сообщений между равноправными системами, находящимися на одной ступени иерархии. Этот шаблон подразумевает двунаправленный обмен сообщениями.
Шаблон «асинхронный обмен сообщениями»
Если используемый протокол поддерживает асинхронный обмен сообщениями, на его основе можно построить любые другие шаблоны передачи данных.
Среди протоколов, которые поддерживают данный шаблон, можно назвать XMPP, Advanced Message Queuing Protocol (AMQP), и, на уровне IP — User Datagram Protocol (UDP). Однако, в случае с применением UDP для реализации этого шаблона, возможны проблемы с сетевыми экранами.
Шаблон «надёжная доставка сообщений»
Приложениям, выполняющим критически важные функции, необходимо знать, что сообщение было доставлено получателю как минимум один раз. Собственно говоря, при использовании шаблона асинхронного обмена данными это требование выполняется. Сообщение может потеряться в пути, но использование шаблона «запрос — ответ» позволяет запросить отправку сообщения снова, до тех пор, пока не будет получено подтверждение (или ответ) от стороны, которая должна сообщение получить. Тут нужно учитывать, что потеряться может и сообщение, и ответ о его получении, поэтому данный шаблон гарантирует, что сообщение будет доставлено как минимум один раз. Однако, то, что сообщение будет доставлено получателю не более одного раза (или не менее одного раза), не очень подходит некоторым приложениям, например, таким, которые задействуют концепцию транзакций или выполняют подсчёт сообщений.
Применение шаблона надёжной доставки сообщений (reliable messaging) даёт гарантию того, что сообщение будет доставлено получателю в точности один раз. Среди протоколов, поддерживающих надёжную доставку сообщений, можно отметить Message Queuing Telemetry Transport (MQTT), AMQP. Кроме того, благодаря открытым расширениям, подобный функционал поддерживают HTTP и XMPP
Шаблон «многоадресная передача сообщений»
Предыдущий шаблон занят обменом сообщениями между двумя объектами. Иногда, однако, требуется более эффективный подход, если одну и ту же информацию нужно, в одно и то же время, отправить нескольким получателям. Самый простой из шаблонов, реализующих подобный функционал — это «многоадресная передача сообщений» (multicasting). В рамках этого шаблона отправитель отсылает одно сообщение через промежуточное звено системы (это может быть брокер или маршрутизатор), после чего сообщение пересылается нескольким получателям, каждый из которых зарегистрировался для получения подобных сообщений.
Шаблон «многоадресная передача сообщений»
Благодаря использованию данного шаблона можно снизить нагрузку на сеть, так как отправителю не нужно самостоятельно слать одно и то же сообщение каждому, кто его ожидает. На самом деле, отправителю даже не нужно знать, кто именно получит сообщение. Этот шаблон может быть весьма полезен во множестве ситуаций. Например, при синхронизации множества устройств или при распределении одних и тех же данных между несколькими получателями. Многоадресную передачу сообщений поддерживают протоколы XMPP, AMQP и UDP.
Здесь уместно высказать некоторые предостережения. Касаются они использования многоадресной передачи сообщений для реализации других схем связи.
Так, хотя этот шаблон и можно использовать для снижения нагрузки на сеть, часто к нему обращаются как к способу обхода ограничений в используемом протоколе, а также — для реализации на базе некоего протокола шаблона «подписка на события». Если, например, использовать многоадресную передачу сообщений для того, чтобы уменьшить задержки в сетях, где нужно, но невозможно, реализовать шаблон «подписка на события», данный шаблон приведёт не к снижению, а к повышению нагрузки на сеть. Кроме того, систему с многоадресной передачей данных сложнее защитить.
Что касается повышения эффективности использования пропускной способности сети при использовании многоадресной передачи данных, то ресурсы можно сэкономить лишь в том случае, если получатели потребляют большую часть полученных данных. Если же значительная доля передаваемых таким образом данных не используется получателями — это повод рассмотреть другие шаблоны взаимодействия.
Шаблон «издатель — подписчик»
Шаблон «издатель — подписчик» (publish — subscribe) является расширением шаблона многоадресной доставки сообщений. Принципиальная разница между ними заключается в том, что переданные сообщения сохраняются на промежуточном узле. Эти сообщения, или ссылки на них, затем распределяются по заинтересованным в них подписчикам.
Особенности реализации шаблона зависят от используемого протокола, зависит от него, а также от настроек промежуточного узла, и то, какие именно сообщения хранятся. Это может быть только самое свежее сообщение, или заданное количество сообщений, или все сообщения.
Здесь, кроме того, важна разница в передаче самого сообщения и ссылки на него, так как это влияет на требуемую полосу пропускания сети, и, как результат, на производительность решения.
Если подписчики используют большинство сообщений, то передача самих сообщений более эффективна, как и в случае с многоадресной передачей данных. Если же фактическое потребление данных получателями зависит от неких дополнительных факторов, то эффективнее передавать ссылки на сообщения. Они меньше, чем сами сообщения, а подписчики, вероятнее всего, используют лишь небольшое их число для того, чтобы получить те сообщения, на которые указывают ссылки. В подобном случае, для того, чтобы получить сообщение по ссылке, требуется выполнять дополнительные обращения к узлу хранения сообщений по модели «запрос — ответ».
Шаблон «издатель — подписчик» поддерживают такие протоколы, как MQTT, AMQP, XMPP.
Шаблон «очередь»
Очереди, а конкретно — очереди FIFO — это шаблон обмена данными, который позволяет одной или большему количеству сущностей отправлять некие сообщения или задания для обработки в очередь, после чего один или несколько получателей получают эти сообщения в том порядке, в котором они были поставлены в очередь.
Шаблон «очередь»
Очередь обычно находится на промежуточном узле, или в сети, к которой подключены все участники обмена данными. Очереди — это замечательное средство для балансировки нагрузки. В очередь собирают задания из различных источников и распределяют их среди существующих обработчиков, возможно, обладающих разной производительностью.
Используя очередь, можно избежать жёсткой связи между системами, передающими данные, и системами, эти данные получающими и обрабатывающими. В результате, в зависимости от реальной рабочей нагрузки на систему, можно увеличивать или уменьшать количество приёмников и передатчиков данных. Среди протоколов, о которых мы уже говорили, лишь AMQP обладает встроенной поддержкой очередей.
Шаблон «брокеры сообщений»
Брокеры сообщений (message brokers) обычно являются стандартизированными компонентами вспомогательной сетевой инфраструктуры IoT-проектов. Они красиво решают проблемы, вызываемые ограничениями, которые накладывают сетевые экраны на двунаправленный обмен данными между устройствами. Брокер позволяет сущностям подключаться к нему, занимаясь передачей сообщений между подключёнными к нему клиентами. Так как все подключения выполнены через брокера, только брокер должен быть доступен из интернета. Сетевому экрану не нужно принимать или перенаправлять входящие подключения к устройствам, как было бы нужно при использовании протокола, обеспечивающего связь равноправных систем, жёстко ограниченного подобной моделью обмена сообщениями.
Помимо управления сообщениями, брокеры могут предоставлять подключённым клиентам дополнительные службы. Например, брокер может выступать посредником при реализации шаблона многоадресного обмена сообщениями, шаблонов «издатель — подписчик» и «очередь».
Кроме того, брокеры сообщений обычно предоставляют службы аутентификации клиентов. Это облегчает работу в распределённых сетях, где проверка подлинности устройств может оказаться непростой задачей. Таким образом, если брокер может сообщать о статусе уже аутентифицированных участников системы, включённых в обмен данными, другие участники могут использовать эту информацию для принятия решений в сфере безопасности. Это, к тому же, избавляет от необходимости реализации собственной схемы аутентификации на каждом участнике обмена данными.
Хотя обмен сообщениями между равноправными системами — это лишь один из вариантов организации связи, подобные решения должны предусматривать аутентификацию клиентов. Иначе серьёзно пострадает безопасность системы. Если же используется протокол, который включает в себя брокеры сообщений, то, вероятнее всего, не понадобится разрабатывать собственные вспомогательные службы, которые позволят решению работать надёжно и безопасно.
Протоколы XMPP, AMQP и MQTT, в той или иной форме, задействуют этот шаблон.
Шаблон «федерация»
«Федерация» (federation) — это важный шаблон, в котором некая глобальная сеть разбивается на логические части. Это позволяет осуществлять глобальное масштабирование решения и обеспечивает всё необходимое для его естественного роста.
Шаблон «федерация»
Основная идея здесь — позволить увеличивать размеры решения, не ограничивая при этом производительность существующей сетевой инфраструктуры, используя подход «разделяй и властвуй».
При осуществлении связи без брокеров, например, как при использовании протоколов HTTP и CoAP, федеративная структура имеется на уровне домена. Каждый домен указывает на собственный набор IP-адресов, с ним связан собственный веб-сервер. В систему можно добавлять новые веб-сервера, в новых доменах, не ограничивая доступ к существующим системам. Такой подход — один из основных ключей к успеху Всемирной паутины.
При использовании протоколов, предусматривающих наличие брокеров и поддерживающих федерации, брокеры соединяются между собой для маршрутизации сообщений. Каждый брокер управляет аутентификацией в собственном домене и знает, как подключаться к другим доменам для перенаправления в них сообщений. Кроме того, федеративные сети с брокерами предоставляют удобное решение проблемы глобальной идентификации участников обмена данными.
Наиболее широко известный протокол, использующий брокеров и федерации — Simple Mail Transfer Protocol (SMTP). Среди протоколов, о которых мы говорим в этом материале, умеющих работать с брокерами, федерацию поддерживает лишь XMPP.
Шаблон «обнаружение»
Рассмотрим условный пример. Пусть, у нас имеется некое изготовленное на заводе устройство, которое планируется использовать в IoT-системе. Если его, например, планируется применять в системе с многоадресной передачей данных, мы сразу же столкнёмся с некоторыми сложностями, связанными с интеграцией устройств в систему.
Заключаются они в том, что «вещи» осведомлены только о собственной идентификационной информации (это может быть что-то вроде MAC-адреса), но ничего не знают ни о том, как они будет «видны» в сети, к которой их планируется подключить, ни о некоем главном сетевом устройстве, с которым им придётся взаимодействовать.
После установки и настройки (чем больше автоматизирована настройка — тем лучше), «вещи» узнают о своей сетевой идентификационной информации, но не о том, как подключиться к главному устройству. В свою очередь, главному устройству известен собственный сетевой адрес, а также — заводские данные «вещей» (которые, например, можно быстро ввести в систему, отсканировав наклейки на коробках), но не сетевые данные других устройств.
Шаблон обмена сообщениями «обнаружение» (discovery) позволяет создать механизм, с помощью которого производится сопоставление сетевых идентификационных данных подчинённых устройств с сетевыми данными главного узла. Делается это с использованием общих знаний об исходных идентификационных параметрах подчинённых устройств.
Шаблон «обнаружение»
Данный шаблон реализуется с использованием «реестра вещей» (Thing Registry), доступного по сети как самим «вещам», так и главному устройству. Клиенты регистрируются в реестре, а главное устройство обращается к ним через реестр, используя лишь их заводские идентификаторы. Если запрос успешен, то сетевые идентификационные данные каждого из участников обмена данными отправляются другому, и оба, таким образом, знают, как друг с другом взаимодействовать. Существует расширение XMPP, которое поддерживает этот шаблон.
Шаблон «делегирование доверия»
В интернете важна возможность принятия взвешенных решений в области безопасности. При использовании шаблона «делегирование доверия» (delegation of trust) конечные устройства перенаправляют запросы к более надёжно защищённой, доверенной системе в реальном времени, а после получения ответа выполняют некие действия.
Шаблон «делегирование доверия»
Действия доверенной сущности, при поступлении новых запросов от клиентских систем, могут быть основаны, например, на машинном обучении, либо на настройках, которые задаёт администратор, возможно, реагируя на запросы системы при поступлении ей новых запросов.
Для того, чтобы можно было реализовать этот шаблон, необходимо использовать асинхронный двунаправленный обмен сообщениями. Существует расширение XMPP, которое поддерживает делегирование доверия.
Итоги
В заключение хотелось бы отметить, что, придерживаясь стандартов и открытых спецификаций, можно улучшить совместимость разработки в сфере IoT с существующими системами. Аналогично, используя открытые, стандартизированные, взаимозаменяемые компоненты, можно избежать необходимости создания дорогой инфраструктуры. А правильный выбор шаблона обмена данными — это отличный способ обезопасить себя от серьёзной переработки проекта на поздних стадиях его развития.
Некоторые из шаблонов, о которых мы говорили, могут увеличить сложность проекта в самом начале работы над ним, но эти дополнительные издержки — ничто по сравнению со стоимостью возможных будущих неувязок. Например, сложностей, связанных с интеграцией в существующую среду. Сразу такое предусмотреть почти невозможно, однако, правильный выбор шаблона поможет избежать подобных проблем.
