尝试在具有多个服务器或可能多路复用的 Python 中使用 gRPC

我们的用例涉及一个类,该类必须远程初始化另一个类的多个实例(每个实例都在不同的 IoT 设备上),并且必须从每个实例中获取特定结果。最多,我们需要每秒从每个远程客户端接收 30 条消息,每条消息都相对较小。你们会推荐什么类型的架构来解决这个问题?

我们在想,位于 IoT 设备上的每个类都将充当服务器,而接收结果的类将是客户端,那么我们是否应该为每个 IoT 设备创建一个服务器,每个服务器都有自己的通道?或者是否可以让每个 IoT 设备在同一台服务器上使用相同的服务(意味着同一台服务器上的同一服务会有多个实例,但在不同的设备上)?


潇湘沐
浏览 83回答 1
1回答

手掌心

该问题将受益于其他详细信息以帮助指导答案。gRPC(及其对 HTTP/2 的使用)是比 MQTT 等“更重”的协议。MQTT 更常用于 IoT 设备,因为它占用空间更小。REST/HTTP(即使比 MQTT 更重)也可能比 gRPC/HTTP2 对您有好处。如果您致力于 gRPC,我想知道反转您提议的架构并让 IoT 设备成为客户端是否会更好?这似乎提供了额外的安全性,因为客户端发起与您的服务器的通信而不是公开服务。无论哪种方式(如果您决定使用 MQTT),希望您将使用 mTLS。我假设(!?)客户端实现小于服务器实现。无论方向如何,客户端和服务器都可以(独立地)流式传输消息。IoT 设备(客户端或服务器)每秒可以传输 30 条消息。服务器可以流式传输管理|控制消息。我没有管理物联网设备群的经验,但我认为,远程管理|监控和无线升级|修补对您来说是重要的要求。gRPC 不限制任何这些功能,但调试可能更具挑战性。使用例如 REST/HTTP,卷曲端点是微不足道的,但是使用 gRPC(即使是优秀的grpcurl)你将被限制在所实现的服务上。是的,您也不能调用不存在的 REST API,但我发现远程调试 gRPC 服务比 REST 更具挑战性。
打开App,查看更多内容
随时随地看视频慕课网APP

相关分类

Python