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

Question

我一直在考虑将gRPC用于'IoT'型设备; 没有像传感器那样受限制的东西; 更像是单板计算机内置设备,如机器人,无人机等.设备和集中控制器之间的接口需要什么,因为这些设备是由其他公司单独开发的.所以版本化的界面语言是必须的; 它不应该只是在word文档中; 可编程的东西,如头文件或WSDL或IDL或ProtocolBuffer.在设备和控制器之间也应该为注册,重新注册等常见用例指定行为.这可以在word文件或某些非技术文档中.

协议缓冲区(版本3)中的(rpc)接口规范以及通过gRPC的高效实现使我能够通过CoAP/LWM2M(乐山Java和C++实现)进行选择.

使用LWM2M和grPC后,我会说gRPC对开发人员更友好; 与OMA LWM2M进程相比,接口定义和实现速度很快.当然,gRPC中没有Observer-Notify,但对于MQTT应该足够了.

严格来说,无法将LWM2M与gRPC进行比较.LWM2M不仅仅是接口,而且还定义了许多物联网案例中的行为,如BootStrap,Registration,KeepAlive,SW Upgrade等,其通用HTTP如GET,PUT在URL类型可寻址资源上使其非常完整.但是,大多数这些行为都可以通过一些努力进行自定义.

我们计划编排的一些物联网事物远不是像灯泡这样的小脑器,更像是机器人.有没有人使用gRPC用于类似目的.分享任何失败故事的成功

Answer 1

我会在 gRPC for IoT 中遗漏的是 MQTT MQ 功能，例如消息排队、代理桥接 QoS 参数。或者对于 CoAP，通过 SMS 传输的带外消息。在这种情况下，gRPC“只是”一个假设始终通过 TCP 连接的 RPC 框架。

Answer 2

我已经冒险尝试并在一个具有连接“设备”的项目中使用它；这些是像 Raspberry-pi 这样的小型计算机。总的来说，这是一次很好的经历；使用的语言主要是 C++ 和 Java，Node.js 中也有 JavaScript。我们将其用作 Docker 化的微服务；负载均衡是我们没有做的；我读到基于 HTTP/2 的负载平衡很棘手；将更新该部分；计划为此使用 Kubernetes。具有版本化接口的整体容器技术 - GRPC 似乎非常适合（微）服务