我一直在玩弄将 gRPC 用于“IoT”类型设备的想法；不是很受限制的东西，比如传感器；更像是单板计算机内置设备，如机器人、无人机等。由于设备是单独开发的，并且可能由其他公司开发，因此需要设备和集中 Controller 之间的接口(interface)。所以版本化的界面语言是必须的；它不应该只是在一个word文档中；一些可编程的东西，比如头文件、WSDL、IDL 或 ProtocolBuffer。同样在设备和 Controller 之间，应为注册、重新注册等常见用例指定行为。这可以在 word 文件或一些非技术文档中。
Protocol Buffer (ver 3) 中的 (rpc) 接口(interface)规范以及通过 gRPC 的高效实现使我选择了 CoAP/LWM2M(乐山 Java 和 C++ 实现)。
使用过 LWM2M 和 grPC，我想说 gRPC 对开发人员更友好；与 OMA LWM2M 流程相比，接口(interface)定义和实现速度很快。当然 gRPC 中没有 Observer-Notify，但对于那个 MQTT 就足够了。
严格来说，不能将 LWM2M 与 gRPC 进行比较。 LWM2M 不仅仅是接口(interface)，它还定义了许多 IoT 案例中的行为，如 BootStrap、Registration、KeepAlive、SW 升级等，它的通用 HTTP(如 GET、PUT)在 URL 类型的可寻址资源上使其非常完整。然而，大多数这些行为都可以通过一些努力来自定义。
我们计划编排的一些物联网事物远不是像灯泡这样的小脑设备，更像是机器人。有没有人将 gRPC 用于类似目的。任何成功的失败故事分享
最佳答案
我在物联网的 gRPC 中错过的是 MQTT MQ 功能，例如消息队列、代理桥接 QoS 参数。或者对于 CoAP，通过 SMS 传输的带外消息。在这种情况下，gRPC“只是”一个假定始终通过 TCP 连接的 RPC 框架。
关于protocol-buffers - 使用 gRPC 作为物联网协议(protocol)而不是 LWM2M/CoAP，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41935674/