使用gRPC作为IoT协议而不是LWM2M/CoAP

我一直在玩弄使用gRPC作'IoT'型设备的想法;不像传感器那样受到很多限制;更像是像机器人，无人机等单板计算机内置设备。设备和集中控制器之间需要一个接口，因为这些设备是由其他公司单独开发和可能的。所以一个版本化的界面语言是必须的;它不应该只是一个文字文件;可以像头文件或WSDL或IDL或ProtocolBuffer一样编程。在设备和控制器之间，应该为注册，重新注册等常见用例指定行为。这可以在word文件中或在一些非技术文档中。使用gRPC作为IoT协议而不是LWM2M/CoAP

协议缓冲区（版本3）中的（rpc）接口规范以及通过gRPC的高效实现使我选择了CoAP/LWM2M（乐山Java和C++实现）。

既然使用了LWM2M和grPC，我会说gRPC对开发者更友好;与OMA LWM2M进程相比，接口定义和实现速度很快。当然，在gRPC中没有Observer-Notify，但为此MQTT就足够了。

严格地说，人们无法将LWM2M与gRPC进行比较。 LWM2M不仅仅是接口，还定义了许多物联网案例中的行为，如BootStrap，注册，KeepAlive，SW升级等，其通用HTTP如GET，PUT在URL类型可寻址资源上使其非常完整。然而，大部分这些行为可以通过一些努力来定制。

我们计划编排的一些物联网项目远离像灯泡这样的小设备，更像机器人。有没有人使用gRPC用于类似的目的。任何成功的失败故事分享

来源

2017-01-30 Alex Punnen

grpc社区也问过;无法在那里得到答复;因此张贴在这里; https：//groups.google.com/forum/#！topic/grpc-io/H0DBwvUqIDA –

尽管看起来很完整，但我一直隐约关注gRPC，它确实是品牌崭新的。我在内部对Node.js微服务进行了测试，但我不敢肯定地说这是经过测试和/或生产稳定的。您可能会对所知道的或只是原始原型更安全。除非你乐于参与长时间的游戏，研发/原型设计和/或坚持可能成为最好的基础，而不必担心大的重写，因为随着时间的推移gRPC变得更加稳定。（也许在一年内它可以被认为是一个坚实的图书馆） –

我已经采取了冒险，并用它在一个项目中连接'设备';这些小型电脑像Raspberry-pi。总的来说，这是很好的经验;所使用的语言主要是C++和Java以及Node.js中的JavaScript。我们用它作为Dockerized微服务;负载平衡是我们没有做的;我读到基于HTTP/2的负载平衡是棘手的;将更新该部分;计划为此使用Kubernetes。使用版本化界面的整体容器技术 - GRPC似乎非常适合（微）服务

来源

2017-06-01 04:31:58

我在gRPC中为IoT所错过的东西是MQTT MQ功能，如消息队列，代理桥接QoS参数。或者通过SMS传输为CoAP提供带外消息。在这种情况下，gRPC只是一个RPC框架，它假定始终通过TCP连接。

来源

2017-08-24 18:54:55

使用gRPC作为IoT协议而不是LWM2M/CoAP

回答

相关问题