使用gRPC代替LWM2M/CoAP作为IoT协议

Question

我一直在考虑将gRPC用于“IoT”类型的设备，而不是像传感器这样受限的东西；更像是单板计算机内置的设备，比如机器人、无人机等等。需要的是设备和集中控制器之间的接口，因为设备是单独开发的，并且可能由其他公司开发。因此，版本化的接口语言是必须的；它不应该只存在于word文档中；一些可编程的东西，如头文件、WSDL、IDL或ProtocolBuffer。此外，设备和控制器之间的行为应该指定为常见用例，如注册，重新注册etc.This可以在word文件或一些非技术文档中。

Protocol Buffer (版本3)中的(rpc)接口规范以及通过gRPC的高效实现使我选择它而不是CoAP/ LWM2M (乐山Java和C++实现)。

同时使用了LWM2M和grPC，我想说gRPC对开发人员更友好；接口定义和实现速度更快，与OMA LWM2M process.Of课程相比，gRPC中没有观察者通知，但对于MQTT应该足够了。

严格来说，不能将LWM2M与gRPC进行比较。LWM2M不仅仅是一个接口，还定义了许多IoT案例中的行为，比如BootStrap，注册，KeepAlive，软件升级等，它的通用超文本传输协议，如GET，放在一个URL型可寻址资源上使其非常完整。然而，这些行为中的大多数都可以通过一些努力进行自定义。

我们计划编排的一些IoT东西远不是像灯泡这样的小脑洞设备，而更像是机器人。有没有人将gRPC用于类似的目的。分享任何成功的失败故事

Answer 1

在用于IoT的gRPC中，我会遗漏的是MQTT MQ功能，比如消息排队、代理桥接QoS参数。或者用于CoAP短信传输上的带外消息。在这个上下文中，gRPC“仅仅”是一个假定总是通过TCP连接的远程过程调用框架。

Answer 2

我尝试了一下，并在一个连接了‘Devices’的项目中使用了它；这些都是像Raspberry-pi这样的小型计算机。总体而言，这是一个很好的体验；使用的语言主要是C++和Java，还有Node.js中的JavaScript。我们使用它作为Dockerized的微服务；负载平衡是我们还没有做的；我读到基于HTTP/2的负载平衡是棘手的；将更新这一部分；计划使用Kubernetes来实现。具有版本化接口的整体容器技术- GRPC似乎很适合(微)服务

Answer 3

我们的想法与乔的解决方案相同，包括CoAP + Protobuf：

• Protobuf &它的IDL是一种非常有用的方式来集中定义和管理我们的API。谷歌的api-linter和AIPs都是保证一切正常的高质量资源。
• CoAP for transport:适用于IoT设备的轻量级协议。它在几乎所有的RTOS/embedded/platform中都可用，并且适用于我们在这个世界上通常面临的低带宽。作为线程选择的协议和Project Connected Home Over IP给予它的支持也是有帮助的，
• 使用Protobuf处理消息，无论它们是请求/响应，甚至是IoT设备推送的事件消息。nanopb已经解决了一个问题，它是一个用于嵌入式systems.
• Generate的protobuf兼容C代码生成器，我们自己的存根基于IDL语言来创建我们自己的基于CoAP和nanopb代码的包装器。支持一元调用，也支持服务器流，通过利用这一点到CoAP可观察机制。