2017-01-30 3 views
1

Я занимался идеей использования gRPC для устройств типа «IoT»; не очень ограниченные вещи, такие как датчики; больше похожи на встроенные компьютерные компьютеры, такие как роботы, дроны и тому подобное. Нужен интерфейс между устройством и централизованным контроллером, поскольку устройства разрабатываются отдельно и возможны другими компаниями. Таким образом, язык интерфейса с версией является обязательным; и это не должно быть только в текстовом документе; что-то программируемое как заголовочный файл или WSDL или IDL или ProtocolBuffer. Также между устройством и контроллером поведение должно указываться для обычного использования, например, для регистрации, перерегистрации и т. Д. Это может быть в текстовом файле или в каком-то нетехническом документе.Использование gRPC в качестве протокола IoT вместо LWM2M/CoAP

Спецификация интерфейса (rpc) в протокольном буфере (версия 3) вместе с эффективной реализацией через gRPC позволяет мне выбирать это по сравнению с CoAP/LWM2M (реализация Leshan Java и C++).

Используя как LWM2M, так и grPC, я бы сказал, что gRPC более дружественный для разработчиков; определение интерфейса и реализация выполняется быстро, по сравнению с процессом OMA LWM2M. Конечно, в gRPC нет Observer-Notify, но для этого MQTT должен быть достаточным.

Строго нельзя сравнивать LWM2M с gRPC. LWM2M - это не только интерфейс, но и определяет поведение во многих случаях IoT, таких как BootStrap, Registration, KeepAlive, обновление программного обеспечения и т. Д., А его универсальный HTTP, такой как GET, PUT по адресу URL-адресу, адресуемому ресурсу, делает его очень полным. Однако большинство этих поведений можно настроить с определенными усилиями.

Некоторые из вещей IoT, которые мы планируем организовать, далеки от небольших мозговых устройств, таких как луковицы, и больше похожи на роботов. Кто-нибудь использовал gRPC для подобных целей. Любой успех неудачных историй для обмена

+0

спросил в сообществе grpc; не мог получить ответ; так что размещайте здесь: https: //groups.google.com/forum/#! topic/grpc-io/H0DBwvUqIDA –

+0

Хотя это может выглядеть полно, я смутно следил за gRPC, и это действительно шпагат нового бренда. Я тестирую его для микросервисов Node.js внутри, но я не уверен, что это тестирование на битву и/или стабильное производство. Возможно, вы можете быть более безопасными с тем, что знаете, или просто протосами. Если вы не счастливы играть в длинную игру, R & D/прототипирования и/или придерживаться того, что, вероятно, будет лучшим фундаментом и не беспокоится о больших переписях, поскольку gRPC становится более стабильным с течением времени. (Может быть, через год его можно считать сплошной библиотекой) –

ответ

0

Я сделал решительный шаг и использовал его в проекте с подключенными «Устройствами»; Это небольшие компьютеры, такие как малина-пи. В целом это был хороший опыт; и языки, используемые в основном C++ и Java, а также JavaScript в Node.js. Мы использовали это как Dockerized microservices; Балансировка нагрузки - это то, чего мы не сделали; и я прочитал, что балансировка нагрузки на основе HTTP/2 сложна; Обновит эту часть; планируя использовать Kubernetes для этого. Общая технология контейнеров с версиями интерфейсов - GRPC кажется подходящим для (микро) услуг

0

То, что я пропустил бы в gRPC для IoT, - это возможности MQTT MQ, такие как очередь сообщений, макетирование QoS Parameter. Или для CoAP сообщения Out of Band через SMS Transport. В этом контексте gRPC - это «просто» инфраструктура RPC, которая предполагает, что она всегда связана через TCP.

Смежные вопросы